Releasing code to production – does it really need to take more than 5 minutes?

How long does your team typically spend working between production releases? Do you know that feeling when 3 months have passed since your last release and you think it’s far too long to the next one? You almost forget what the goal is, and although everyone is slaving away, there is nothing that benefits users immediately and so at times the whole thing seems to be in vain...

The concept of developing a Minimum Viable Product (MVP) was introduced by Eric Ries in his book, Lean Startup. Eric suggests that the MVP is the “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.” This is our formula for avoiding disastrous projects, which never get off the ground and stagnate. We ship early and often, enabling our team to test, optimize and retest in controlled, lived environments. Daily releases help us realize a truly agile operating model for our engineering team.

This was not always my experience. Previously, I have worked at different companies where a “high level of agility” equated to one monthly release for production. And that was the best case scenario. The actual release for production was often an entire project in itself, with the release process inevitably causing headaches and lasting days. Annual and semi-annual releases were not unusual in waterfall projects either - which, unfortunately, can still be found in the software industry today.

With that being said, I believe the waterfall model is dead.

The formula for efficiency is clear – compartmentalizing components of a build into digestible deliverables will enable teams to maintain a clearer focus and stay on course with their work. Ultimately, creating more buy-in by individual contributors as they understand their contribution to the great whole.

Developing MVPs can help your team avoid wasting months on what could potentially become a disastrous project.

Many engineering organizations are reluctant to pursue automation, particularly when it comes to testing and deployment, as they are concerned it will be too time-consuming to implement. However, after some up front investment, the time invested is recouped multiple times over. The hardest part is just a matter of getting started!

But how do you restructure your development department to become MVP-focused? Here is a brief summary of my preferred methods and tools.

It all starts with automated testing!

The easiest way of working with automated tests is to ensure that your development process in based on Test Driven Development (TDD). This requires you to develop unit tests, UI tests, integration testing and load testing, as part of your feature development. We use tools such as Azure DevOps, Selenium and xUnit. And, of course, our proprietary development tool box, CADD, which helps us to automate and simplify all aspects of the testing process, making it even easier to get started on TDD.

Moreover, code analysis tools, such as StyleCop, ensure that your team writes consistent code and will help identify issues already at the code writing level.  Combine this with SonarQube for ongoing monitoring of the code, and you will have come a long way in the development process.

Once you introduce systems to manage automation for testing and your development process, the next step is to establish automated deployment. I have often struggled with deployment processes that involve logging onto a server, copying some files and then, at best, running a script that partially automated discrete steps of the process. This comes with the risk manual portions of the deployment are forgotten, the wrong versions are deployed for the wrong environments, or perhaps that they are not deployed across all servers. Considering the myriad of functional tools available for supporting fully automatic deployment, maintaining any manual requirements within the deployment process is simply no longer necessary. Our operating model is proof of what is possible. We have good experience using a combination of CADD, Azure DevOps, Powershell and ARM templates.

The final step

The final step is to make it easy to monitor your environments so that errors are identified immediately - before they become user-reported bugs. Our framework makes it easy to identify exactly which updates have caused the errors, but a comprehensive monitoring scheme needs to be established from the start of any build.

Our CADD toolbox comes with a variety of monitoring tools, this coupled with Application Insights support a comprehensive monitoring framework and in-depth support of trouble-shooting if anything goes wrong. You can supplement this with the automated monitoring function capable of comparing data discrepancies between a pre-production and production environment, which allows you to readily identify the consequences of large daily batch runs before rolling them out into production.

Not only will your company realize the benefits of a quicker and more cost effective deployment process, but you will also enjoy a team of happy developers who can focus on more high-value tasks. They will now be able to focus on building new features rather than fixing old errors, or worse, spending hours hunting for bugs which are difficult to identify.