Skip to main content

Continuous delivery and release automation for microservices

As software organisations continue to invest in achieving Continuous Delivery (CD) of their applications, we see increased interest in microservices architectures, which, on the face of it, seem like a natural fit for enabling CD.

In microservices (or its predecessor, SOA), the business functionality is decomposed into a set of independent, self-contained services that communicate with each other via an API. Each of the services has their own application release cycle, and are developed and deployed independently often using different languages, technology stacks, and tools that best fit the job.

By splitting the monolithic application into smaller services and decoupling interdependencies (between apps, dev teams, technologies, environments, and tooling), microservices allow for more flexibility and agility as you scale your organisation’s productivity.

While things may move faster on the Dev side, microservices do introduce architectural complexities and management overhead, particularly on the testing and Ops side. What was once one application, with self-contained processes, is now a complex set of orchestrated services that connect via the network. This has impact on your automated testing, monitoring, governance and compliance of all the disparate apps, and more.

Achieving CD through automation

A key prerequisite for achieving Continuous Delivery is automating your entire pipeline – from code check-in, through Build, Test, and Deployments across the different environments – all the way to the production release. In order to support better management of this complex process, it’s important to leverage a platform that can serve as a layer above any infrastructure or specific tool/technology and enable centralised management and orchestration of your toolchain, environments, and applications.

When constructing your pipeline, keep in mind:

  • Use one repository per service. This isolation will reduce the engineer’s ability to cross-populate code into different services.
  • Each service should have independent CI and Deployment pipelines so you can independently build, verify and deploy. This will make set-up easier, require less tool integration, provide faster feedback and require less testing.
  • Plug in all of your tool chain into your DevOps Automation platform – so you can orchestrate and 'automate all the things': CI, testing, configuration, infrastructure provisioning, deployments, application release processes, and production feedback loops.
  • Your solution must be tools/environment agnostic so you can support each team’s workflow and tool chain, no matter what they are.
  • Your solution needs to be flexible to support any workflow – from the simplest two-step web front-end deployment to the most complex ones (such as in the case of a complex testing matrix or embedded software processes).
  • Your system needs to scale to serve the myriad services and pipelines.
  • Continuous Delivery and microservices require a fair amount of testing to ensure quality. Make sure your automation platform integrates with all of your test automation tools and service virtualisation.
  • Auditability needs to be built into your pipeline automatically so you always record in the background the log of each artefact as it makes its way through the pipeline. You also need to know who checked-in the code, what tests were run, pass/fail results, on which environment it was deployed, which configuration was used, who approved it and so on.
  • Your automation platform needs to enable you to normalise your pipelines as much as possible. Therefore, use parameters and modeling of the applications/environment and pipeline processes so you can reuse pipeline models and processes between services/teams. To enable reusability, planning of your release pipeline and any configuration or modeling should be offered via a unified UI.
  • Bake in compliance into the pipeline by binding certain security checks and acceptance tests, and use infrastructure services to promote a particular service through the pipeline.
  • Allow for both automatic and manual approval gates to support regulatory requirements or general governance processes.
  • Your solution should provide a real-time view of all the pipelines’ statuses and any dependencies or exceptions.

Consistent logging and monitoring across all services provides the feedback loop to your pipeline. Make sure your pipeline automation plugs into your monitoring so that alerts can trigger automatic processes such as rolling back a service, switching between blue/green deployments, scaling and so on.

For both Continuous Delivery and microservices, a highly focused and streamlined automation pipeline is critical to reduce bottlenecks, mitigate risk, and improve quality and time-to-market. While some may choose to cobble together a DIY pipeline, many organizations have opted for a DevOps Automation or Continuous Delivery platform that can automate and orchestrate the entire end-to-end software delivery pipeline. This is particularly useful as you scale to support the complexities of multitudes of microservices and technologies. You don’t build your own email server, so why build this yourself?

Anders Wallgren at Electric Cloud

Anders Wallgren
Anders Wallgren is the chief technology officer at Electric Cloud.