Can you start your development environment with one command? Automate your environments using Gitpod

Lou Bichard Product Manager at Gitpod

May 22, 2024

We are in a relentless pursuit to bring you—and every software company—‘a one command development environment’. That means with one click on a pull request, in your internal developer portal, or from your CLI you can have a full environment to write code, commit and raise a pull request, in seconds.

Caption: Starting a Gitpod workspace from Backstage.

This is what at Gitpod, we call being ready-to-code.

This post is intended to help you understand the main automation features of Gitpod so that you too can always be ready-to-code. We will cover mostly the basics today, but we will also include links for you to dive deeper, if you want.

The challenge with development environments today

While we can spend a lot of time crafting our README instructions, writing shell scripts, or including a makefile in our repository, nearly always something stands in our way when it comes to having an environment ready. That might look like:

• Operating system incompatibility like Windows WSL2 issues.
• Hardware issues like insufficient RAM for docker-compose.
• Hours downloading source code, installing packages and database seeds.
• System access issues like VPN setup or cloud account access.

There’s always something.

And it’s not just getting our environment setup when we join a company. What about when we: change branches? Review a pull request? Swap to a new project? All the development environment pains are back.

Automation is the key for creating your own one command development environment

To fix our development environments, we must automate everything. Right down to having our editors opened, with our code loaded, our application running, and our ports ready to test changes. We need everything from our installed packages, to our network access, to secrets and external systems access setup for us.

Today, we’ll show you how to:

1. Automate installing packages and libraries using .gitpod.yml.
2. Performance optimize development environment using Prebuilds.
3. Automate access to internal resources and access to secrets.

Caption: Opening a Gitpod workspace via CLI

Define your development environment in configuration

The .gitpod.yml is a declarative definition of your development environment, stored at the root of your repository.

Here’s a simple example of what that configuration looks like:

yml

tasks:
    - command: npm install && npm start

Caption: A .gitpod.yml that installs packages and starts the application.

Automate your development environments ports

Specify the ports to open on startup. Here’s how that looks:

yml

ports:
    - name: Web App
      port: 8080
      onOpen: open-browser

Caption: Specifying port 8080 to open in a browser tab on environment start.

When your application starts, you’ll get a notification that your port is now ready to access.

Caption: An example notification of ports opening inside of VS Code.

With desktop editors like VS Code or JetBrains, automatic port forwarding is built-in. Gitpod detects processes running on a port and maps them to a localhost address.

Define your development environment with Docker

For complex setups, use a Dockerfile to benefit from the caching of layers. Add an image reference to your .gitpod.yml that points to a hosted Docker image, or point to a local Docker file and let Gitpod build it for you.

image: gitpod/workspace-full

Caption: A development environment pointing to a hosted Docker image.

image: .gitpod.Dockerfile

Caption: A development environment pointing to a local Docker image.

For more, see Workspace Image.

Test your development environment changes

Test changes within your workspace by running the gp validate command.

This command builds your environment and provides a preview.

Caption: Running gp validate to test configuration updates.

Automate secrets, databases and cloud accounts

A development environment doesn’t simply consist of packages and libraries. It needs access to external systems like databases, cloud accounts, or Kubernetes clusters. Add environment variables through the workspace or dashboard.

You can add an environment variable to Gitpod through the workspace, or dashboard. However, a more secure solution is using the Workspace OIDC integration.

Each environment has an identity token, which includes claims from the integrated SCM and identity providers. You can exchange this token for a short-lived access token from any public cloud provider (i.e. AWS, Azure, GCP) or secrets management tools like Hashicorp Vault.

For example, to fetch an identity token for AWS Secrets Manager:

tasks:
    - command: |
          gp idp login aws --role-arn <your-iam-role-arn> 
          aws secretsmanager get-secret-value --secret-id <secret-id>

Caption: Fetching a secret from AWS from Gitpod

See Workspace OIDC for more.

Automating enterprise development environments with private networking, SSO and more

Finally, a lot of what we have covered today are application-level concerns. In large enterprises, we often have requirements and restrictions around who can access our internal corporate network, we need to use a VPN, or other network level restrictions. Gitpod helps can automate this with Gitpod Enterprise.

Gitpod Enterprise is our single-tenant, self-hosted solution that runs in your cloud account and is managed by us.

See Gitpod Enterprise for more.

Your fully automated one command development environment

With full automation in place, you can now enjoy:

• Not wasting hours every week fixing your environment.
• The security benefits of short-lived, ephemeral cloud environments.
• Multi-tasking on pull requests.
• Share your environment configuration with your teammates.

Now you can launch your development environment in a single command from a pull request, internal developer portal, or CLI.