LogoLogo
HomeAbout usSign up
  • Introduction
  • AttentionSet
    • AttentionSet Best Practices
    • How to View AttentionSet for Others
    • How to Manually Change Attention
    • AttentionSet Chrome extension
    • Attention reasons
    • AttentionSet Slack Home Page
  • Releases
    • Getting Started with Releases
    • Concepts for Releases
      • Terminology for Releases
      • Two-step delivery
      • Rollbacks
      • Cherry-picks
      • Dogfood, Canary and Rollout
      • Release notes
    • How-to Guides for Releases
      • How to Create a Release Project
      • How to Configure Environments
      • How to Create a Scheduled Release
      • Create Custom Workflow Parameters
      • How to Manage Cherry-Picks
      • How to Resolve a Cherry-Pick Failure
      • Working with your CI / CD
        • GitHub Actions workflow
        • Buildkite workflow
    • API Reference for Releases
  • FlexReview
    • Getting Started with FlexReview
    • How to Onboard a Large Org
    • Concepts for FlexReview
      • Read-Only Mode in FlexReview
      • Recursive Ownership in FlexReview
      • Reviewer suggestion and assignment
      • FlexReview Teams and SLO Management
      • Validation in FlexReview
    • How-to Guides for FlexReview
      • How to Get a Reviewer Suggestion
      • How to Exclude Reviewers
      • How to Set Up Team Rules
      • Whitelist Teams for Review Assignment
      • Troubleshoot Reviewer Assignment
      • PagerDuty Integration for Reviewers
      • How to Set Up FlexReview Validation
      • Recommended Slack Notification Settings
      • How to Exclude OOO Reviewers
    • FlexReview Reference
      • Configuration
      • Slash commands
      • Expert scoring algorithms
      • Slack Notifications
      • Out of Office User Exclusion
    • FlexReview Roadmap
  • MergeQueue
    • Getting Started with MergeQueue
    • Merge Rules
    • How-to Guides for MergeQueue
      • How to Configure Base Branches
      • How to Customize Required Checks
      • How to Set Up Fast-Forwarding
      • How to Set Up Pre-Queue Conditions
      • How to Queue / Dequeue via API
      • Pause / Unpause Queues via API
      • Slash Commands Using GitHub Comments
      • How to Customize Sticky Comments
      • Require an Aviator Status Check
      • Backport a PR
      • How to Configure ChangeSets
      • Custom Integrations
        • GitHub Integration
      • How to Create Personal Access Tokens
      • How to Set Up SAML Configuration
        • Microsoft Active Directory
      • How to Merge Stacked PRs
      • How to Block Pull Request Mergeing with Slash Commands
    • Concepts for MergeQueue
      • Queue Modes
      • Pull Request Lifecycle
      • Analytics
      • Parallel Mode
      • CI Status Requirements
      • MQ Created Branches
      • Batching
      • Managing flaky tests
      • Fast-forwarding
      • Pre-Queue Conditions
      • Sticky Comments
      • Backporting
      • Paused Queues
      • Affected Targets
        • Directory-Based Affected Targets
        • nx based affected targets
        • GitHub Actions based Affected Targets
      • ChangeSets
        • Global CI Validation
        • ChangeSets FAQs
      • Priority Merges
        • Instant Merges
      • Merge Rules Audit Trail
      • Timeline
      • Ready Hook
      • Reduce Queue Failures From Staleness
    • MergeQueue References
      • Configuration Schema
      • Configuration Reference MergeQueue
      • GitHub Slash Commands
      • Status Codes
  • Stacked PRs CLI
    • Quickstart for Stacked PRs CLI
    • CLI Installation
    • How-to Guides for Stacked PRs CLI
      • How to Create Stacked PRs in CLI
      • How to Navigate & Modify Stacked PRs
      • Add Commits in the Stack
      • How Split a Commit in CLI
      • How to Split and Fold Pull Requests
      • How to Rename a Branch in CLI
      • How to Adopt a Branch in CLI
      • Orphan a Branch with Aviator CLI
      • How to Do Git Subcommand Aliasing
      • How to Create an Access Token
      • How to Set Up Auto Completion in CLI
      • How to Use Editor Plugins in CLI
    • Concepts for StackedPRs CLI
    • How to Rebase and Sync with GitHub
    • Configuration for StackedPRs CLI
    • Stacked PRs FAQs and Troubleshooting
      • Working with Aviator CLI
      • Default Branch Update Master to Main
    • Manpages for Stacked PRs CLI
      • av(1)
      • av-adopt Command Guide
      • av-auth-status(1) in CLI
      • av-stack-branch(1) in CLI
      • av-commit-create(1) in CL
      • av-stack-diff(1) in CLI
      • av-fetch(1) in CLI
      • av-git-interaction Command Guide
      • av-init(1) in CLI
      • av-stack-next(1) in CLI
      • av-orphan Command Guide
      • av-pr-status(1) in CLI
      • av-pr-create(1) in CLI
      • av-stack-prev(1) in CLI
      • av-stack-reorder(1) in CLI
      • av-reparent Command Guide
      • av-restack Command Guide
      • av-commit-split(1) in CLI
      • av-switch Command Guide
      • av-stack-sync(1) in CLI
      • av-stack-tidy(1) in CLI
      • av-stack-tree(1) in CLI
    • Aviator CLI Major Releases
      • Aviator CLI v0.1.0 Release Notes
  • Aviator's Chrome Extension
  • Pilot Automated Actions
    • Scheduled Events
    • JavaScript Execution
    • Pilot Automated Actions Reference
      • GitHub Reference
      • MergeQueue Reference
      • Slack Reference
  • API and Integrations
    • Slack Integration Guide
    • GraphQL API Quickstart
    • Prometheus Metrics Setup for GCP
    • Reference
      • JSON API
      • GraphQL
      • Webhooks
      • Monitoring Metrics
  • Manage
    • Access Management
    • GitHub App Permissions
    • Security
      • Aviator Agents Data Usage & Retention Policy
    • On-Premise Installation
      • GitHub App for On-Prem
      • GitHub OAuth for On-Prem
      • Use Helm Instructions
      • Use Docker Compose Instructions
      • Prometheus endpoint
      • Slack Integration for On-Premise
      • Google SSO Login for On-Prem
    • FAQs
      • Troubleshooting GitHub app connection
      • MergeQueue FAQs
      • Billing FAQs
