Risk-Aware vs. Risk-Averse Product Development

When organizations adopt Agile development practices, they also adopt shorter release cycles. These shorter release cycles mean more frequent application deployments — and more frequent deployments increase the risk of an unstable release.

While any threat to application quality can be unsettling for both developers and IT personnel, this risk is necessary in order to allow development staff to innovate and move the business forward. Rather than becoming risk-averse, organizations need to be risk-aware; and they need to find ways to ensure application quality in the fast-moving world of software development. Keep reading for an overview of the modern development practices that enable organizations to manage risk effectively, without stifling innovation.

The Importance of Accepting Risk

In the current development climate, being risk-averse is unacceptable. It can hinder businesses in ways that are difficult to overcome. For instance, organizations that are willing to move quickly to push out new features are better positioned to cope with changes in the market. Competitors are constantly rolling out new products targeted at the same customer base, and organizations need to be able to adjust their products quickly to prevent an exodus of users. In order to survive in this environment, you have to take risks.

In addition, today’s development teams need to be able to continuously deliver their own innovative features and increase their product’s value to the end user. Organizations that lean on lengthy development cycles, or continually delay releases until they are 100% confident in their features, risk something that may be more valuable than quality assurance. They risk missing out on the opportunity to attract new customers — an opportunity that would allow their businesses to grow.

3 Tactics for Effective Risk Management in an Agile World

Therefore, organizations must be equipped to develop and release innovative features in short cycles, while also ensuring a high level of application quality and reliability. While this may not sound particularly fair, it is the reality of the situation.

To accomplish this, DevOps teams must employ modern development practices to manage the risks that these frequent changes pose to application stability. Let’s take a look at a few of these practices in more detail.

1. Automated Software Testing

Ensuring that your new code works cohesively with your existing features is key to your ability to implement and release it quickly. An efficient and effective way to do this is to build out an automated testing strategy. Automated testing involves the development of test scripts that can be executed in an automated fashion to validate the functionality of application features. And, oftentimes, these tests are integrated within a product’s CI/CD pipeline.

An automated testing strategy enables development teams to ensure that new functionality works as designed, while existing functionality remains unaffected by newly introduced changes. By automating the process of validating functionality, the risk of human error is eliminated and the testing process is much faster. Furthermore, an automated testing strategy is more scalable than a manual testing process. The efficient nature of test automation allows development and QA teams to construct suites of test scripts to cover almost all of an application’s functionality, and they can all be run with each application build. This empowers development organizations to have the utmost confidence in the quality of their releases (even when deploying with high frequency).

2. Application Performance Monitoring and Effective Incident Management

No matter how diligently DevOps teams validate their application changes, problems will always make their way into production. A risk-aware development organization ensures that they have the ability to respond to these problems efficiently, in order to limit the impact that these issues have on end users. One way for development organizations to accomplish this is through Application Performance Monitoring (APM).

As the name suggests, APM involves monitoring an application’s performance, usually through the use of an APM tool. These solutions are equipped to detect anomalies and alert the proper personnel of potential incidents. In addition to alerting, modern APM tools can provide insight into the root cause of an incident. This enables development and IT personnel to streamline the process of incident remediation, thereby addressing problems with greater speed and reducing the impact that these problems have on the user experience.

3. Release Strategies That Lower the Risk of Deploying Applications

Another way in which a risk-aware organization can limit the impact of production issues is through the use of deployment strategies that empower them to act quickly, whenever quality issues in a new release threaten application stability. Such deployment strategies provide mechanisms for IT folks to roll back problematic releases in an efficient manner. Consider the following strategies:

A canary deployment is a deployment strategy in which two versions of an application are deployed side-by-side in the production environment. When a new version is ready to be deployed, a certain percentage of the traffic is routed to the new version (the “canary”), while the rest of the traffic is still sent to the old version. As the stability of the canary version is verified, more instances of the new release are spun up and a greater portion of the traffic is sent to these instances. This gradual migration of traffic to the canary version continues until all users are routed to the new release.

It’s easy to see how this type of deployment can help mitigate the risks associated with an unstable release. If there are problems with the canary version, all users can be quickly sent back to the previous stable release (which has been running all along). And if the canary release’s problems are identified before large swaths of traffic are routed to it, then many of the system’s users will have been completely unaffected.

As with a canary deployment, the new version of an application is deployed side-by-side with the old one in a blue/green deployment. The blue version of the application is the previous release, while the green version represents the new one. Initially, traffic is routed to the blue version. After the green version is deployed and thoroughly vetted, all traffic is rerouted to it (all at once) while the blue version remains up and running. If the green version proves to be buggy and unstable, IT personnel can simply route all traffic back to the blue version.

Key Takeaways

Today’s development cycles are shorter than ever, but releasing applications more frequently increases the risk of an unstable release. While the heightened risk is certainly concerning, organizations cannot allow fear to stifle innovation.

To alleviate these concerns, you can adopt development practices that help ensure application quality and limit the impact of stability issues when problems occur. These include:

• Automated testing for conducting highly efficient tests with greater coverage.
• APM to help streamline the incident management process.
• Using release strategies that enable low-risk deployments.