Release Process is a structured process with planning, scheduling, and controlling the project in each stage or environments with testing and deployments. It makes deployment stable and smooth.
Release management is required for new projects or even changes to an existing project. To prevent delays and last-minute issues with releases, we need to follow the release process systematically.
Release Process Components
A specific release process from project planning to delivery
The definition of release standards, types, and requirements for the release process
A single and repeatable workflow for release process that includes human and automated activities
Activities involved to deploy a release to production
Include many release units that have higher and critical business impact
Includes release units that do not include critical components
Design the release model based on the customer’s requirements. In the existing process checkpoints, validation and verification are not seamless. So, customized the release model to overcome these challenges. Here is the comparison table for the release process versions.
In version control systems, Branching is a technique that makes a copy of source code.
In this Release model, master contains the production copy. Create a Develop branch–copy from master. Develop branch contains all the developed components. In Agile model the stories are aligned with Sprints. So, create a sprint copy from the develop. Based on the stories the developer needs to create their own user story branch from sprint copy.
Once the developers complete their stories, they need to create a pull request from their story branch to sprint copy. The reviewer takes the responsibility to review and merge the code.
The develop copy contains all the completed sprint copies. Once we plan for higher environment release, we need to create a release copy from develop. Based on the project release, we can also create a release copy from sprint itself.
Importance of Branching Strategy
- Provides the better code management. We can track the changes by time, person and versions.
- Developers can work on their stories independently by creating separate story branch.
- Work between current and existing tracks easily because maintaining the code by versioning.
- collaborates better and spend less time managing version control and more time developing code.
- Merging will happen only via pull request that give checkpoint to review the code.
- Proper branching will provide a smooth development and fast release.
Once the developer has cloned their branch into local, they need to install the git-hook(pre-commit) script. It is used to track the current committed components in a text file called manifest.txt. Also, it generates the runtests.txt file. There, the developer needs to maintain the related test classes to get the successful deployment.
- Automatic change log
- Key file for any build jobs used to generate the package.xml
- Can be modified manually if required
- Developer must list down the test class
- Key file for any build jobs, used to generate the ant build.xml file
- Need at least one test to run the build
Release Process Overview
Source Code Management (SCM):
Source control is the practice of tracking and managing changes to code. It provides the history of code development. Each version will be shown with the time and includes the person’s name when made the change.
Developers complete their tickets and create a pull request from user story branch to sprint branch. Once they create a pull request, Jenkins Dev-Int validate job will get triggered automatically. Reviewers will review the code and merge the pull request only when Dev-Int validate job gets success. Based on the job status, the reviewer starts to review the code and merges the user story copy into sprint copy. At the time Dev-Int deploy job will get triggered and the components present in sprint branch will get deployed to Dev-Int sandbox. QA validate job will get triggered once Dev-Int deploy job completes successfully. After the QA validation is ‘success’, QA person will request DevOps team to deploy the sprint branch components to QA sandbox. DevOps team will deploy and notify that to QA person about the success or failures. After completion of each sprints, they will be merged with the develop branch via pull requests.
The successful completion of sprints will be merged in to the develop branch. A release branch will be created from the develop branch when we need for higher environment deployments.
Roles and Responsibilities:
- Track the changes over source code using SCM.
- Helps to find and fix the defects fast during the deployments.
- Test classes are mandatory to deploy the component from the lower environment onwards. So, developers can find the test failures in early stages.
- Increases the code coverage.
- DevOps takes the responsibility to do the manuals. Developers needs to document the manuals in teamwork or confluence. So, it will reduce the chances of missing the pre/post manuals.
- Increases the productivity.
- In CI server, the DevInt deployment and QA validation are automated one. It will reduce the overall deployment time.
Risks (If missed to follow)
- No track on changes
- Overwriting each other’s changes
- Risk of missing manual changes
- Less productivity
- More defect
- More rework
Release management presents a tremendous opportunity to drive continuous improvement in software delivery throughout an enterprise. It provides greater visibility and traceability throughout the release.