Release management is a relatively new but fast-growing field within software engineering. This concept is about managing, planning and scheduling software delivery all through the release lifecycle.

The aim is to facilitate the process required to move software releases into production while coordinating with different teams to ensure the smooth delivery of software releases with little disruption. 

Thus, release management has become an integral part of software delivery and IT service management as well as a crucial aspect of continuous delivery.

Overview of the role

As more and more companies adopt DevOps practices, the need for highly specialized roles has increased in the last few years.

One such role is a Release Manager, who can plan projects and schedule faster and more frequent delivery of software.

This is especially important as at the core of DevOps is releasing new software in shorter time increments to reach end-users faster.

A Release Manager in DevOps, more particularly, works with development and operations teams to ensure the scheduling of fast releases.

He/she will work closely with different teams from the beginning of a project and see it through to the moment of release.

It goes without saying, then, that this manager will need to be familiar with DevOps tools.

Roles and responsibilities

A Release Manager should stay on top of the release management lifecycle including scheduling and coordinating releases across the company for multiple applications.

He/she will usually be focused on the bigger picture and views the software development and release processes in relation to the overall business objectives.

Whenever necessary, he/she will provide the tools and services needed to help product teams manage and deploy code into production.

Therefore, this manager will be responsible for implementing and managing the release process from development to testing then finally to the production environments.

In this case, the goal of this manager is to handle consistent, on-time delivery of high quality releases. Time is of the essence when it comes to this role so he/she will need to be able to create the infrastructure necessary to enable frequent and quick releases.

To summarize, the following are the typical daily tasks of a Release Manager:

• Scheduling, managing and coordinating releases across multiple applications within various portfolios across different teams and projects.
• Constructing a release calendar for the different projects to have a centralized view of all releases.
• Manage and mitigate risks and resolve issues regarding release quality and schedule.
• Continuously monitor projects and provide reports about their progress.
• Ensuring all team members are adhering to engineering best practices as well as enforcing DevOps policies.
• Monitoring the release process and collecting feedback from the different teams as well as customers for review.
• Making improvements on a regular basis to the release process.

Required skill set

The Release Manager, then, will need to work across different teams involved in the software development processes and will provide support to developers as they set up test environments.

He/she will also need to work with the IT team in order to enhance software engineering practices and work closely with project or portfolio managers.

The release manager will usually have a background in computer science or a related field with advanced knowledge of the software development lifecycle. This manager may also have a project management background.

Furthermore, he/she will need to have some technical skills with thorough knowledge of feature toggles, branch handling, continuous integration and continuous delivery.

He/she will use these technical skills to solve any issues that arise; hence, he/she will need to be in possession of interpersonal skills and problem-solving abilities to resolve any cross-functional team issues.

He/she will also need to define and implement the best practices and methodologies depending on the project requirements.

Such a role is considered to be highly challenging as these managers are involved in various aspects of the release process including monitoring, testing, communicating across teams and deploying and so he/she should be able to work under pressure.

Additionally, he/she will need to have a clear understanding of business needs and their priorities. They will also align software development with organizational goals, acting as an intermediary between tech and business teams, in order to effectively schedule builds and testing as well as create release plans.

Release management tools

The following are some common tools that Release Managers may need to be familiar with: 

• Jenkins– a popular tool for continuous integration but it can also be used for release management.
• Ansible– this is an open-source configuration management and application deployment tool intended for IT professionals.
• Chef– another configuration management tool that enables continuous automation across all IT processes.

When incorporated into IT processes, such tools can reduce inefficiencies by creating consistent automated processes which result in high-quality releases.

What is the salary of a Release Manager?

According to Indeed.com, a Release Manager makes an average base salary of $81,679 per year in the United States with a $6,000 cash bonus per year.

Conclusion

To sum up, a Release Manager is an important part of release management and is usually the final decision maker on any vital release-related issues.

Such a manager is capable of carrying out various functions and working across teams by developing a collaborative approach in the software development process.

These managers promote more effective release management within your organization to reduce release management pains and to help successfully deploy reliable software with the least disruption possible.

What is a ring deployment?

Ring deployment is a form of gradual rollout where new features are released gradually to different groups of users to mitigate risk.

Jezz Humble first introduced this concept in his book Continuous Delivery.

It is referred to as a ring as these groups of users are represented as an expanding series of rings, starting with a small group of users to eventually encompass all users.

Rings allow developers to evaluate the impact on those users, also referred to as ‘blast radius’ through observation, testing and gathering user feedback.

How is it implemented?

When executing a ring deployment, the group of users you choose will be based on similar attributes. The first step is to carefully consider your primary users and which users are suited for each ring by assessing the level of risk at each stage. 

For example, you can choose to release to internal users within your organization first to validate the release. Afterward, you can move on to the next ring which will have more users and so on. 

The users within the rings will then receive the new feature. Your impact, or blast radius, will increase as your feature moves through the rings.