Powered by GitBook
On this page
  • Choosing the granularity
  • Release Configuration
  • Project Name
  • Repository
  • Git tag patterns
  • File code path
  • Build Configuration
  • Not configured
  • GitHub Actions
  • Buildkite
  • Editing a Release Project

Was this helpful?

  1. Releases
  2. How-to Guides for Releases

How to Create a Release Project

Follow our guide for instructions on creating a release project with examples. A Release Project is a top-level entity you must build and deploy simultaneously.

PreviousHow-to Guides for ReleasesNextHow to Configure Environments

Last updated 10 months ago

Was this helpful?

A is a top-level entity that needs to be built an deployed simultaneously.

Choosing the granularity

Typically, even in a large micro-services architecture many services may be deployed together. In such cases, all of those will be tied to a single Release Project. If each service is deployed separately, then each of them should be it’s own Release project. Each Release Project can have multiple environments that it deploys to, in which case all of those environments should share the same Release Project.

Aviator recommends making release projects as granular as possible for better manageability.

Release Configuration

Other than the GitHub Repository name, all the Release Project properties are mutable.

Project Name

A readable string representing the name of the project. Do not use any special characters other than -, _ or a space. The project name is only used for reference purposes and is mutable. Each project name within the Aviator workspace should have a unique name.

Repository

Represents the primary GitHub repository containing the project’s source code. This is the repository that Aviator uses to generate the Changelog. When using the GitOps based tool such as ArgoCD or FluxCD, we recommend choosing your application repository as the primary repository.

Each Release Project is tied to 1 GitHub repository, but each GitHub repository can have multiple Release Projects, each of which represent separate Changelog.

Git tag patterns

[Coming soon]

This is an optional field, can be left blank.

File code path

This is an optional field, can be left blank. When left blank, all code changes in the repository are associated with the Release Project. The field is mutable, but it does not update the Changelog associated with the past release versions.

Build Configuration

Not configured

If you want to skip the build step entirely (one-step delivery workflow), you can choose the build step to be “Not configured”. You can also choose this step if you decide to build an entirely API-driven workflow.

GitHub Actions

Since GitHub authorization already provides Aviator access to the GitHub workflows, integrating GitHub actions is fairly straight-forward. Simply select the GitHub workflow that should be triggered for creating a build.

If you do not see your workflow in the dropdown, click on “Fetch workflows” to async fetch the workflow names.

Buildkite

On the Release Project page, configure the Organization slug and Pipeline slug to be able to trigger and track the Buildkite pipelines. Please note that these slugs are case sensitive. No callbacks are necessary to track the workflows in Aviator with Buildkite.

Editing a Release Project

Once a Release Project is created, you can edit all the project configuration other than the GitHub Repository name. None of the changes should impact your existing released versions and changelog. To edit the Release Project, go to the Releases main dashboard, and click on the Gear icon next to the Release Project name.

Aviator autogenerates and publishes to track the Release Candidates. Aviator supports 2 Git tag patterns: and to automatically generate versions for new releases. These versions are not enforced and can be overridden.

A list of glob patterns that presents the file paths associated with the Release Project. This file follows similar patterns to . This is a great way to filter out the changes associated with

If you are using a workflow, the build step should be configured here. A more detailed explanation of each supported CI is explained in the .

Note: Please read the full to configure the GitHub workflow parameters and callbacks to ensure your build and deploy workflows can be tracked in Aviator.

Aviator uses Buildkite to trigger the Buildkite workflows. Please read the to understand how to configure the access tokens with the right permissions.

Once the Release Project is created, next step is to .

Git-tags
Semver
Calver
gitignore
two-step delivery
CI specific pages
GitHub Actions guide
API access tokens
Buildkite setup guide
set up the environments
Release Project
Build step with GitHub
Build step with Buildkite