Release management is the process of managing software releases. Every program and application needs to be maintained, periodically updated and released to market in order to keep its business value. Although this seems pretty simple to the end user, usually no more than a few button clicks, the process of rolling out releases can be very complex and error prone if not followed correctly. A good process can effectively enhance the value of your product; lower development costs and raise the trust of your customers in your brand.
Source control systems
Developing code requires deep collaboration that is almost real time between all members of the team. Each developer needs to have a local copy of the code in order to develop. In addition, each change should be reflected across multiple development locations in order to keep all teams in sync. Source control systems can provide all of that and more. Code patches, gated check ins, backup, access control and branching are some of the features of good source control systems. Current notable source control systems include Team Foundation Server(TFS), PerForce(P4) and subversion (SVN). Documentation of each system can be found on their vendor’s websites.
Source code branches
Source branches contain the complete source. There are three main branches
Dev – containing the current development code. This branch is the first to reflect any code changes spanning from upcoming releases.
QA – code that was developed and integrated into the dev branch will be merged into the QA branch in order to be subject to testing by the QA department. If this code passes all integration testes it will be ready to be merged up into the Live branch.
Live – this branch contains the code that is currently in production. Any deployment of new code to production systems should be done only from this branch.
Continuous integration and continuous build
Every branch powers its own environment. The DEV branch powers the dev environment, QA the QA environment and LIVE, the staging environment along with production. Each environment should be 100 percent operational at all times. To insure this is being done we usually use two systems. Continuous build also referred to as Build automation is running on the build server and uses systems such as CruiseControl or Hudson in order to continuously compile the code. If a code branch is broken and cannot be compiled, an alert is being send to the release manager or the entire team along with the last check in that caused the build to break. The last check in contains the name of the developer that checked in the code so that they can fix it. The second system is automated unit testing. The solution’s unit tests project is being executed and checked for any unit tests that might not pass as a result of new code.
Development categories: bug fixes, enhancements and projects
In general enterprise software development can be categorized into three main areas:
New projects – this is the development of new projects. It requires new architecture and new code. A project requirement document (PRD) has been passed on to the team by the product manager or stakeholder and new development is about to begin.
Bugs – bug fixing is a part of an application development lifecycle. There is no way around it and even with the best QA bugs are bound to appear in your software. Bug fixing should be done at the break point and no new development is done at that point. No refactoring should ever take place at bug fixing in order to minimize the introduction of new bugs as a result of fixing current bugs.
Enhancements – new features being added to major releases of the software. This requires the application to be architecturally sound and handle the additional code. If the application cannot handle the new features it must be re architected or the enhancements be separated into sub systems.
Integrating with remote teams
In enterprise software shop the team is rarely developing from the same physical location. It is more likely to have a team in the main office along with multiple teams in remote locations, maybe offshore, along with individual developers that might be working from their home office. Each team member should be aware of the process and follow it to the letter. It is best if all teams work on the same branches and not create local office copy simply since integrating the code from local office copies is likely to conflict with other offices. The idea here is: break builds early, when it is simple to fix them.
Efficiently funneling the stream of code into successful releases
The process of merging code up and down between branches can be tedious but needs to be done correctly to insure no bugs appear as a result of a faulty merge. Over the years I have develop a process I like to follow and that has proven to be reliable.
New projects process: In new projects, a new branch is created with the project name and target release. Development is done in the branch and then merged into the Dev branch once it’s completed. It is then pushed to QA along with all other projects targeted for the next release. Pushes are Delta only. Any existing bug fixing in QA is not affected. It is then tested and pushed to the Live branch to be archived and released as a part of a release.
Bug Fixing: Bug fixing will be coded on the QA branch where it will be QAed and verified. Once a bug is fixed, it will be merged in two directions. Down to the DEV branch and up to the Live branch. It will then be released to production manually.
Enhancements: Will be coded in the DEV branch to be merged into QA
I hope you find this process helpful in your enterprise environment. As always, a process is as effective at the people that follow it.
27 Aug 2010 6:00 PM