As mentioned previously, you can envision this process as a series of rings, where the first release can be to the ‘internal users’ ring. 

Then, as you get a bit more confident, the feature will be released to your ‘early adopters’ ring, who are more tolerant in case problems arise during testing and then finally to your ‘all users’ ring. This final ring can also be done in stages, such as all your users in a certain country. The names of the rings, as well as the deployment pattern, can vary depending on your preferences and objectives.

New releases would be deployed to each ring over time. Between each ring, there is a wait period where the team analyzes the release and monitors for any issues. If the deployment stays as it is and is not delayed or canceled, the next ring will be deployed.

Benefits of ring deployment

The main benefit of such a technique is risk mitigation which seeks to minimize the impact on end-users by gradually releasing your feature without affecting all users instead of opting for one big-bang release. 

Using ring deployment, you can identify issues early on while limiting the blast radius of disruption on your users in case of any problems that might occur during testing.

By gradually releasing your feature, you would be able to gather feedback from your most relevant users and allow you to detect bugs before all your users have access to it.

Rings and feature flags

Now, the question you may be wondering is whether to use rings or feature flags.

The simple answer would be to use both. The main aim of feature flags is to release changes to specific groups of people. Therefore, using both rings and feature flags will help you to progressively expose your features.

So, for example, you can use feature flags in ring deployment to hide certain features in a ring that you’re not fully confident about.

Then, if something goes wrong, you can roll back the release while you fix the issue and then release again whenever you’re ready.

Therefore, ring deployment using feature flag management tools will help you to release your features strategically and efficiently starting with your low-risk user segments. 

For example, AB Tasty’s flagging feature allows you to assign specific flag values to different user segments so certain users, such as your internal users, will be presented with one value and other users will be presented with another value. As such, this will allow you to create and manage rings easily and allocate users to each ring accordingly.

To conclude

Ring deployment is an effective, risk-free method of progressive delivery where you can pick which features you want to expose to which users. Using feature flags alongside ring deployment, rolling out and rolling back features have now become easier than ever!

Consider this scenario: you’re an app developer for a shopping app. You wish to add new functionality to this app, for example, a new chat feature but you’re not certain how it’s going to affect user experience and usage. You want to be able to test it to see how things go in production before moving forward with a full release.

This can be done through remote config, where you can add this new feature to your app and release it to a small percentage of users for testing. If any issues occur, the feature can be easily disabled remotely without going through the App Store review process. 

What is remote config?

Remote config, or remote configuration, is a software development technique that allows you to modify certain features of a mobile app remotely without having to do a full app update or deploying a new version of the app to the App Store. 

This is done by defining parameters in the remote config interface and then setting default values for these parameters in the app. These parameters are used to define the configuration values that will be used in your app. 

Then, you can just change the values to app behavior from a remote server without the need to re-deploy to the app store. Remote config can then download the updated values the next time a user accesses the app.

We can imagine the implementation process as follows. Firstly, you will need to define which aspects of your app behavior you wish to modify through remote config, which can then be translated into the parameters you will use in your app.

Then, you set the in-app default values for the remote config parameters. Your app can then fetch parameter values from remote config to activate them. With that, you can define user segments and release new features to validate improvements without any app update required from your end

Rollouts and rollbacks 

Remote config allows you to make changes to your app’s behavior. It gives you an easy way to roll out new features since you can control your app remotely. You can control which users get access to these new features based on several criteria such as location, for example.

Then, you can make immediate changes to your live app in production without going through the lengthy App Store approval process.

This is especially beneficial when you’ve just rolled out a release but you discover a bug so this way you can fix this bug and make the necessary changes without worrying about waiting for approval. Such App Store approvals usually take hours, which is time you cannot afford to lose with your users. 

Consequently, the most obvious benefit of remote config is the power to make instant changes without having to publish an app update. 

A/B Tests

Remote config, as we’ve seen, can be used to enable and disable certain parts of your features for a subset of users by delivering different values to random users. This means it can be used to present different variations to certain segments of your user base. 

Therefore, a segment of your user base, say 10%, would be given a new user experience while the remaining 90% are presented with the original experience.

Remote config and feature flags

Remote config can be implemented through feature flags. These, in turn, can be switched on or off while deciding who gets to see the new features without rolling out an update in the App Store. 

With feature flags, new features can be wrapped in a feature flag and can be remotely turned on or off, allowing flags to be activated based on specific user profile. As a result, feature flags have become a staple in mobile development best practices.

Therefore, remote config allows you to provide a percentage of your users with customized content to give them experiences based on their preferences. It also lets you provide changes faster resulting in higher quality releases.

Simply put, remote config gives developers the ability to experiment with the look and feel of their app remotely giving them more control and flexibility over the app release process. 

And all of this without needing to do a full app update or publish a new version of your app.

As a cloud-based feature management service, AB Tasty enables you to wrap your features with flags. Afterward, you remotely configure your flags from the server-side dashboard, allowing you to enjoy the flexibility of remote configuration at scale.