Epic: Preview Environments
### Summary To bring the concept of a preview environment to Gitpod; a new type of `workspace` (i.e. regular, prebuild, preview). ### Context Validating a PR most frequently requires reviewers (devs and non-devs) to manually verify the application behaviour. A common practice is to have a companion preview environment, that shares the lifecycle with the PR, auto-updates and is available for any team member to collaboratively use. Currently, that is possible with Gitpod but is suboptimal. Each individual needs to start a new Gitpod workspace, wait for it to start, enter the IDE, and open the application port. Particularly for user groups that are unfamiliar with IDEs (e.g. Product Managers and Designers) this can be hard. Additionally, sharing is possible, but only while the workspace is running (i.e. while it doesn't time out) and only the owner can start it. ### Value Some customers have been requesting this feature so that other (non-dev) members of the teams can take benefit of Gitpod. Additionally, this solves a problem many teams face. It can work as a way for getting teams to set up their Gitpod environments and then more easily discover the benefits of ephemeral development environments. ### Acceptance Criteria - [ ] Non-dev team members are able to validate application behaviour without having to learn how to use the IDE and open the appropriate ports. - [ ] On each PR a link to one (and only one) `preview` workspace is automatically shared - [ ] The `previ
Posted by atduarte on Mar 30, 2022, 11:10 AM
Tags
Related issues
- struct's lifetime requirements can be bypassed via covariant field assignment
- Proposal to Reorganize the Moderation Team and Review Moderation Policies
- Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
- proposal: container/...: generic collection types
- Better Custom Endpoint BYOK
- A concrete policy for backward compatibility until Godot 5.0
Raise real-world problems, find people facing the same issue, and discuss solutions.2,500 issues0 comments
github (Other)
struct's lifetime requirements can be bypassed via covariant field assignment
Proposal to Reorganize the Moderation Team and Review Moderation Policies
Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
proposal: container/...: generic collection types
Better Custom Endpoint BYOK
A concrete policy for backward compatibility until Godot 5.0
New MTP models not supported
Tracking: 429 / Capacity Issues
Epic: Preview Environments
### Summary To bring the concept of a preview environment to Gitpod; a new type of `workspace` (i.e. regular, prebuild, preview). ### Context Validating a PR most frequently requires reviewers (devs and non-devs) to manually verify the application behaviour. A common practice is to have a companion preview environment, that shares the lifecycle with the PR, auto-updates and is available for any team member to collaboratively use. Currently, that is possible with Gitpod but is suboptimal. Each individual needs to start a new Gitpod workspace, wait for it to start, enter the IDE, and open the application port. Particularly for user groups that are unfamiliar with IDEs (e.g. Product Managers and Designers) this can be hard. Additionally, sharing is possible, but only while the workspace is running (i.e. while it doesn't time out) and only the owner can start it. ### Value Some customers have been requesting this feature so that other (non-dev) members of the teams can take benefit of Gitpod. Additionally, this solves a problem many teams face. It can work as a way for getting teams to set up their Gitpod environments and then more easily discover the benefits of ephemeral development environments. ### Acceptance Criteria - [ ] Non-dev team members are able to validate application behaviour without having to learn how to use the IDE and open the appropriate ports. - [ ] On each PR a link to one (and only one) `preview` workspace is automatically shared - [ ] The `previ
Comments (0)
No comments yet. Start the discussion.