How to ensure a smooth production release and avoid the rush?

Smooth release of product or service can be very stressful at times even if you have an excellent team, proper test coverage, strong continuous integration, and a good release pipeline. 

All your teams’ effort in the form of excessive working hours, avoiding breaks won’t be adequate to avoid the rush and anxiety that comes along the release process. 

So, don’t you think it’s an important matter to look upon? Shouldn’t there be some suitable guidelines for stress-free releases? 

Well, all we need here is proper enterprise release management and a suitable framework that will guarantee a smooth release, preventing the release rush.  

Enterprise Release Management is a must

What exactly is enterprise release management? Enterprise release management (ERM) helps in managing the releases at the organizational level of entities with complex software like big companies, healthcare systems, and much other stuff. 

It basically looks after the coordination of individual software releases and in what ways they suit the company’s bigger strategies, and plans. 

So, why is ERM important? Just think of an organization that builds complex systems of software. 

There are various development groups that are seen working over different components of these large systems. 

Therefore, this kind of structure will be beneficial internally since it enables the developers to specialize, improve focus, and develop components piece by piece. 

But eventually, the pieces should converge in a single, smoothly integrated system. 

Even without overarching release management at the very enterprise level, there can be a lack of coherence among the company’s IT portfolio. 

So, ERM helps in introducing large software products that can work well as an integrated whole, and it allows them to do it effectively. ERM enables release managers to work together, also allowing them to synchronize their different releases. 

The process ensuring a smooth production release while avoiding the rush

Let me provide you with a framework that can ensure you a smooth production release, also preventing the unavoidable rush. 

Start with the Pre Release Checks

You need to begin with the Pre Release since there are several checks that need to be done just before a release. Here is the important list. 

• Completion of the accepted features
• Acceptance testing
• Sign-off from the product owner and agreement on the release date
• Approval from other stakeholders such as security, licensing, IT, etc.
• Feature completion of upstream or downstream systems
• Feature toggles to be enabled/disabled
• Bug bash
• Regression testing — manual or automated
• Hotfix plan, if something goes wrong
• NFR/CFR checks like performance, browser and platform compatibility, etc.
• Appstore/Play Store publishing
• Creation of a new environment
• Backend and frontend release
• Data upload
• Third party licenses, renewals, contracts
• Documentation — release notes, manual, known concerns , etc

Even though this list may not include everything, it can still be a great start.  

Perform the Post Production Checks

Sometimes it might so happen that you assumed a release to be successful, but later you encounter various problems that can get you into trouble. 

So, it’s always advisable to have a post-production check. These are the essential items that need to be checked.

• Core functionality, particularly if the features are completely new
• Performance over various supported devices
• You can check for data integrity. It would be necessary if there are client-specific releases, in the case of SaaS or even when there is some major migration
• You can check for logs, in case of integrations with new upstream or downstream systems.
• Performance dashboards, particularly, if you are expecting heavy loads (like a booking system)
• Other monitoring dashboards or Sonarqube 

Adopt modular architecture 

When it comes to any software program, it’s preferable to release software smoothly and frequently.

By building a modular architecture, teams are able to make the release a natural part of their agile culture. 

Instead of having one large application, you can modularize it into various pieces, categorize similar features into smaller components or applications, and also have clear API contracts between each of the components and applications. Such APIs can be automatically tested with each build in order to provide compatibility and minimize risk in the software release.  

Automate everything

Automating a software release can be the finest way to enhance a release culture. 

So, if releasing software is not presently being automated, you have the option to begin by automating the software release to a staging environment. 

Also, when once everybody finds how easy it is, then the next step is to automate production deployments. 

And, if the releases are difficult, then you can go for releasing software frequently. 

Therefore, automated testing and continuous integration are means to great releases. 

Most importantly, you need to make sure that testing times and build times are short, and also keep in mind that the builds which are easy to validate are easier to release too. Here’s your complete guide to testing in production.

Prepare a Release Template

You must know that there are several parties and stakeholders involved in a release either directly or indirectly. 

Therefore, it will be very convenient to document the checklist in a place that can be accessed by everybody involved. You can simply call it a Release Template. 

So, a release template can be easily created and a copy of it could be prepared every time a release is scheduled. 

While you document the action items or checklist, just make sure that they are actionable tasks. 

Create a timeline for every task

It’s a very obvious thing to have release dates before even finalizing what is being released. This gives you a good opportunity to make the necessary plans. 

