"Mastering Chaos: A Guide to Seamless Release Management with Automated Release Notes"

In a distributed application environment there are often more than 20-30 different components that work together in the application flow. It's always a struggle to manage the releases and get a view of which components are part of the release and what changes are being deployed as part of the release. In this article I would describe a practical approach towards release versioning and generating the release notes.



Existing Pain Points

Here are some of the pain points with managing releases in a distributed application environment

  •  How do we identify the components that are part of the release?
  •  How do we identify the version of the components that need to be deployed?
  •  How do we know what changes are part of the release?
  •  How do we generate the release notes automatically?


Approach

Follow Github flow instead of Git flow

Choosing the right branching strategy is extremely important for release management. In the traditional git flow model development teams create several git branches like master, develop, release. New features would be developed on the feature branches and merged to the develop branch. They would use an existing release branch or create a new release branch every time they want to do a release. And, after the release, code would be merged into the master branch. This approach is tedious and it slows down the teams as they have to deal with many branches and requires manual effort of creating the release branches and merging the branches.



With the github flow there is just one master branch (or develop branch) and feature branches. New features are developed on the feature branches and are merged to the master branch. With github flow branching strategy latest code is always available on the master branch. There are no separate develop, master or release branches. This allows us to create tags and version the releases.


Versioning

Below diagram explains the build and release process which would also allow us to version the releases. 

DEV is integration environment used by the developers for verifying their changes. Test environment is used by the QA for testing the stories. Stage is the environment for UAT and Regression testing. And Prod is the production environment.



Process flow


 1. Developer would create a feature branch to work on a story

 2. Once the development is complete they would raise a pull request for the code review

 3. After the pull request is approved feature branch is merged into the master branch

 4. At this point a build is initiated (manual or automatic) which would 

  • Build the latest code from the master
  • Create a git tag with a version number
  • Deploy the code into the Dev env




5. Developers would verify their changes in the Dev environment



6. Once the changes are verified, developer would initiate the build, this time from the tag, to the Test env. Now we know the component and the version that is deployed on the Test environment.



7. This process would be followed for every component in the application. CI/CD tool should be able to provide a view of the components and their versions deployed to any environment.

8. At any given time we can compare the snapshots of the two environments to identify the delta between the two environments and come up the list of components that would be part of the release.








Comments

Post a Comment