How To Release Software Several Times A Day.

Our world can flip upside down in the blink of an eye – we’ve seen this time and again, with recent events being an especially harsh example. In the context of software development, companies with systems that can adapt quickly to changing conditions can have the upper hand in their market – for meeting the latest trends and most critical and urgent demands alike.

From a technical standpoint, an infrastructure which allows fast and frequent deployments means a system that is more stable, easier to test, and enables more regular experimentation for new feature development. Quite simply, smaller releases are less risky: when it comes to critical releases and innovative experiments alike, it’s easier to roll-back a release that was a granular part of a bigger and well-structured system.

Monolithic systems that involve releases taking weeks or months inherently take longer to deploy, which opens a window of opportunity for a crash upon release: the worst nightmare of a development team in a high-usage context. When there is visibility of the impact of a release and measures in place to monitor, test and resolve issues, there is much less chance of system failure.

Godel often finds that its clients benefit from the approach to development we will describe below. However, it is important to highlight that faster deployments aren’t always necessary. In certain industries, for example, where new features aren’t a user priority or compliance processes are particularly complex, there may be little gain from frequent releases.

These are the top 3 scenarios that a faster deployment strategy can be applied to great business advantage:

Highly competitive sectors where technology is a key differentiator (e.g. retail).

Sectors very reliant on conversion metrics, where constant A/B testing and reactivity is a priority (e.g. booking companies)

Innovative companies looking to deliver new features that can make a competitive difference.

How can a faster release cycle be achieved?

If we’re building a greenfield system, it’s sensible to take a development approach that takes all the practices defined below into account from the beginning. However, a real challenge is faced by teams wishing to transform an existing monolithic, difficult-to-change system into one that is more adaptable to change. When existing logic isn’t geared towards this approach, it can take a while to reach the goal of multiple deployments a day. Despite this, in the context mentioned above where pivotability is important, this investment is certainly worth the effort.

Step One: A microservices architecture

Before anything else is considered, the “sprint zero” objective to achieve is a microservices architecture. Microservices are an alternative to a monolithic architecture – where each “microservice” is an independent module that is individually responsible for performing a precisely defined, standalone task. This alone is a serious undertaking, especially for bigger monoliths. Skilled developers must break down the system sufficiently – building small microservices without going overboard and “over-granulating” a system into dust, so that they are “just right” for the system at hand.

Step Two: Ship-shape CI/CD and deployments to Kubernetes

Once a microservices architecture is in place, setting up a continuous integration / continuous delivery (CI/CD) pipeline is an optimal development strategy for faster deployments. Kubernetes is a fantastic tool for achieving this. It orchestrates the running of containerised microservices in their chosen environment, and automates load balancing, storage, self-healing and many other processes that support CI/CD. Ultimately containerisation using Kubernetes can transform a system from something that’s difficult and slow to pilot, into one that is much nimble.

Step Three: The Infrastructure as Code production line

Along the automation theme, an infrastructure-as-code (IaC) setup which ensures automated and complete provision of various environments will be another crucial factor in speeding up release cycles. This means creating configuration files for automatic management and provisioning for the system at hand. IaC provides a steady production line of consistent environments, which is necessary for a sustainable approach to faster deployments. Centralised management of these environments is achievable with tools such as Terraform, Ansible or Azure Resource Manager, for example.

Step Four: A barrage of automated testing

Faster feature releases are fantastic, but they are useless if poorly tested and error prone as a result. Test automation is the answer to scaling testing across a containerised system.

Before a developer deploys code into production, it must pass through multiple staging environments, in each of which it will be subject to a barrage of automated tests. Godel’s test automation engineers write scripts that cover a long list of defined user journeys and scenarios. With this approach, teams deploying multiple times a day can be assured that their QA process can keep up.

Furthermore, a developer willing to experiment will be able to be much more adventurous in a shorter space of time with proper automated testing in place. With smaller releases, IaC and test automation as de-facto standards, they can circumvent waiting for 2-week sprint cycles to complete and instead encounter and try solving problems themselves, applying manual testing where necessary.

Step Five: Keeping an eye on things

Once things are up and running, systems cannot be left to their own devices. Effective logging and monitoring systems across every single facet of the software is how developers can ensure no deployment has a negative impact, no matter how subtle that impact is. In combination with the previous four steps, developers will be able to quickly spot system issues and roll back deployments with immediate effect, with little to no impact on users.

In practice, a great example of where this is not just necessary, but a fundamentally valuable component is in “canary deployments”. This is a practice which sees developers take a small portion of their user base and expose them to a certain experimentative scenario. The logging and monitoring system will show how this “canary” sample is affected by the scenario, so the developer can decide whether to implement the feature for everyone or roll it back.

Want to learn more about how Godel’s approach helps clients deploy code faster? Get in touch with us for a conversation!