Continuous Integration, Delivery, and Deployment: Behind the Hype

A big trend in SaaS software development over the past decade has been the rise of “continuousness” as part of the larger industry adoption of Agile practices and DevOps culture. This is true of website development as well, though because of the nuances of managing content in addition to configuration and functionality, websites present some unique challenges.

Pantheon was founded on the principles of Continuous Integration and Continuous Delivery (CI/CD), and we’re proud to champion these workflows within the wider community of WordPress and Drupal developers. In this piece, I’ll explain what the main types of “continuous” workflows represent, and why they matter for both developers and site owners.

The Continuous Delivery Core Value Proposition

The goal of Continuous Delivery is to improve the velocity of progress and reduce the risk of error by allowing releases to happen more frequently, getting smaller more incremental changes live quickly rather than holding up a ton of changes for one “big bang” release. In a perfect world, Continuous Delivery means you can release at will, though you may choose to hold your deployment until the time is right.

This is crucial for projects of moderate to high complexity, where the risk of “last mile” problems can be extremely high. It’s also crucial on projects where multiple developers are collaborating. Nobody wants to find out after weeks (or months!) of work that their code conflicts with something their colleagues developed, and have to refactor or start over.

Continuous Delivery is also vital when working to improve an a website post-launch. You can’t afford to freeze the site during a development cycle; content updates and data gathering are a core part of the application value and you can’t just turn them off. You also don’t have the luxury to engage in the kind of wholesale redesign/overhaul that working in a pre-launch context allows.

Updates need to be seamlessly released into a live, running, living, breathing website application. This is the only way to make the kind of iterative progress on an existing site—leveraging the build, measure, learn cycle—that real greatness requires.

For site owners or stakeholders, there is huge value in a process that lets them see changes quickly:

• Demystify the development cycle: frequent builds means you’re able to check in on progress all along the way, rather than waiting—and worrying—for weeks on end.

• Decrease uncertainty and stress: iterative builds and the ability to release at will mitigates the risk of launches going sideways.

• Same budget, more website: more efficient teams with faster feedback loops can accomplish more work in the same amount of time.

• Build, measure, learn, succeed: industry leading practices like A/B testing and data-driven development are all predicated on the ability to iterate.

For development teams the benefits are similar: greater clarity around goals, fewer last-minute surprises, stronger collaboration. Ultimately it all leads to shipping stronger code, building a better internet, and having happier clients—outcomes that everybody can get behind.

The Continuous Integration Epiphany

In the context of websites, Continuous Integration means frequently combining all pending code changes with the latest content from the “real world” of the production environment. This is the single most important bar to clear; it is an epiphany for development teams, project managers, and site owners or stakeholders.

When working on a website, you ideally integrate any time there’s a change to the code (e.g. with every commit to version control). In practice, you might integrate a sub-set of changes in real-time, while doing a full CI run on an hourly or daily schedule. But the point is that you are making sure everything fits together in near real-time, and addressing failures (aka “broken builds”) immediately.

That immediacy is the key. It’s vastly more efficient to solving conflicts, integration bugs, or design issues due to production content changes in the moment, versus days or weeks after the changes were made. It also significantly reduces “last minute” bugs from blowing up launch deadlines. It’s just a better way to work.

CI does assume some automated testing, which can often feel like a blocker, or a daunting amount of effort. However, the depth of testing does not need to be very deep for CI to deliver enormous value. More often than not, integration failures are far from subtle; breakage is obvious. The value is in detecting these cases as quickly as possible so they aren’t a last minute discovery.

You don’t need a large or distributed team of developers to see value from CI. If your website is being actively managed there’s a high rate of change in content from the live production environment. Even a lone developer will benefit enormously from integrating those changes into his or her workflow on a daily basis.

For site owners, a green build status from CI is “proof” that you’re ready to deploy—it’s how you know you’re getting the value you need. It’s also often the exact same environment that you can use for on-demand acceptance testing. If not, the tooling to manage a CI process can easily give you environments to review and provide feedback.

The Continuous Deployment Utopia

Continuous Deployment (as distinct from Continuous Delivery) is an aspirational goal, in which a team has sufficient faith in their project’s automated testing that changes can be released immediately when tests pass. This essentially removes any final user-acceptance testing, review, or manual timing considerations from the equation. Developers love this because it is the ultimate in confidence and velocity, but few website projects are able to make the necessary investment in testing (including the cost of designing and developing an easily/reliably testable website) to reach this ultimate goal.

However, as an ideal it has a lot of value, and there are some specific situations where Continuous Deployment is visible on the horizon. In particular, we see Continuous Deployment as imminently achievable when it comes to rolling out updates from “upstream”—that is updates that are minor or point releases to the core CMS, rather than project specific changes designed to change the look, feel, or functionality of the site.

In theory, upstream updates should have no impact on the functionality of a website. New features won’t yet be implemented, and bugfixes or security patches shouldn’t break existing functionality. In practice we all know that’s not really true, and that blindly applying core updates to WordPress or Drupal can have unpleasant side-effects.

A strong test suite can catch those side effects. Behavioral tests like those written in Behat can tell you when functionality break. Plenty of sites could safely do Continuous Deployment of security updates with visual regression tests as the primary safety net. We do that with one of our WordPress sites.

This has a great deal of potential value for anyone who has responsibility for a large number of sites, be it an agency, a university IT team, or the web development group within a corporate marketing department. Nobody wants to lose a day—or more—of time deploying core software updates, but you also don’t want to fall behind, especially on security patches.

A solid Continuous Integration workflow with visual regression testing could take care of 90% or more of release work. That gets you to Continuous Deployment for the routine cases, and allows the team to focus their attention on the edge cases, either instances where the visual regression failed, or where there’s existing work in progress that needs to be managed or put aside to do the core release. For site owners, this provides the ultimate peace of mind around the security and quality of their core website infrastructure.

In summary, there’s a reason everyone is excited about the tectonic shift from quarterly (or even annual!) releases, and towards higher-throughput cycles. All it takes is a little smart technology and you can eliminate risk, improve quality, and respond quicker to market needs. Breaking the habit of a slow-paced legacy workflow isn’t easy, but the wins are there for both dev teams and site owners.

Learn more about how a streamlined DevOps workflow can help build efficiency in The Definitive Guide to Agency Optimization.

 You may also like: 

• Continuous Integration Is for Teams [BLOG]

• Continuous Integration: Pull Requests, No Distractions [BLOG]

• Why Version Control? Collaboration, Accountability, Security [BLOG]