Epic: Preview Environments

atduarte commented 2 years ago

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

shaal commented 2 years ago

👍 💯 Yes please!!!

Gitpod is incredible, and was a game changer for Drupal contributions. I was just giving a presentation last night, where I said "I am sure in the near-future Gitpod will add a preview feature". I came to add that feature request, and I am so happy it was already submitted.

For Drupal, this would allow non-developers to help with contributions. They can run a ready-made setup to test PRs, without touching (and/or being overwhelmed with VSCode interface).

TheBestMoshe commented 2 years ago

There are lots of options when it comes to preview environments. It's especially easy when using services like Vercel, Netlify, Heroku, and Render. However, they all have big flaws.

Regarding Vercel and Netlify, the issue I've always had was branch state. I want each preview environment to have its own freshly seeded database. However, these services do not have a way to manage the databases. Generally, each environment ends up sharing a database, and it leads to annoying migration conflicts.

Heroku and Render can spin up a database for a preview environment, however, as far as I can tell, there is no way to dynamically spin it up when someone is using it, and then scale it back down to 0 when it's not in use. This means that you need to pay for the entire infrastructure during the predetermined duration of the preview environment. Once the time is passed, you lose access to the preview environment.

Since I already have a full environment (database, Minio S3, pubsub, etc.) configured in GitPod, it would be amazing if we can use this same environment as a preview environment, that can scale up when the user needs it, and then scale back down.

loujaybee commented 2 years ago

Static URLS Wanted to mention that I think the use case for preview environments is also closely related to the topic of static URLs, e.g.

https://github.com/gitpod-io/gitpod/issues/898

For the QA use-case where users want to have a single URL to be passed to QA teams for review.

Collaboration This also has quite a lot of overlap with collaboration use-cases (e.g. more granular / secure sharing of the workspace, restrictions on things like terminal access etc). But that depends on whether this is more of a browser-only preview.

svenefftinge commented 2 years ago

Since I already have a full environment (database, Minio S3, pubsub, etc.) configured in GitPod, it would be amazing if we can use this same environment as a preview environment, that can scale up when the user needs it, and then scale back down.

Is this not what we already have today? I.e. scale up => start a workspace?

TheBestMoshe commented 2 years ago

Is this not what we already have today? I.e. scale up => start a workspace?

Not exactly. What I had in mind was that when a request comes into a URL, the environment gets spun up and serves the request. Similar to the way Heroku can scale down to 0 and scales up when requests come in. This way takes much less effort out of the reviewer. This is especially important if the reviewers are not technical and aren't really familiar with starting workspaces.

josepjaume commented 2 years ago

Brilliant idea 🤩! It'd be ideal for us (Factorial) as an organization. We have some stakeholders in product who don't use Gitpod (or GitHub for that matter) but would like to review the work we do in branches. We're managing to do this right now by creating workspaces for them and sending the URLs, but of course, expiry times are an issue, as well as having to go through us. Streamlining this would be fantastic!

charIeszhao commented 2 years ago

It would also be great if gitpod can provide a switch or a checkbox in the subject PR, so that people can only trigger the preview env deployment when they turn on the switch. This helps save the server cost and potential build time in each PR.

stale[bot] commented 1 year ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

shaal commented 7 months ago

I wanted to inquire if there have been any recent updates regarding this issue. @loujaybee, I believe the recent CLI improvements may help us get closer to implementing this feature.

To clarify, my definition of a preview environment entails running all tasks specified in the .gitpod.yml file, creating a Gitpod snapshot (optional), and opening a designated port to serve as a preview (skips the integrated development environment for users who do not require it)

gitpod-io / gitpod