By deciding the release date and documenting the Release Template, you can have a discussion with your team and then create a timeline consisting of dates by which every task needs to be completed for a smooth release. 

Also, from the release template, you can make a copy and add a column for dates, and even mark the discussed dates against every task. 

The next suitable step is signup of tasks 

Once you add the dates to the release document, the next step will be the signup of tasks by suitable people. 

You need to set up a meeting with all the teams/stakeholders involved with the release of the product either directly or indirectly. 

The major outcomes that the first meeting brings out can be like: 

• Everybody involved tends to understand that you and your team have a proper plan that would lead to a successful release.
• List of teams or people that are involved, such as important events, 3rd parties, Security team, etc.
• Understand events and timelines
• Recommend/object/change anything if required in the early stage itself
• List of all dependencies
• Looking for what people/individual teams can sign up for, from the list. For instance, your IT team will know about when to work on a renewal of a license, by creating new servers or environments. 
• Clearly understand and discuss the possible RAIDs.

Once the meeting is completed, make sure that each task point on your list includes a date (of completion) and person (not a team, ONE person) who will be responsible. 

Even though the person can take help from others, he/she needs to ensure that the task gets completed by the said date. 

Follow an organic work plan

After setting up the initial context (with everyone involved), it is essential to keep a periodic tab on the plan. Every iteration can be a great start and possibly on a regular basis when you are in the last iteration of the release. 

The first few meetings can be a little longer, but after some iterations, it would turn out to be quick, and also even chats async communication modes such as chat/emails would work. 

It’s necessary to solidify the plan, where each task consists of a date and a person assigned. 

If required, you can even change a few points or dates within reasonable limits, but at the same time, it is also essential to ensure that the plan doesn’t go off track. 

Yash Marwaha, Project Manager at OpenSense Labs, says,

We can plan for a soft release which means the feature or campaign is available for a smaller audience before releasing it to everyone.

Build strong relationships

It is observed that software development requires the involvement of the complete team from product management to operations. 

For instance, the operations team is a major partner in offering software to production since they help in reaching out the software to its end-users. 

Also, the development teams tend to empower the operations team with the following techniques. 

• Create the bill of materials for every software release very clearly. In comparison to the development team, the operations team might not have a similar level of context around the release. 
• For every issue that's solved in the release, offer a link back to your issue tracker and source control system so that the operations team can have a similar level of context if any issues come up during the deployment. 
• You will find that sometimes issues arise while pushing code from the development environment to the staging environment. So, you need to look for these issues, since they might again appear during the production push.
• Since errors appear during the deployment, it's advisable to provide the operations team with a clear way to easily resolve the issues.  

On the other hand, the operations team can help their counterparts in the development process with the following suggestions.

• While the problems appear in production, you need to take time to identify the core causes and solutions. By doing so, you can handle the issues effortlessly in the future as well.
• You can migrate configuration data from production back into staging and development environments to avoid configuration drift.

The solution for the tasks going beyond deadlines

Let us be honest here. We all at times have missed our deadlines and that is completely normal. 

So, if you have any doubt, then add a buffer. 

But there are a few points that cannot afford to have a buffer, like a release date. Some other tasks such as backend release, process-related items like security audit can have a buffer.  

Arjun Sharma, Product Manager at OpenSense Labs, says,

Releases should always have a buffer from the final production date on which we are supposed to have the feature or campaign released.

So, how do you manage to complete your tasks on time? 

Let’s say if you envision that a task might go beyond the stipulated time (that includes buffer) then you need to inform your team, stakeholders, and everybody involved in it. Then you should conduct a meeting and discuss the effective ways to handle such a situation that can lead to a successful release. 

By doing so you won’t end up in a disaster and can normalize the fact of delivering quality products exceeding the set date without compromising on the product standards. 

Yash Chauhan, Associate Business Analyst at OpenSense Labs, says,

You shouldn’t deviate from the goal of delivering quality products in order to meet your product release dates.

To know more, read about adopting a secure software development lifecycle for a safer path to production.

Final thoughts

If you want to avoid the release rush and walk towards a successful release then you will certainly have to follow a suitable plan as discussed above. Such strategic planning can prevent you from experiencing the last-minute anxiousness of the release rush. 

Therefore, by anticipating the future release possibilities, and adopting the well-designed framework we can encounter a smooth product release.