{{announcement.body}}
{{announcement.title}}

Git Strategies for Software Development: Part 2

DZone 's Guide to

Git Strategies for Software Development: Part 2

Developing multiple program releases or features in parallel shortens overall development time and increases productivity.

· DevOps Zone ·
Free Resource

Please go through the earlier article before reading this article. I will assume the strategy defined in first article is clear before reading ahead. This article will focus on multiple releases in parallel. A software team working on two or more releases at a time may refer to this strategy.

Screen Shot 2019-07-16 at 1.11.36 AM


Let’s consider two releases starting in parallel from today.

  • Release1: 1-month release date from today.

  • Release2: 2-month release date from today.

First, we should create two release branches from production deployed codebase.

Release1: Branch1 is the branch for Release1.

Release2: Branch2 is the branch for Release2.

For simplicity, obvious branch names are used. Typically you will define a naming convention for branches based on your project needs, but a sample name convention can be “ProjectName_ReleaseName_Year_Month_date_Version.”

Once branches are created for release, the development team can start development on features specific to each release by creating a feature branch from the release branch and following a merge strategy as mentioned in single release development.

A key point to note is that we have to regularly pull changes from the master branch to get any production fixes done during the release development time.

Once feature development is complete, we have to get it merged to the release branch after the review cycle.

The merged release branch should get tested by the QA team by creating a release tag from the release branch. Normally we would have multiple QA tags created to test all the features going in a release. Once QA team validation is complete, the release team or QA team should create a final release tag.

Note: We should avoid having the development team create tags from the release branch. The release team should handle such task; if you don’t have a release team, QA can pitch in. 

TagR1 is final release tag created for Release1 from Release1-Branch1. Release1 should be released in production from tag “TagR1.”

Post-release, we have to merge the “TagR1” code to the Master branch to keep the Master branch up to date with production code. “TagR1” should be used for any production fix, after Release1, if needed.

Once Release1 is complete and the code for Release1 is moved to Master branch, “Release2-Branch2” branch will get all the changes done in production through a regular pull request from the Master branch.

Release 2 can follow the same approach done in Release1 for feature development.

Create a final release tag, “TagR2,” and move the code to production, and after release, merge Release2 code to production.

This approach will give us the flexibility to run multiple releases in parallel and handle any changes in the release plan.  In conclusion, here are a few points to remember during the release cycle

  1. Define proper naming conventions for branch and tags best suited for your project.
    1. The branch name can be “ProjectName_ReleaseName_Year_Month_date_Version
    2. The tag name can be “Release_Year_Month_date_version
  2. Post-release activities like marking a tag as released, merging the final tag code to the Master branch, and margining all development branch code with new production code, should be done without fail to avoid any confusion.
  3. The development team should refrain from creating tags, maintaining branches or any release activities. It is advisable to have a release team for such activities.
  4. Follow the proper branch creation and merging process even for small changes in the codebase.

Finally, please refer to this page for useful git commands.

Thanks for reading. Please leave a comment or advice for this or future write-ups.

Topics:
devops, git, git and github, parallel deployment, release, release management

Published at DZone with permission of Dharmendra Rathor . See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}