[rust] zero2prod Build Log 01 - Environment - Gitpod

After I got my first job as a software engineer, my practice time kept shrinking. At work I sometimes want to try things out in the odd free moment, but my code sits on the computer at home. A few small websites let me run simple snippets. I wanted something better: a cloud environment where I can pick up a project and carry on. That is how I found Gitpod. GitHub Codespaces is a similar tool.

I gave Gitpod a try, and by then I was also a little more comfortable with Docker. Cloud development turned out to be a good experience, so I decided to rebuild this project on Gitpod from scratch. Last year I made a grand promise that I would write articles again. Winter is almost over, and only now do I get back to it XDD

How Gitpod works

Gitpod starts a development environment in the cloud. At startup it pulls the code from a repo on GitHub or GitLab. The free plan only works with public repos. Gitpod also ships a Chrome extension that lets you start Gitpod with one click. After you enter Gitpod, the browser opens your repo in a VS Code interface, and you can start work right away. It is very simple!

Look at the terminal. Gitpod already ran some tests when I entered the workspace. The project is still empty, so the test count is 0. A script configures this part. On the left you can also see the extensions that Gitpod installed. The extension settings appear to follow the account, because the same extensions come along when I open other projects.

There are other panels besides the terminal, and most of them are familiar. During development I used the ports panel a lot. I start the services that I need with Docker, and the panel shows me clearly which port I must connect to for each service.

gitpod.yml

The first time you open a project, Gitpod asks whether you want to add a gitpod.yml. This is a very powerful Gitpod feature. You write a script, and every time Gitpod prepares the environment again, it follows the commands in that script. I also heard that this company does viral marketing: it opens a gitpod.yml pull request on every project, which is honestly a bit obnoxious.

The gitpod.yml is genuinely useful when several people work on the same project. If you have ever fought an environment problem, you know how much it hurts. The same code does not run on a different machine. You debug it step by step. A whole day is gone.

Of course, a shell script is enough if you only need to prepare the environment. But Gitpod lives in the cloud, so I can easily get ready to develop in a different place.

Task

A gitpod.yml consists of tasks, and one yml file can hold many tasks. Unless you configure something else, all of the tasks run at the same time during startup. The example below starts the database and the application together.

tasks:
    - name: run database
    - name: run app

A task has three phases.

1. before - runs first. Use it for the global settings of the environment.
2. init - downloads the dependencies of the project. It can also run the tests before the project starts.
3. command - starts the compiled project or another program that must run. If you turn on the prebuild feature, the environment gets ready faster. The official site has a diagram that explains the three phases.

Each phase takes a command directly.

tasks:
  - name: test app
    init: cargo build
    command: cargo test

A command can also span several lines. For example, you can use sqlx to run a database migration the first time that the project starts.

tasks:
  - name: database migration
    init: |
        cargo install sqlx
        sqlx migration run
    command: cargo run

As I said above, a yml can hold several tasks. You can decide whether each task waits for the others. You configure that part through the Gitpod CLI. The gp ports command also exposes a port to the outside, which helps with testing. The CLI tool offers many features that are worth a try. Finally, you can even add VS Code extensions with a vscode: block in the yml.

vscode:
  extensions:
    - svelte.svelte-vscode
    - [email protected]
    - https://example.com/abc/releases/extension-0.26.0.vsix

Thoughts

Take the project that I want to practice on. It has a backend and a database. The script can pull the Postgres Docker image and start it when Gitpod creates the workspace. Then it installs the sqlx CLI and runs sqlx migration to set up the database schema. When everything is in place, it runs the tests once for me. Gitpod also accepts a Dockerfile, so you can package the whole thing and get a ready-to-use environment in the cloud.

Overall the workflow is smoother than I expected, but you must get used to it. Many things require a command in the terminal. The debug tools in VS Code are also less complete, and extra tools are not easy to install on Gitpod. So I split the code into smaller units and wrote tests to debug it. That turned out to be the easier way to work. Gitpod now supports a JetBrains connection, but the browser version of VS Code pushed me into some good habits.

Cloud development also raises new questions. A database connection string does not belong in the repo, so I start a test database with Docker instead. Another option is the Gitpod CLI, which sets environment variables from your own computer. This part needs more thought.