Terminology for Releases
Read the terminology for the Releases feature. The common terms are important to understand the Release process with Aviator and use the tool more effectively.
Last updated
Was this helpful?
Read the terminology for the Releases feature. The common terms are important to understand the Release process with Aviator and use the tool more effectively.
Last updated
Was this helpful?
Release Project is the top-level entity in Aviator Releases. It refers to software that need to be built and deployed at the same time. Typically, this could be a single service, application, or library, however it could also be defined as multiple services that have to be deployed altogether. Aviator recommend designing the release projects as granular as possible for better manageability.
A Release Project can have one more , and is tied to a unique CD workflows for each of those environments. When cutting a Release, it would trigger a separate CI workflow to build the artifacts that are then deployed to specific environments using the CD workflow.
Each Release Project is tied to 1 GitHub repository, but each GitHub repository can have multiple Release Projects, each of which represent separate .
Each can have one or more Environments that are deployed and managed. Most common examples of Environments are staging and production, but depending on different use cases, there may be additional environments you can configure, e.g. canary, dogfood, pre-production, sandbox, development.
There is no limit to the number of Environments for a Release Project. Each Release Project defines its own Environments, and there is no correlation of same Environments across different release projects.
Changelog is one of the core utilities of Aviator Releases. The Release dashboard records of all the changes as pull requests in a linear history. This way it’s easy to understand which code changes (PRs) are deployed with which and on which . Each Release project has a it’s own
Changelog makes it easier for any engineer to track and understand when their changes were deployed. The Changelog also represents the , and tie them to the corresponding Release and .
Changelogs help users and developers track the progression of the software, understand what has changed from one version to another, and ensure compatibility with other systems or components.
A Release is a snapshot of a commit SHA from the primary branch that is tested and eventually deployed to various environments. A release contains one or more . Each Release is also associated with a unique . A Release is also associated with a git commit SHA, but this association is mutable. That means, as new Release Candidates are created the the git commit SHA for a Release can change.
Each Release has one or more Release Candidates represented by rc1, rc2 and so on. A Release Candidate is always tied a unique git commit SHA and is immutable. There is no limit in the number of Release candidates as Release can have. Typically there is only one valid Release Candidate for any Release at a given time. The default Release Candidate for a Release is represented by rc1.
Aviator does not automatically create Git-tags for the release.
Deployment is an action of taking existing build artifacts and pushing those to a specific Environment. To manage the Deployments via Aviator Releases, you will have to configure Aviator to trigger your a deployment CI or CD workflow. Similar to the Build step, the Deployment step also passes the Release Candidate version and the git commit SHA to your configured workflow.
Each is represented by a unique version that typically follows a pattern. Aviator Releases supports some common release version patterns such as and . But you can also define and maintain your own release version formats.
Release Candidate version is a full string that uniquely identifies both a Release and a corresponding Release Candidate version. A Release Candidate version is created by appending .rc<number> to a . For instance, if the Release version is: 2024.06.20 then the first Release Candidate version will be 2024.06.20.rc1, and second one will be 2024.06.20.rc2 and so on.
To effectively use Aviator Releases we recommend . A build process is where the artifacts are built. A common example of this would be building one or more docker images. To manage the Build process via Aviator Releases, you will have to configure Aviator to trigger your build CI workflow. When triggering this pipeline, Aviator passes the as a parameter along with the git commit SHA to your build CI workflow. This helps uniquely tie the build to a given Release Candidate to generate the artifacts.
Cherry-pick allows you to apply any arbitrary commit on top of an existing Release Candidate to create a new Release Candidate. This is also sometimes called hotfixing. This can be useful in scenarios where you don’t want to cut a new release because there are too many commits being introduced since the last release was cut and you want to surgically hotfix a bug. Find more details on the page.