GitHub Handbook
What is a release?
A release is the distribution of the final version of an application or product. Releases can be made before the end of an iteration and are often the culmination of several iterations. You can create a release to provide packaged software, release notes, and binary files for other people to use.
Release vs. pull request
Unlike a release, a pull request lets you tell others about changes you’ve pushed to a branch in a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before your changes are merged into the base branch. Pull requests should be made early in the development process, sometimes after just one commit, so your work is visible to team members, managers, and stakeholders.
Release management and semantic versioning
Most teams at the VA will tag and name releases following semantic versioning. We have created a separate TL;DR for semantic versioning. Some teams, namely those publishing redacted files for public consumption, will not follow the semantic versioning naming system. If you’re not sure what naming system your team should follow, open an issue.
To learn more about release management, including editing and deleting releases, read managing releases in a repository.
Creating a release
The reading-time-demo example code has a GitHub release done the VA way: reading-time-demo/releases/tag/v1.1.0.
1. Start a VDD Checklist Issue
The VDD is now a checklist that explains the steps you need to complete to create a release: configuration-management/issues/new/choose
2. Create a release
From your code repository, choose Code > Releases > Draft a new release
- Tag your release with semantic versioning:
- For example: v1.3.23
- Include the library name and the version in the release title
- Link to the milestone that contains the work included in this release
- Also link to the comparison of the current to the previous baseline release
- Use GitHub’s compare view in your code repository to choose the two versions to compare
- For example: https://github.com/department-of-veterans-affairs/<repository>/compare/v1.1.0…v1.1.1
- Upload a compiled binary
- Source code snapshot is automatic
Here’s what a completed release looks like.
3. Complete a Release Readiness Checklist
From your Product repository, create a new RRC issue. This should be completed by your product team. It links to the release that you just created, and any required compliance artifacts or user stories.
Automated releases
Releases and their drafts can easily be automated to work towards an efficient CI/CD DevOps model (Continuous Integration/Continuous Deployment). Both the DOTS and GitHub team at the VA can assist with release automation.
| DOTS CI tools | DOTS CD tools | GitHub CI/CD tools |
|---|---|---|
| Actions | Jenkins | Actions |
| CircleCI | ||
| Jenkins |
Get started with automated releases
-
To get started with the DOTS team, visit https://vajira.max.gov/servicedesk/customer/portals.
-
To get started with the GitHub team, fill out the Automation Consultation issue in the
github-user-requestsrepository.