software launch

Here's how to bring software to life effortlessly and keep things under control

1 July 2021


Once the built software has been extensively tested, it's time for the release so that users can learn about the new function(s). When something comes to life, you have to let go of it to a certain extent. Of course, this has to be done under controlled conditions. There are numerous strategies to control the go-live as much as possible. In addition, using observability to monitor whether the software works as intended, as well as whether it is used as intended, is a smart move. Discover how all this works.

A smooth transition from build to run

In our previous blog posts, we talked about the continuous delivery flow. This consists of everything needed to bring software to production with a short lead time, iteratively and securely. Accountability remains with the same team during the transition. This is a consequence of the DevOps attitude: you build it, you run it. So building and keeping a piece of software up and running are not separated, only the rules of the game change.

In order to clarify this, let's take a look at NASA's way of working. They make a clear distinction between launch control and mission control. Launch control is responsible until the count reaches 0 and the rocket ignites. Until that point, they can abort at any time. This is similar to a continuous delivery pipeline that has built-in checks and can interrupt the process if minimum requirements are not met. Once the rocket has taken off, mission control takes over because from then on it is impossible to simply stop a flying rocket. Everything is monitored, and if something does happen they can still try to limit the damage. To a certain extent, this is comparable to putting software into production. Once the software is live and the users start working with it, it is not so easy to reverse the process. Fortunately, there are some release strategies where we have more control than NASA does in space.



Release strategies to keep things under control as much as possible

By separating deployment of a new version of certain aspects from the release of certain features, a whole world of possibilities opens up. Deployment is about the binaries (a set of executable files that perform a particular function), while release is about the functionality. In too many cases, these two things go together. The following strategies keep you much more in control:

  • Blue-green deployment: A new version is placed next to the old one. A self-selected pilot group of users gets access to the new version so they can test it in production. If all goes well, the switch can be made so that everyone uses the new version.
  • Canary release: This strategy gets its name from the little yellow birds that were formerly used to detect any signs of gas leaks in mines. Here again, there are two versions side by side. A random 10% of users get to see the new version via load balancing. This percentage is steadily increased. If something goes wrong, the percentage drops again.
  • Feature flags: Certain new features are already available in the code, but not yet visible to users. This makes testing in production possible. It is even conceivable that a user is given the choice of using the old screen of a particular feature or the new one already. In that case they will be asked "Do you want to test the beta version now?"  This also makes it easier to integrate auto-healing concepts. If the monitoring system detects a problem with the new feature since the activation of a certain feature flag, for example, it can be automatically turned off.



Keep an eye on everything with the right observability tool

In any case, monitoring is essential in any DevOps context. After all, if you have end-to-end responsibility you want to know exactly what is going on. Nowadays there is a lot of talk about observability. This is the degree to which a system releases information about itself during its run time. The days of a black box where no one knows what's going on are over. Logs, metrics and traces are the basic pillars, but you can go much further in terms of monitoring to keep control. For example, real user monitoring is very important nowadays in our world focusing on the user experience. This kind of monitoring registers the user experience, using parameters like click area. 

By putting all this data in a specific context, you end up with issues that need attention. Based on this infoformation, AI can be used for automatic problem detection with root-cause analysis and business impact detection. Dynatrace is a platform that makes all of this possible. A software intelligence system such as Dynatrace constantly monitors all aspects of an application landscape. Application Performance Monitoring (APM) has long ceased to be a stand-alone process. The in-depth automation that Dynatrace offers today allows us to adopt an AIOps approach. As a result, the product team obtains an enormous and continuous stream of information, which is why it is also called continuous feedback. This information is also crucial for the business, so that they can validate whether the software is being used as initially intended and whether it is achieving the intended results. The large feedback loop that we discussed in the first blog post of this series ("Are we building the right things") can also be fed this way.  This can even be done using Service Level Objectives (SLOs). These are self-selected variables that represent an objective. An example is the percentage of customers who actually check out their shopping cart.

This system can also be used in test environments to detect problems before they are released. This is an integral component of the whole 'shift left' approach. There is even a system (Keptn) where load testing can be automatically performed and validated based on advanced observability data.


Like to find out more about the whole agile software development flow?

Also read the other blog posts in this series:

Discover all blogs
Read more

Subscribe and receive our blogs in your mailbox