On this post I will cover a compilation of best practices I’ve gathered both from personal experience and from the web. Hope you enjoy it! Please feel free to drop with your own view on the comment section.
- 1 What is Release & Deployment management ?
- 2 Final thoughts
- 3 References
The definition of release & deployment management may vary according to the project or service management methodology you are most familiar with. I’ve tried to compile under the same table the scope of release & deployment management according to PMP, Prince2 and ITIL.
|Includes the processes, systems and functions to build, package, test and deploy a release into operation.||Not clearly identified, but could exist on the “Managing product delivery” stage as a liaison role between team leads and project managers.||Same as the Project Manager with added skills specific to the deployment of the software. Also encompasses negotiation, coordination and mediation of all the stakeholders activities,that impact product deployments on schedule and budget.|
As you can see there isn’t a clear role definition here, but rather a mix of capabilities having the project manager role as reference. From my perspective and experience, wikipedia’s role description is the most complete one.
To be a release & deployment manager you’ll need to play the roles :
- Architect: define, implement and improve processes to efficiently manage releases of code
- Coordinator: responsible for coordinating software sources across multiple teams
- Facilitator: point-of-contact between different business units to promote smooth delivery of software products or updates
- Support Engineer: helps troubleshooting application problems related with specific releases
Now that we clarified the role, lets look at 7 best practices that will really help you turnaround your project.
1. Understand legacy processes
As much as you would like, typically you’ll never start with a clean slate. Before starting to apply your own ideas about release & deployment management on your company , make sure you understand the existing legacy processes. Quoting Einstein as above “if you can’t explain it simply, you don’t understand it well enough.”
Start by making a list of all the people you are going to work with and their roles. Then make a list of all the processes and tools currently being used.
2. Establish regular release cycles
After knowing who you are going to work with, and how they currently work, your next step should be to establish a release strategy. This strategy should articulate regular release cycles. To define regular release cycles you can :
- Define the actors and stages of your release cycle
- Define regular release windows to deploy new features to the environments you control
- Regular review the release windows with your team to improve the process
- Anticipate as much as you can the communication of intermediate and final release windows. This will allow the discussion to shift its focus from release dates to release content.
You can depict your release lifecycle as the example below…
This diagram(courtesy of IBM) depicts the websphere portal 6.1 build release cycle. They clearly identified 3 actors which provide code, content and scripts to a common source code repository. This code gets built and is sent to development server for integration and testing. After a certain period, this code is promoted to the staging server where it goes through user acceptance testing. Finally when UAT testing reaches a defined quality gate, the code is finally promoted to production.
After defining the release cycle, now its time to define the release windows. Since 2011, Mozilla the company behind the famous Firefox, has come up with the following release windows:
As, you can see above, every six weeks, Mozilla is producing a new Firefox release ! Then the product will spend 6 weeks being community-tested on the Aurora release and another 6 weeks stabilizing on Beta. Finally 6 weeks afterwards, we will get a major Firefox release totalling 18 weeks from the first release date to mass public availability. The release lifecycle should never be only focused on the final release and equal importance should be given to intermediate releases.
Depending on your project you may need not one, but multiple release cycles for different sets of teams/technologies.. Don’t fall on the trap that “one sizes fits all” ! Also remember that your release cycle is not about when your customer wants the release. It’s about when you can deliver it to the desired level of quality.
3. Identify key collaborators
Identify from the list of people you already gathered, those who can help you best achieve your goals. Make every effort to get close to these people because they are the ones who are going to make “things happen” independently from their role. Also make sure these people know and are engaged with you and your release lifecycles dates. This will help getting things done on time.
4. Form your release infrastructure
As important as identifying key people, ideally you should start defining your release infrastructure before the project starts. The release infrastructure comprises:
- the code repository: CVS, SVN, GIT
- the documentation repository: Confluence, Wiki, Sharepoint
- build tools: Jenkins , db/forms deployment scripts ; Red-gate
- release control tools: Jtrac, Mantis, Jira, Bugzilla
Besides these examples, the release infrastructure also covers the hardware, storage, network connections, bandwidth, software licenses, user profiles and access permissions.If you’re lucky you will be able to establish most or all of your own release infrastructure, if not, you’ll have to understand the existing one and adapt to it.
5. Automate,standardize and upgrade
After having understood/established your release infrastructure, automate as much processes as you can, and establish clear and easy standards to follow. This will ensure the quality and consistency of deliverables.
Typical standards to establish may include:
- code commit standards: define the standards to which every development team must abide to submit code. These can be file format/naming standards for example.
- documentation standards: define the required documentation for code deliveries
If a release infrastructure was already in place, your project may also benefit from upgrading to better tools. If your company has some degree of flexibility, you should push this. Example:
|Tool||Functionality||Could be improved by|
|CVS||Concurrent versioning system||Changing to SVN would allow:
* easy rename files and directories
* commits as changesets on the whole tree
|WinCVS||CVS client||Changing to Tortoise would grant:
* easy to use
* greater community support
|Mantis||Open source issue tracker||Changing to Jira would allow:
* define powerful custom workflows
* access to wide plugin ecosystem
* friendlier user interface
6. Improve test environment usage
Typically the test environments should be in place for test execution and validation well in advance of the final code delivery. Try to understand where bottlenecks may happen and adjust your release infrastructure and processes to avoid them.
7. Invest on communication and people
This may seem a rather obvious topic but it is not. It doesn’t matter how good your release processes and infrastructure are, if you don’t invest on communication and people your mission as release & deployment manager will ultimately fail.
On topic 3, you already identify which are your most important collaborators. Now also invest time to know what is the most relevant information they need and how they prefer it to be delivered. The most important information should typically be available in realtime. The release progress for example, should be available to the relevant stakeholders at all times and not only on emails or on weekly meetings.
Last but not least, take time to listen to your collaborators, fears, aspirations and desires. Make these people feel that you care about what is important to them, so that they can care about delivering personal value to the process!
Being a release & deployment manager is a challenging role. To succeed you will continually have to challenge yourself as well as your team. Adapt yourself to the development environment , learn with your team, and evolve together!
 CIO online magazine; 7 ways to improve your software release management ; http://www.cio.com/article/440101/7_Ways_to_Improve_Your_Software_Release_Management?page=3&taxonomyId=3038
 Wikipedia ; Release Management ; http://en.wikipedia.org/wiki/Release_management
 Wikipedia ; Software Deployment ; http://en.wikipedia.org/wiki/Software_deployment
 Universities and colleges information system association;ITIL – A guide to release and deployment management ; https://www.ucisa.ac.uk/~/media/Files/members/activities/ITIL/servicetransition/release_deployment/
 Plutora, 8 ways to Improve your Release Management Success Factors ;http://www.plutora.com/insights/2012/8-ways-to-improve-your-enterprise-release-management-process/
 W3Schools ; CSS styling tables ; http://www.w3schools.com/css/css_table.asp
 Plutora, Release Management Best Practices ; http://www.plutora.com/insights/2013/release-management-best-practices/
 Search for software quality; Enterprise release management: The top 10 myths; http://searchsoftwarequality.techtarget.com/photostory/2240208260/Enterprise-release-management-The-top-10-myths/1/Define-your-own-software-release-management-process#contentCompress
 Mozilla blogs ; Every six weeks ; http://blog.mozilla.org/channels/2011/07/18/every-six-weeks/
 Atlassian ; Jira Vs Mantis ; https://www.atlassian.com/software/jira/importer-migrations#!jira-mantis
 Wamped ; Choosing an issue tracker ; http://www.wamped.org/post/4105652822/choosing-an-issue-tracker-trac-vs-mantis-vs-jira-vs
 Mantis; Welcome to Mantis ; http://www.mantisbt.org
 Project Open; ITSM Release Management ; http://www.project-open.org/en/process_itsm_release_management
E-Gineer; Continuous application release cycle ; http://e-gineer.com/v2/blog/2007/12/continuous-application-release-cycle.html
 IBM Redbooks; Managing websphere portal 6.1 ; Portal release lifecycle