Release management (or DevOps) is a growing practice within the IT industry. As computer systems and resources become more distributed, they invariably become more specialized and complex. Software products (especially web applications) are typically “never complete” and are consequently in a continual cycle of development, testing, and release.
Shipping software products from development through to production can be a pain, quite often requiring the input of multiple technical professionals. In this article we explore Release Management and how by implementing a formal release process, you can help improve the delivery of your software projects.
Why implement Release Management?
Manually deploying software can contain an element of risk. A formal release management process removes a lot of the manual overheads associated with publishing and releasing software thereby helping to reduce this risk.
Dynamic Configuration
Imagine you’re deploying an ASP.NET web application, and you may have server-specific settings in the web.config file. These need to change each time a release is published. Configuration changes like these can be a pain to track manually as your site makes its way through each release path. Release Management can remove this pain and handle this for you by parameterizing configuration values at runtime when the release is published in real-time.
Improve the quality of your software
Each time code is checked in by a developer, you can execute a suite of unit tests automatically, analyze the code quality (as per standards defined by the team) and report this back, almost immediately, to the developer that performed the code check-in.
Help you focus on what matters
Release Management allows professionals to focus on what matters. For example, developers can write code and test analysts can write test plans. The near instant feedback loop that release management brings is hard to ignore! Developers can even be notified if a change has broken the build!
Server Environments
A common release management architecture is to have four environments like the following:
- development
- system testing
- staging
- production
As developers complete their work, it makes its way from development, through to production. You may also wish to add a User Acceptance Testing (UAT) environment that sits between staging and production environments. Doing so lets you validate the release “post system test” and allows you to release software only after it has been deemed “production ready”.
You can find more detailed definitions regarding each of these environments here.
[bctt tweet=”A formal release management process removes a lot of the manual overheads associated with publishing and releasing software” username=”GAPapps”]
Source Control
Another important aspect of improving your software deliver using release management is source control. There are many source control products to choose from such as Visual Studio Team Services and Git. Source control lets you manage the workflow of code files as they pass from one developer to another.
Historical Archives
As developers check code in and out of your source control product, the source control repository builds an archive and snapshot of each file with an accompanying changeset id (if using TS) or a commit id (if using Git).
Source control products also make it easy for you to restore historical versions of any files with the click of a button – perfect if you’ve made changes that you want to roll back! If required, it’s easy enough to restore any version-controlled file from this archive should you need to undo any breaking changes.
Branches
Branching can help you accelerate your team’s velocity, make maintenance tasks and feature development easier to manage. It allows developers to work in isolation from the “main source code branch” and there are many branching strategies you can deploy. A deep dive into branch planning is beyond the scope of this blog post but if you’re considering it, it’s important to consider the following:
- How often do you need to ship the product?
- How stable does the root branch need to be, what is your tolerance to bugs “in the wild”?
It’s important to only branch when you need to as it does introduce additional tasks such as source repo maintenance and merging tasks. If you’re the only developer in your team, it’s unlikely you’ll need to implement a branching strategy, that said, you might decide to maintain one branch for hotfixes and another for features. Some common branching scenarios and their definitions:
- Release – Branch to stabilize code you want to release. You can branch before release, avoiding the need to lock down the main branch.
- Maintenance – Branch to maintain a previously released build.
- Feature – Branch to isolate feature development that might make the rest of the project unstable.
- Team – Branch to isolate sub-teams so that they can work without being subject to breaking changes, or that they can work towards unique milestones. These are very like feature branches.
Source: Microsoft
Merging
If you do decide to introduce branching as part of your release management process, each developers code branch, at some point, must be reconciled with the root/master branch. This is where merging comes into play. Most popular source control tools let you merge branches of code through GUI interfaces. Where conflicts occur between source code have been identified, these can be resolved in a “review pane” which allows you to select and preview what the merged code will look like. You can then accept each potential change if you’re happy with it.
Progressing through environments
Your software should only progress through each of the environments when “signed off” by the respective function within your release management process. At a high-level, a typical set of release management functions include:
- Software Development
- System Testing
- Production Usage
Each of the above functions have their own set of internal checkpoints. For example, developers will test code behaves as expected using either manual or automated unit tests. Test Analysts will write and execute test plans. As a team, you need to decide on a workflow that best suits your project.
Release to Production
After your product has passed all developer and system tests, your release is ready to be promoted into a production environment! Some guidelines to help you migrate your software from your staging environment can include, but are not limited to:
- Schedule releases to production on a specific date and time which everyone is aware of. Select a time where there won’t be many active users of the system.
- If you can, present a “down for maintenance page” for the user community.
- Ensure key personnel are around for a few hours post upgrade. You may need to deploy a hotfix due to some unforeseen situation for example.
Release Notes
- Produce release notes that documents new features that have been built, and bugs that have been fixed as part of your new release. Share this documentation with your team and the wider user community.
- Circulate documentation or guides across each function (testers, dba’s, DevOps etc) that lets them know exactly what needs to be deployed and how.
Finally
- After the deployment is complete, perform key smoke tests to check everything is working as expected in the production environment.
[bctt tweet=”Software products are typically “never complete” and are consequently in a continual cycle of development, testing, and release.” username=”GAPapps”]
Tracking Feedback and Bugs
Now that your product has been shipped, it’s over to the user community to get their hands on it. The final phase of release and application lifecycle management involves defect tracking, auditing issues users experience and feeding this back into the next release of your software. Fortunately, there are many tools such as Visual Studio Team Services (VSTS) that make it easy to handle this part of the project.
Tools like VSTS let you log defects, new features and just makes it easier to track change request from the point of origin through to completion. You can even identify code that was changed on a per task basis, thereby making it easier to further isolate code changes. Adding all your bugs into your issue tracking software tightens up the release management process. After adding all your bugs into a product like VSTS, you can start the release management process all over again.
Summary
In this blog post, we’ve looked at release management and how it can benefit your software delivery process. We’ve looked at how setting up your development pipeline is important and how tooling such as source control and issue tracking software can also help.
Here at Growth Acceleration Partners, we have extensive expertise in many verticals. Our nearshore business model can keep costs down whilst maintaining the same level of quality and professionalism you’d experience from a domestic team.
Our Centers of Engineering Excellence in Latin America focus on combining business acumen with development expertise to help your business. We can provide your organization with resources in the following areas:
- Software development for cloud and mobile applications
- Data analytics and data science
- Information systems
- Machine learning and artificial intelligence
- Predictive modeling
- QA and QA Automation
If you’d like to find out more, then visit our website here. Or if you’d prefer, why not arrange a call with us?
