Best Practices

Warm up dev environments

You can significantly reduce the time it takes to start a dev environment by removing the IDE warm-up phase: a period of time when the IDE builds indexes, resolves project dependencies, and so on. To do this, you can use the CodeCanvas warm-up feature. During the warm-up, CodeCanvas creates a dev environment where it runs the IDE and performs all the necessary background activities (e.g., builds the project). The result of the warm-up is a snapshot of the dev environment that includes all the indexes and other data. The snapshot itself is stored in a cheap storage, like Amazon S3.

Warm-up snapshots are an ultimate way to optimize resource usage, as they remove the computational overhead of the warm-up phase from multiple user dev environments. E.g., you can configure creating a warm-up snapshot every day at 3 AM to ensure that the users who start their dev environments at 9 AM receive a pre-warmed environment with the indexes that include all the changes made during the last day.

Learn more

Caution: standby pool

The standby pool is a set of already started dev environments. As all preparations are done, the dev environments in the standby pool are ready for immediate use. When a user requests a dev environment, CodeCanvas assigns them a free dev environment from the standby pool. After the environment is assigned, the pool creates a new dev environment to keep the number of available dev environments at the desired level.

Of course, the standby pool consumes resources, so you should carefully configure it to match your needs. Here are some tips:

• Minimize the number of dev environments in the standby pool to save resources: Run the pool only during the peak hours, e.g., when most of the users start their workday. People don't start their workday at the same time, so, typically, it is enough to have a few dev environments in the standby pool. For example, if you're a medium-sized team that starts working at 9 AM, you can have 2–3 dev environments in the pool that runs from 8:45 AM to 10 AM.

• Use the auto-stop feature: You can configure the standby pool, so that the dev environments in it are stopped right after all startup activities are done. This way, you save resources by not keeping the dev environments running when they aren't used, but still provide a decent startup time.

Learn more

Use cleanup policies

• Delete unused dev environments

  Once a dev environment is stopped, CodeCanvas deletes it and frees all the resources except for the dev environment volume. As the volume is stored in a block storage, this entails additional costs. To avoid these costs, you can configure the maximum period of inactivity after which the dev environments are considered unused and can be deleted, i.e., their volumes can be deleted.

  Learn more

• Convert dev environment volumes to snapshots

  Instead of deleting the dev environment volumes, you can convert them to snapshots. Snapshots are stored in a cheap storage, like Amazon S3, and don't consume resources. You can configure the maximum period of inactivity after which the volumes are considered unused and can be converted to snapshots.

  Learn more

• Delete unused warm-up snapshots

  Warm-up snapshots are stored in a cheap storage, like Amazon S3. However, they still consume resources. To prevent the accumulation of unused snapshots, you can configure the maximum period of inactivity after which the snapshots are considered unused and can be deleted.

  Learn more

Dev container image VS. warm-up VS. lifecycle scripts

When configuring a dev environment template, it is important to understand where to place specific preparation steps: in the dev container image, the warm-up, or the lifecycle scripts. For example, your project requires an SDK. To get the SDK, you run curl - o sdk.zip $SDK_URL && unzip sdk.zip. Where do you put this command: to the Dockerfile, the warm-up script, or one of the lifecycle scripts?

Our recommendations:

The key idea is to run the preparation tasks as rarely as possible. For example, dev container image build is a one-time operation, unlike warm-up, which runs on a schedule. Warm-up, in turn, runs less often than dev environment activations. Below are the limitations and suggestions for each phase.

• Dev container image

  Install all necessary tools during the build phase of the image – Everything that doesn't depend on the IDE or the project sources (as they aren't available at this stage). This reduces warm-up time, infrastructure costs, and web traffic usage. So, the answer to the question above is: put the curl - o sdk.zip $SDK_URL && unzip sdk.zip command to the Dockerfile.

  Learn more

• Warm-up script

  CodeCanvas runs the warm-up script when creating a warm-up snapshot for a specific dev environment template (typically, on a schedule). All dev environments created from the snapshot use the same script results, which saves setup time. The warm-up script runs inside a dev environment container: It has all the tools from the dev container image, the IDE, and the project sources.

  Use the warm-up script for tasks that require the IDE and project sources, such as building the project, downloading dependencies, performing code generation, or indexing the source code. Note that the warm-up script doesn't have access to the user context.

  Learn more

• Lifecycle scripts

  • On activation – Use it for tasks you want to run every time a dev environment is activated, like logging into a Docker registry or tracking work time. Keeping this script lightweight and fast is best to avoid delaying the user's connection to the IDE. Since this script runs in the specific user's context, it can access and use personal parameters.

  • On initialization – Use it to customize IDE settings, such as installing plugins from custom sources or modifying JetBrains IDE XML configuration files at the application or project level. This script runs once, either during the warm-up or the dev environment creation (if the warm-up wasn't used).

  Learn more

Find optimal resource configuration for dev environments

1. Start with the initial resource estimation:

   • Start with your best estimates for memory and disk space requirements. Consider peak usage during IDE indexing and project builds. Learn how to define instance types.

   • Use a custom Docker image tailored to your project to optimize resource usage and memory footprint. Learn more.

2. Perform an initial warm-up to build indexes and compile the project. This helps simulate potential resource usage. Learn more.

3. Apply an iterative approach: Monitor resource usage and adjust the instance types accordingly. Dev environments log a notification when memory usage exceeds 80%.