Release Management

Hero image for Release Management

In order to release a new version of an application, it is required to combine branching and tagging techniques.

Release Pull Request

  • Check out a release branch from the develop branch. Naming for the branch should follow the pattern release/<version number> e.g. release/1.0.0.

  • Open a pull request with the release branch as origin and the main branch as destination. Naming for the pull request should follow the pattern Release - <version number> e.g. Release - 1.0.0.

  • The description of the pull request must abide by this template:

    Release Pull Request Template

    • On the first line, include the link to the GitHub milestone or the release on the project management tool to make it easier for reviewers to get the complete requirements:

      # Github milestone
      https://github.com/nimblehq/git-templates/milestone/41?closed=1
          
      # Clubhouse
      https://app.clubhouse.io/acme/label/12345
      
    • Features: provide the list of features in the release.
    • Chores: provide the list of chores in the release.
    • Bugs: provide the list of bugs fixes in the release.
  • Once the pull request is approved and the test suite has run successfully, merge the release branch.

We follow Semantic Versioning for all projects; starting from *0.1.0- to *1.0.0- (or above) at the pace of one minor release per sprint.

Tagging

Once code is merged into the main branch, we keep track of versions by using git tags.

  • Add a tag locally corresponding to the version released from the main branch e.g. git tag -a 1.0.0.

  • Add a changelog in the commit message for the tag following this convention when entering the interactive mode:

    • List changes as a bullet point list
    • Group changes into sections for each issue type:

      Features
      - [ch682] As a user I can view the list of job positions (#125)
      - [ch683] As a user I can view the details of a job position (#128)
            
      Bugs
      - [ch688] Fix: Login with LinkedIn (#126)
            
      Chores
      - [ch678] Set up staging environment (#127)
      

      Having the pull request ID is preferred but not compulsory. On Github, the ID is parsed and linked to the pull request making is useful.

  • Push the newly added tag to the remote with git push --tags.