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 preview workspace is accessible by all team members.
• The preview workspace automatically times out when there's no usage in order to save costs.

Measurement

• Percentage of Gitpod projects with preview workspaces configured.

Growth Area

Expansion

Persona(s)

No response

Hypothesis

No response

In scope

No response

Out of scope

No response

Complexities

• Timeout and automated restart logic

Press release

A preview workspace would start from the same image and run the same tasks as the regular workspace, but would have a different lifecycle, would not run an IDE and would be accessible by everyone in the team.

Lifecycle

Its lifecycle would be linked to that of a PR, just like the prebuilds' lifecycle is linked to a branch. Whenever a new PR is created, if the project is configured, a preview environment would start. Whenever the PR is updated, the preview environment is rebuilt.

The link to the applications running in the preview environment would automatically show up in the PR checks, as seen below:

Timeouts

A preview workspace should stop after X hours of inactivity, and in this case we need to consider external access/traffic to to the applications as activity.

If a preview workspace is stopped and one of the links is visited, it should automatically start.

Configuration

The list of applications would be configured in the .gitpod.yml:

Alternatively, instead of adding a new root property to the .gitpod.yml, we can add a preview: true|false property to the ports array.

Billing

Similar to prebuilds. Usage-based pricing would be a better fit for this feature, as usage particularly

No repository files, tests, or entry points are named; start by locating the existing workspace, prebuild, PR-check, and .gitpod.yml configuration implementations. Break the epic into a scoped plan covering its lifecycle, access, timeout, configuration, and billing criteria. Done means the acceptance criteria are met and the preview link appears in PR checks.