With continuous delivery, the most important mandate is to avoid setting unrealistic goals such as, ‘We want to be like Facebook and do one zillion deployments a day.’ Rather, get quick wins under your belt, gain momentum, and set bigger goals.
Continuous delivery is a progressive journey that doesn’t happen overnight. For example, not everyone needs to deploy hourly to achieve business outcomes. Many companies that go from monthly to weekly deployments have made a massive impact on their business.
If you’re starting out, realistic goals include: automating the promotion of code across development, QA, staging, and production environments; increasing deployment velocity from monthly to bi-weekly cycles; reducing deployment effort from several engineers to a single engineer.
As you get more advanced, goals might look like: migrating from blue-green deployments to canary deployments; reduce rollback time from 30 minutes to five minutes; templating deployment pipelines so all teams have consistent deployment pipelines. For experts, take your goals up a notch with: empowering every developer to deploy their own code in production; reporting and quantifying the business outcome of every deployment; performing automatic verification and rollbacks based on business anomalies or regressions.
But most organisations don’t become continuous delivery wizards overnight. Here are some tips for empowering developers and DevOps teams to embrace continuous delivery.
Where is your organisation today?
Like anything, understand where you are today and where you want to be. This three-stage maturity model reflects where most businesses are in their continuous delivery journey:
Simply put, how often are you shipping code? And who is responsible for deployments? Is it IT operations, DevOps, or developers?
Around half of medium-sized to enterprise companies are in phase 1, meaning IT operations (specifically release and deployment teams) are responsible for deployments — most of which do monthly release cycles.
About 35 per cent of companies are in phase 2, where a dedicated DevOps team exists and is primarily responsible for platform engineering, CI/CD, and automation.
Less than 5 per cent of companies today are practicing continuous delivery as-a-service. For many, stage 3 is where the majority of businesses want to land; it’s very much the holy grail of software delivery. This stage is where developers have high levels of autonomy to build their own deployment pipelines so they can deploy to production on their own.
Organisational characteristics & requirements of continuous delivery
Typically, companies use a deployment model that is either owned by IT operations or DevOps. This model tends to work best with monolith and SOA applications because small dedicated teams can easily manage monthly release cycles.
Unfortunately, this centralised deployment model breaks with microservices, serverless, and cloud-native applications. More components with higher levels of parallel development often means a hundredfold increase in change and deployments.
To overcome this bottleneck, IT Ops and DevOps teams need to empower developers with a self-service platform. This unfortunately does come at a price. Giving freedom to developers has a dramatic impact on security, compliance, visibility, and reporting requirements — because the number of people now deploying could easily increase by at least hundredfold. With great freedom comes responsibility, and organisations still need retain a level of control. If you’re building your own continuous delivery platform, don’t bolt on this.
Who owns building deployment pipelines for your services?
A deployment pipeline is a logical group of stages that code must progress through for it to be ready for customers in production. Stages typically map to environments like dev, QA, staging, and so on. Within a stage you typically deploy code to infrastructure (aka environment) and run a series of tests to validate that everything is functionally and non-functionally sound with the latest build artifact.
Think of a deployment pipeline as a car production line. The car goes through a build process and is promoted through different test areas of the plant where it is inspected and verified using tools before it is finally delivered to the customer. If at any stage a defect is found, it is rejected and sent back to be fixed before it can proceed to the next stage.
In most organisations, a centralised DevOps team is typically responsible for building deployment pipelines. Think of DevOps as the designers and architects for the car production line. They’re ultimately responsible for the structure and governance of everything within a deployment pipeline (environments, tools, tests, standards, security).
Once a deployment pipeline template has been created, make it available to release and deployment engineers or developers to instantiate and use with their own service artifacts.
Who owns deployments for your services?
Once deployment pipelines exist, you need to decide who is responsible for pushing that big shiny deployment button.
Again, IT operations and centralised release/deployment teams have traditionally been the owner of deployment buttons. DevOps teams today are slowly transitioning this responsibility to application development teams. DevOps culture and continuous delivery is a huge part of enabling this transition.
You can go two directions with continuous delivery: human-driven deployments (semi-automated) or event-driven deployments (fully-automated).
The first is where a human manually kicks off a deployment pipeline and it progresses through the various stages. When the time is right, remove manual approvals and blocks from your pipelines to drive more automation.
The end goal for many companies is to kick off a deployment pipeline automatically based on a developer checking in code and creating a new build: each new artifact should then automatically progress through dev, QA, staging, and into production with little or no human supervision.
Who manages your continuous delivery configuration?
Finally, where does your continuous delivery configuration sit and who manages it? Is it IT operations or DevOps teams? Is it piecemeal or a single pane-of-glass? And who should own it going forward?
One important last point: It doesn’t really matter if you’re at continuous delivery maturity level 1, 2, or 3. No matter where you are, you’re in the game—and you can improve. Whether it’s IT ops, DevOps, or developers who own your pipeline and want to deploy, you’re on the path to enhancing and improving your deployment process and reaching ‘continuous delivery nirvana.’
Steve Burton, DevOps Evangelist, Harness
Image Credit: Profit_Image / Shutterstock