One workspace per task
On any given day, you may be involved in tasks such as the following:
- Implement a new feature
- Fix a bug
- Review a pull/merge request
- Pair-program with a team member
- Browse an open source project’s source code
For each of these tasks, you start a clean, ephemeral Gitpod workspace. You can even start multiple workspaces in parallel. For example, while you’re working on a feature, you can start a second workspace to review a production hotfix. When the review is complete, you close the browser tab of that workspace and continue to work on your feature. This works for any GitLab, GitHub or Bitbucket project.
You can learn more about the Life of a workspace
Gitpod vs. local development
A Gitpod workspace is similar to your local developer environment, except for two key differentiators:
- It is configured as code
- It is ephemeral and only lives for as long as you work on a task
Configuration vs. manual setup
Your project’s .gitpod.yml and optional .gitpod.Dockerfile files control what tools will be available in your Gitpod workspace. Both files are version-controlled and let you monitor changes to the developer environment over time. There is no longer a need to @channel in your team’s communication software to tell everyone to upgrade their version of Node.js, only to find out that some people were on vacation and didn’t see the message.
Ephemeral vs. long-lived
Thanks to the fact that Gitpod workspaces are configured as code, you can start and stop them as frequently as you want. You know that each workspace has the tools it needs and even more importantly, has the latest code from your default branch checked out! You no longer have to pull the latest default branch a few times per day because each time you start a new workspace, it has the latest code already available.