How to code directly in a cloud environment using Gitpod!

Why cloud development environments?

Before diving into what is Gitpod, let’s uncover one thing: Gitpod helps create a cloud-based development environment. From that statement, one can wonder: why do cloud development environments exist?

They exist for many good reasons :

• Convenience: With cloud development environments, developers can work from anywhere with an internet connection, using just a browser. They don't need to worry about losing time setting up their own local development environment.
• Collaboration: Cloud development environments make it easy for teams to collaborate on projects in real time. Developers can share their work with each other instantly and work together on code without having to worry about syncing changes manually.
• Cost-effectiveness: Cloud development environments can be more cost-effective than setting up and maintaining a local development environment. This is especially true for small teams or individuals who don't want to invest in expensive hardware or infrastructure.
• Security: Code is not physically stored on the device that interacts with the cloud environment. This is convenient for data-loss protection. However, it also means that you sometimes don't own the underlying infrastructure where the environment is running, which needs to be taken into consideration.

Summing it all up, cloud-based development environments exist to break from the boundaries imposed by hardware.

Introducing Gitpod

Gitpod, unlike many DevOps tools, was not named after some mysterious Greek expression. Let’s take advantage of that to explain its features.

No need to explain Git today, that would be the job of another article. It’s there to symbolize the integration of Gitpod to popular development collaboration platforms such as GitLab, GitHub, or Bitbucket.

Pod on the other hand references the smallest deployable unit in Kubernetes. Pods are used to manage the lifecycle of containers, provide networking and storage resources to containers, and ensure high availability and scalability for applications. This pretty much gives away the gears that make Gitpod (using K8s pods).

Using Gitpod

Here’s a small diagram explaining the core of Gitpod :

After creating an account linked to your git platform account (Github here), you can choose a repository to create a Gitpod workspace.

When creating the workspace, you need to choose how you want to access your code. This can be through the browser using the browser version of VSCode or any of the supported desktop editors (VSCode and the JetBrains IDEs).

Creating a Gitpod workspace will launch a pod in a multi-tenant Kubernetes cluster managed by Gitpod’s infrastructure. The pod will then run a Docker image that pulls your repository.

After this, you will be either guided by Gitpod to open the workspace in your IDE or directly access it through the browser. You can start coding right after!

As this is a discovery article, we will analyze Gitpod on the four different aspects that we defined as important: deployment, configuration, operator experience, and user experience. To illustrate this section, I will refer to a repository I own with which I tried GitPod.

Deployment

Rating: 4/5

This section focuses on deploying the tool we are covering. We dedicate a part of our analysis to this step because while some tools may seem promising, a painful deployment process can change our recommendation decision.

Gitpod’s offer is SaaS for versions that are not “Enterprise” and their self-hosted version is now only available as part of the “Enterprise” plan. We will therefore focus on the SaaS version of Gitpod in our article.

For SaaS services, we consider that there is no deployment to be made by the customer, hence making this part obviously easy.

As a potential user, it's important to estimate whether using GitPod for your organization will save you enough time to justify the cost. On the positive side, the pricing is not too aggressive. As of May 2023, a team of 10 using GitPod for 25 hours per week on standard instances costs 360€ per month excluding VAT.

Operator experience

Rating: N/A

By operator experience, we mean the ability of a nonuser technical person to operate the service, so that users can use it.

As for deployment, we consider operator experience to be natively easy for SaaS services.

Configuration

Rating: 5/5

Configuration is how the user can configure the usage of the service for his own use case.

Configuration is done using a .gitpod.yml file. In it, you can define build and start up commands for your application.

Here is the file created:

tasks:
  - init: |
      npm install
      docker compose build
    command: docker compose up

ports:
  - port: 3000
    visibility: public
    onOpen: open-preview

vscode:
  extensions:
    - esbenp.prettier-vscode

github:
  prebuilds:
    master: true

First, a task is composed of an init and a command section, init is understandably launched before the command. The reason is mainly related to prebuilds, which is an option detailed below that we’ll explain right after.

It’s possible to open ports on your pod in order to share the development version of the app being worked on with your colleagues. Two access levels are available :

• private, which gives access to the port to all users allowed to access the workspace
• public, which gives access to anybody having the URL

IDE-specific options can also be set up such as mandatory extensions. Installing Prettier on all pods in our case makes sense to keep our code formatted uniformly.

Prebuilds can be set up to speed up pod provisioning. The rationale is that when a new version of your application is pushed, some steps can be done once and reused like the npm install && docker compose build step in our case. Enabling them on the default branch for example will speed up all pods created from this branch, which should be the majority when working in a trunk-based flow.

The documentation details all the possible configurations.

By design, this configuration is distributed by the code repo you use gitpod on. It’s really easy to come up with a working configuration for your project. In the end, they have made the configuration of your remote environment very easy.

User experience

Rating: 4/5

Finally, user experience is the ability of the user to use the service

Gitpod's user experience is centered around making development as seamless and efficient as possible (deploying a workspace with Gitpod is a breeze). One of the key drivers behind this is the ability to work remotely or locally, ensuring that developers have the flexibility to work in a way that suits them best.

This also means that developers can have the same environment as their teammates, making collaboration easier and more efficient. And the VSCode’s extension makes linking your workspace to your IDE easy.

They also have a browser extension that displays a Gitpod button on different places of the GitHub interface. It appears for example in the repository and in issues. Click on the Gitpod button in an issue automatically creates a branch for this issue and launches a workspace targetting it. This makes working on issue-based repositories very convenient.

Another benefit of using Gitpod is that onboarding new team members is much easier. With Gitpod, new developers can get up and running quickly, without having to worry about setting up their own development environment. This is especially helpful for teams with a mix of experience levels, or for teams with developers who may have slower or older computers.

Overall, Gitpod's focus on user experience helps to ensure that developers are able to work efficiently and effectively, without being held back by technical issues or limitations. This makes it a great tool for growing your dev team in an environment.

The only drawback we see is getting used to a remote development environment, which should encourage developers to push often due to the ephemeral nature of the pods.

I also encountered a strange issue with the free tier of Gitpod while writing this article. Before writing, we had extensively tested the tool. According to their pricing page, they offer a 50-hour/month free tier. However, when we tried to run a new workspace months after our initial testing, we received a billing error because we had not set up any payment methods on our account.

Conclusion

From this article, we can conclude that if you have the money and do not have a problem using third-party infrastructure to develop your code, Gitpod will suit you fine! Maintaining the self-hosted solution would have convinced us to recommend this tool to any team wanting to have shared development environments.

If you have access to a Kubernetes cluster, I recommend checking out DevSpace. DevSpace offers similar features to Gitpod but is open-source and self-hosted.