Faster development environments with Gitpod.io

Setting-up new dev environments or trying to refresh your local machine for different projects when configurations are different honestly sucks.

The amount of time other developers and I have spent trying to debug nodejs version issues, installing and uninstalling different SDKs, and finding and setting up environment variables and secrets, is just insane. So I searched for a long time, hoping there was a better way, and I found my answer last year!

The solution I was searching for had to meet all of my requirements, and I wanted to ensure that whatever answer I found or setup used would be a good return on investment. If that weren't the case, it would be at risk of being another tool that goes unused.

My Requirements

• Be able to run IDE and software locally
• Ability to do public DNS port forwarding (replacement for ngrok)
• Composable & repeatable environment
• Usable for work and personal
• All-in-one environment (database, queues, etc..)
• Environments differ per branch and per code repo
• Run multiple environments & Repos concurrently
• Easy onboarding for new staff

Wow, that's a pretty extensive list! There are some things I may have missed there, but you get the picture.

The old way

My existing setup, similar to most, was a local install of a database (or 3), SDKs, and HTTP servers. Sometimes our apps have to run on a different operating system than our other tools for whatever reason, so we may have to utilise shared physical servers or set up a virtual machine locally or in the cloud. Sometimes we use docker to host or compose our environment to host the app and tools.

It's a lot of work just to think about that, let alone changing our configurations every time we start something new or change jobs. Sure, we can use all cloud services and deploy to the cloud only, but then debugging becomes a CI/CD round-trip hell hole where you just burn time.

Some of the options

Docker

Use docker locally and encapsulate all tools in docker. But what about the local SDK for the app? Okay, let's put that in the container as well. Now our build gets more complicated, and it may be different from what actually runs in production. It's hard to debug, and we have to do more work for port forwarding and just run the app in general.

Virtual Machines

Sure it'll work fine, but a new virtual machine setup every time? No Thanks.

GitHub code spaces

It seems okay, but the pricing is too expensive.

Gitpod.io

A big free tier, composable environments per branch and repo, database available, utilise docker like a VM and host IDE inside (well sort of), public DNS accessible...it seems to be ticking the boxes.

Get Started with Gitpod.io

Getting started with Gitpod is super simple, especially if you have a GitHub, Gitlab, or bitbucket account, as it will use that for SSO.

All you have to do is type https://gitpod.io/#, and Gitpod will automatically load a workspace for that repo, even if you aren't the owner of that repo. It is very helpful if you find a repo you want to test but want to avoid the local setup.

You can also supply it with a full branch path to launch directly into!

For those who have used VS Code, you'll be greeted with a very familiar experience, with Gitpod hosting an instance of VS Code Server for you to use as your IDE in the browser.

Test this out with my template repo for Next.js. Here is the same project on a branch so you can run it side by side.

I won't go into details here about the configuration of the .gitpod.yml file. It is covered in detail in the Gitpod's docs

Accessing the app from Gitpod

Now that your environment has launched, you can run the app in the terminal just as you usually would. The app will already have started if you have opened the starter repo above. The prompt will appear with the option to open the URL.

You will also be able to see any ports that are forwarded, the URL they are accessible on, and the port's privacy state, e.g. private or public.

Adding in tools

Adding tools into a workspace on Gitpod is a simple process. As it uses docker and is compatible with Dockerfile inside the repository, you can use whatever docker file you like as a base configuration which means your imagination is the limit. You find the in-depth documentation here.

You can also configure different startup and initiation scripts to run inside the .gitpod.yml file.

Environment Variables

There are many ways to define environment variables in Gitpod. One of the simplest ways is through Account Settings/Variables, which allows you to persist environment variables shared across repositories or scoped down to user/organisation or a specific repo.

Another fantastic feature is the ability to supply environment variables as URL parameters. Personally, I believe this has some great benefits. For example, you might set up an environment variable to automatically create seed/sample data so that a non-technically user can test a feature or even just for developers to have a comparison environment to test against.

The value passed as CUSTOM_URL_ENV_VAR displays on the app's home page on startup, or if not supplied, the element will hide automatically. Try it out for yourself!

https://gitpod.io/#CUSTOM_URL_ENV_VAR=here is the variable passed in the url/https://github.com/TheOptimisedWeb/gitpod-nextjs-typescript-template/tree/showoff-branch

Local IDE & Handoff

With Gitpod running an instance of your workspace in the cloud, the need for running a local IDE is almost redundant. The browser-based VS Code works almost identically.

However, connecting up a local IDE is 100% supported. It uses an SSH plugin to tunnel the data and make it look and feel like the repo is running locally but with all the benefits of Gitpod.

Since your workspace is running in the cloud, device handoff is seamless. You can access the same workspace on multiple devices simultaneously with no commits or data loss. In addition, if your workspace shuts down, any uncommitted files are saved in a snapshot that you can reopen later.

Conclusion

I didn't think a single solution would work exactly how I wanted, but Gitpod tickets every box.

The only downside that I'm sure you'll pick on is "but you must be connected to the internet" sure, that is a valid point. But, still, seriously, think about how often you are doing development properly without an internet connection. I bet it isn't often.

I started writing this blog post on my 4-year-old iPad inside gitpod.io from a restaurant in Japan, taking full advantage of the free wifi. It gives an idea of how crummy an internet connection and hardware can be and still have a great development experience.

Gitpod may not be for everyone or every team, but do yourself and your team a favour and at least give it a try to see if it is a fit.