Just some phrases from the Gitpod website: “Select project, start coding”, “Works on my machine – and yours”, “Always ready to code.”. Those statements make you curious. What’s it all about and what should you know about it? GitPod is the new local developer experience. Suppose you have a new developer joining the team. He/she needs to learn about the project itself, get up to speed in the organization itself, and also set up a local development environment. This can be painful if it’s not exactly the same as every other teammember. GitPod frees up this hassle to offer a fresh dev environment every now and then you need it in your coding tasks.
Introduction
Every local developer environment is different. Companies that have adopted a “Bring Your Own Device” policy understand that every engineer has a strong opinion on which tools he/she needs and the way their system is being configured. Some people prefer MacOs, others demand Windows whereas others love to work with the flexibility that Linux offers them. The number of differences rises when it comes to setting up a local development environment: everyone needs to install the same tools to build software that produces an identical artifact and runtime behavior. Ideally, people run the same shell to stay compatible with each other. And last but not least: the IDE. It’s a great help to share the same IDE for example to adhere to code formatting, debugging options, indentation, syntax highlighting, etc. GitPod changes the way you think about local development environments radically. In this article, I’ll give a smart overview of what it is and where your business can gain traction.
A quick overview
GitPod tunes in the public cloud or you have to host it yourself. So this is a hard requirement for you to consider. It spins up a fresh development environment for every development task you would normally execute multiple times a day (think of code changes, merge requests, etc). GitPod connects to Gitlab, Github, and BitBucket primarily by provisioning so-called workspaces.
Furthermore, it runs solely in a browser so you can work on any device that has a browser available. In addition to that, it claims to have more than 500k+ developers that already use GitPod. The free version is limited to 50h of usage per month, whereas other commercial plans offer more than that. Perhaps the most compelling arguments are the 5h weekly productivity gain of every developer, and the 60%+ cost savings statement compared to a (custom) VDI solution. And last but not least: GitPod claims to be four times faster from zero to the first Pull Request. These statements sound promising. Let’s find out what GitPod brings into practice to make this happen.
Core concepts of GitPod
According to a co-founder who wrote on Stackoverflow, GitPod is a server-side development environment (as code) + prebuilds as well as an IDE and collaboration between developers. At the heart, it’s a Docker container that contains everything you need to develop your application, including a proper IDE, a terminal, VS-code extensions and it’s even possible to run other services such as databases. This concept is linked to your existing Git repository in Gitlab, GitHub, or BitBucket. In fact, it’s a disposable but fully customizable development environment that perfectly fits your application (project).
Let’s break it down in chunks:
- Your IDE runs in a browser whereas your DEV environment itself runs server-side. No more code deployments from your laptop to your target environment. Pair programming with peers is easy and you can also easily share your DEV environment. It’s just a URL.
- Your DEV environment itself is built “as code” just like Infrastructure as Code. When you start writing your code, the environment is already compiled and the dependencies are fetched. Every time you push new code to your Git repository, it builds your application under the hood. In turn, it deploys your workload on the DEV environment. Ultimate CI/CD and a super fluent experience when reviewing Pull Requests.
- Every step of the development process is reproducible and can be shared with the entire team. Collaboration and conflict resolution become much easier.
GitPod is offered as a SaaS solution or you can host it yourself on AWS, GCP or any other Kubernetes cluster. Once you’ve finished your day, you can just throw away your DEV environment, just like you always do when you get rid of a container.
Business justification
Every budget holder needs to have a proper business justification to do an investment. Let’s find out what the business benefits are:
- No initial setup of developer environments thus no differences between individual developers of the product team.
- There is no (recurring) maintenance of the various components such as the IDE itself, no dependency management, no environment-specific configuration, and no messing with access rights on a more restricted developer environment (think of managed DEV laptops).
- This (security) risks of having a security issue in the DEV environment decreases since there are fewer (almost zero) manual configuration steps to be taken.
Cost savings
A hypothetical use case to calculate the (proposed) savings.
Initial costs:
- 50 developers
- Setting up and maintaining a local DEV environment: 2 hours per month per developer
- Average hourly wage: 100 euro
Total costs every year: 50 X 2 X 12 X 100 = 120.000 euros.
Costs with GitPod:
- 50 developers
- Professional plan: 23 euros per month per developer
Total costs every year: 50 X 23 X 12 = 13.800.
Simply said, the cost reduction is about: 120.000 – 13.800 = 106.200 euros each year.
Off course, this is just a very simple calculation that does not take into account multiple factors such as training developers, educating them, writing documentation (to set up a local environment), lost hours due to hot fixing a critical security issue (such as the recent openSSL issue). It gives you a rough idea of what you can expect.
Important terms
Before you acquire a license to try GitPod, it’s good to understand some of the most important terms from the perspective of the core capabilities itself.
- Team: the “container” in which all of the other components live: projects, workspaces, prebuild as well as the team members actually belonging to the DevOps team.
- GitPod projects: a single point of contact between the Git source code repository and GitPod itself. This is one to one relationship. Good to know: projects have a unique URL which also includes the team. Therefore they can be shared easily between members. Besides, billing happens on a “per usage” basis and applies per team. So this also aligns with the adagio “you build it, you run it, you own it” and … “you pay for it”. No more discussions with other (shared) departments whether who should pay the bills.
- Workspaces: these are the actual developer environments in which you program your application. They are based on (predefined) Docker images you would pull from Dockerhub. It’s also possible to build your own images so you would save time using them as a “bootstrapped environment”. Private Docker images are currently in the alpha stage.
- GitPod configuration file. Just like Azure DevOps pipeline definition files and Kubernetes manifests, you would write your GitPod configuration in the YAML format. An example of a GitPod file below shows how to install and run npm every time the workspace is created. This is extremely powerful since then everything is provisioned even before you assign new team members.
tasks:
- init: |
npm install
- command: |
npm startDeployment options
There are multiple deployment options in case you want to try GitPod yourself.
The easiest method is to sign up for the SaaS version. This only requires you to log in using your GitLab, GitHub or BitBucket account credentials. You would need to connect the desired Git source code repository to the GitPod project and customize your workspace after that. The Free plan has a limit of 50 hours a month, 4 parallel workspaces, and a 30 min inactivity timeout.
Consider hosting GitPot yourself if SaaS is not an option for you. There are 2 options here: install the local preview version or install the fully-fledged Kubernetes version. The local preview version is based on a single (Docker) container and this is really only for testing purposes. It comes with a lot of limitations for example the integration with GitLab, GitHub and BitBucket is missing. You need to integrate them manually.
See the self-hosted installation guide for more information on the local review version.
Running GitPod locally with all of the integrations and capabilities requires a complete Kubernetes cluster. Since GitPod depends on a lot of resources and aspects which heavily depend on various features of Kubernetes, it’s not enough to just run a simple test cluster using Minikube or similar. You would require advanced Kubernetes-related knowledge to evaluate the requirements of GitPod. Your Kubernetes cluster needs to be compatible with GitPod, so reference the compatibility matrix. It also requires a CERT manager in your cluster as well as a DNS setup since it requires valid domain names. And last but not least, you need a valid license based on one of the pricing plans.
IDEs and Integrations
No tool is complete with the proper integrations. Tools that run in isolation do not contribute (much) to the CI/CD and DevOps philosophy.
Currently, only VScode is fully supported. However, more IDEs follow either and are already in the Beta stadium. Think of popular IDEs like IntelliJ, PyCharm, and WebStorm. Other IDEs like CLion and Rider follow soon. It’s great to see the expansion of IDEs to facilitate an even more versatile group of developers.
Use your IDE
Typically using the IDE of your choice requires the following steps:
- Install the (lightweight) IDE of your choice, for example, the JetBrains Gateway plugin.
- Install the GitPod plugin in your IDE.
- Configure your GitPod workspace to set your IDE and the default one.
- Start or restart your workspace. This can be done from your IDE or by opening a new workspace which will open your preferred IDE immediately.
Integrations
Another integration point that is worthwhile to mention is Tailscale. This lets you connect your GitPod workspace to other development resources. These can reside on-prem or in the cloud itself. Think of your production message queue or a database that runs behind your corporate firewall. By connecting these resources, you can make the developer experience as smooth as possible. The Tailscale integration is built based on the open-source protocol WireGuard. Tailscale uses a Docker image under the hood to set up the connection to external resources. GitPod 1.32+ enables this feature so be sure to update your version if needed.
Conclusion
As seen in this article, GitPod blends the tools and tasks for developers to offer a smooth developer experience. It connects to your existing Git source code repositories in GitHub, GitLab, or BitBucket. Developers get an IDE that runs in a web browser that connects to a fully-fledged target environment. Writing code and deploying it to a target environment blends into the process of Git push and Pull Requests. Companies save time and money by setting up, configuring, and maintaining development environments. This decreases the time needed to get (new) developers up to speed, reduces the security risks being introduced in local environments, and conflicts are resolved much faster. You can try out GitPod for free or buy a monthly subscription to extend the usage (across teams).
If you have questions related to this topic, feel free to book a meeting with one of our solutions experts, mail to sales@amazic.com.
