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.

  • 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.