Ramblings on Release Management August 30, 2015Posted by Edwin Ritter in Project Management.
Tags: release management, release management process, software configuration management, software development, software development lifecycle
add a comment
From a recent project, one of the lessons I learned concerns release management and who drives that process. What I find most interesting is the developers’ view that once code is checked in, the deliverable is complete. I have worked organizations that use a formal software configuration management and release management process (SCM/RM). That role can be a fully staffed position working with development teams to get code changes tested and released.
Related to this topic is environment management and configuration, the related tools and workflow to keep the organization working on the right things and at the right time. Ultimately, the changes are provided for use by external customers to meet their business needs. Let’s not forget that customers keeps the business going.
The SCM/RM process can easily be used with change control to manage the code base consistently. When the SCM/RM is not the responsibility of any single person, I submit that the developer shepherd their respective code changes through the test and release cycles. What I find lacking is ownership from developers on following that through to getting code changes released.
While my expectations are influenced by past experience, I am aware that it is naive to expect other team members will have a level of ownership and commitment consistent with mine.
So the next time there is a change, I will use my greater understanding on what is needed to keep things moving and align my expectations. A lesson learned and one that I am willing to share with others.
Comments invited on the level of effort and ownership with release management. Who drives changes through to release? Is it automated in your shop? What tools and process do you use to manage the code base?
Tags: coding, deployment methods, lifecycle, management, process, project management, projects, software, software development, software development lifecycle, software development teams, technology, tools
In my last post, I covered my recent efforts at software programming after a self-imposed hiatus. As a follow up, I wanted to talk about the development cycle. More specifically, the software development lifecycle. The most traditional development method is the Waterfall method. As it’s name implies, the lifecycle flows across phases with the result being a finished product that is tested to satisfy design requirements.
Deployment methods I have used include Waterfall and Agile among others and hybrids of these. As shown in the image, there is a feedback loop with testing that can introduce new/revised requirements. That starts the cycle over again, from the beginning. From my experience, there are two phases that seem to get short shrift. One or both of these typically get compressed due to project constraints and are sacrificed in order to stay on schedule. Those phases include Design and Test. What I have also found is that if you accelerate either of those, the project will reap a short term benefit. But, ultimately the project will not stay on track. Instead, the project will re-visit one or both phases, which causes waste, and any gains in time expected are then not delivered.
As a programmer, I admit I have squeezed several phases. My advice – whatever process you employ, don’t cheat it. Having a solid design ensures requirements are addressed and adequate testing provides confidence for success at launch. Whatever method you use, adhere to the diligence in each phase and then keep progressing forward. Each phase should be sized according to the project goal. Changes to existing code base can be minimal and have little design impact. Great! Testing should then focus on regression impact to ensure everything is working with new changes integrated cleanly.
Does your mileage match mine? Comments invited!