Track changes to your deployments and roll back to previous versions
Versioned deployment properties
Deployment Property | Versioned |
---|---|
description | |
tags | |
labels | |
entrypoint | |
pull_steps | |
parameters | |
parameter_openapi_schema | |
enforce_parameter_schema | |
work_queue_id | |
work_pool_name | |
job_variables | |
created_by | |
updated_by | |
version_info |
Unversioned deployment properties
Deployment Property | Versioned |
---|---|
name | (immutable) |
schedules | |
is_schedule_active | |
paused | |
disabled | |
concurrency_limit | |
concurrency_options |
git
CLI commands as a best effort to discover these values.Environment Variable | Value |
---|---|
GITHUB_SHA | Commit SHA |
GITHUB_REF_NAME | Branch name |
GITHUB_REPOSITORY | Repository name |
GITHUB_SERVER_URL | Github account or organization URL |
version
deployment propertyversion
to your deployment is not required, but using human-readable version names helps give meaning to each change you make.
It’s also valuable for quickly finding or communicating the version you want to roll back to or promote.
For additional details on how Prefect handles the value of version
, see deployment metadata for bookkeeping.
pull_steps
and job_variables
define what repository or image to pull when a flow runs, updating their contents with each code change keeps deployment versions in step with your codebase.
Which of these configurations to use depends on whether you are pulling code from Git or storing code in Docker images.
The examples in this section use GitHub as their source control management and CI platform, so be sure to replace URLs, environment variables, and CI workflows with the ones relevant to your platform.
You can check out complete example repositories on GitHub for executing specific code versions when pulling from Git and pulling Docker images.
git_clone
deployment pull step and GitRepository
deployment storage class offer a commit_sha
field.
When deploying from a Git repository, provide the commit SHA from your environment to your deployment.
Both approaches below will result in a deployment pull step that clones your repository and checks out a specific commit.