Promoting between environments

Tasks, runbooks, configs, resources and schedules can be promoted via the UI, CLI and Deployments. Promoting allows you to to initialize and/or sync an entity across environments. For example, the same task definition that depends on a set of configs and/or resources can be deployed to multiple environments. When the task is run in a specific environment, it will run with the config/resource values specified in that environment.

You can promote tasks via the CLI by appending --env <env_slug> to your deploy command:

bash
Copied
1
airplane deploy ./slug.task.yaml --env your_env_slug

A recommended approach is to deploy your task to your development environment, test that it works properly and then deploy it to your production environment.

You can promote tasks via the UI by selecting promote in the dropdown menu for the task. You can select the environment you would like to promote to via the dropdown in the modal that pops up.

You can set up different git branches to deploy to different Airplane environments.

A recommended approach is to configure two separate branches for your development and production environments. Changes can be merged to your development branch and then merged into your production branch once they are verified.

The GithHub integration allows configuring a different git repo and branch per environment. To do so, navigate to Git repositories and change the active environment in the environment dropdown. The configuration you see reflects the configuration in the currently selected environment.

The GitHub action takes an optional env input that can be used to specify the environment to deploy to.

When Deploying from another CI/CD system, you can specify the environment to deploy to via the --env flag just like you can with the CLI.

While the examples here only focus on tasks, they apply to all entities in the Airplane platform, including runbooks, configs, resources and schedules. Configs can be manipulated via the CLI using the same --env <env_slug> argument and can be promoted via the UI. Runbooks, schedules and resources can be promoted via the UI only (since you cannot manipulate them via the CLI).

Tasks, runbooks and other entities are entirely isolated from one another between environments. Edits made to an entity in one environment will NOT be reflected in other environments until the entity is explicitly promoted.

Any resources and/or configs used by a task or runbook must also be promoted if the task/runbook is promoted to a new environment. If you want to change the values/configurations of resources and/or configs in a new environment, first promote the resources and/or configs to the new environment and then update their configuration.