Is Continuous Integration Worth It?

When you start addressing the topic of Continuous Integration (or CI for short) for the first time with an organization or project, there are often some typical questions that arise.

• Do we really need to do this?
• Isn't this going to be costly to do? Can we skip it?
• Is it worth it for our type of project?

At Promet we work in the world of the open source Drupal platform, and I've had more than a few conversations with people at various companies and organizations regarding Continuous Integration for their Drupal projects and sites and how it impacts their customers. Since we've been talking about CI practices and tools quite a bit recently at Promet and throughout the Drupal community, I wanted to share a few additional thoughts on this question of need and value.

Read Part I here.

Read Part II here.

 

Does Continuous Integration apply to a web CMS project?

This type of question still comes up, and the short answer is yes. Web content management system projects—whether you are using Drupal or pretty much any other CMS software these days—are a web application or website projects. They follow and adhere to many of the same standards and best practices as any other software project.

While a website project and deployment may seem simple, it can actually be quite complex these days. A project involving a CMS, while reducing a lot of effort for content management, often introduces some of that complexity in website deployment as part of the trade-off. Long gone are the days of your webmaster manually moving files via FTP to deploy your website (and good riddance).

Talk to others or take a look through forums and posts for CMS software (doesn't matter if it's a PHP-based CMS like Drupal or a .NET-based one, an open source CMS or a proprietary one). You'll see that many people are looking at similar problems in their website projects and discussing ways to implement CI to mitigate common risks.

Here's a quick checklist for you of typical issues:

• You are "going commando" without source code management for your site and deployment process. No tracking. No rollback.
• You are deploying manually between environments. It's slow. It's brittle. It's painful.
• You are stuck in a "hot mess" of hotfixes. Not uncovering problems early. Forced into making changes late in the game.
• You are editing CMS configurations manually. And doing it on Staging or Production environments! (Everyone who has ever worked on a Drupal project ever knows this one.)
• You hear the all too common "it works on my machine" uttered by your developers. But then it breaks on Staging and Production. Now pair this with manual deployments... not fun.
• You do not have automated site builds or automated tests in place. Proper QA is painful or even non-existent.

If your developers are nodding their heads on any of these or similar issues, then you are already at a place where CI applies. Understand that CI is not going to magically fix everything at once, but it can get you back on the right path to a better web CMS project and start to make some tangible differences.

As an aside for Drupal implementations, we continue to see a growing need for CI practices to support the growing development demands. Drupal's one-two punch of web CMS platform and application framework drives its increasing use for implementations that need to scale out and up and for more complex projects often involving multiple integrations. Combine that with today's increasing business demands for faster changes, faster time to market, fewer errors, and faster delivery, and the question of the need for CI in many Drupal projects is quickly becoming less of “if” and more of “when.”

 

Doesn't Continuous Integration cost a lot to do? Can't we just skip doing it?

A common misconception is simply to think of CI as overhead in a web project, and expensive overhead at that.

First, is it really all that costly to implement some basic CI practices into your development process? No, not really. Let's take a look at a pretty typical example CI workflow with Drupal.

1. Your developers commit some code to a repository (e.g. in Git)
2. They push that code up
3. The update to the repository triggers a job on your CI server (e.g. on Jenkins)
4. The job kicks off code deployment automatically
5. It runs Drush commands to update the database and revert Features
6. It runs some tests on the site build (e.g. automated unit, smoke, functional, regression, acceptance tests)
7. You get a status report back from your CI server (e.g. pass/fail)

While you will have different variations, steps, etc. for this type of process depending on your Drupal project and it can certainly be more complex, the general concept is the same. Yes, it takes some effort to get this working for Drupal, but it is not a herculean task and there are improving tools and services that can help you.

Second, the idea that we should just skip this if it does cost us (time, money, etc.) is frankly not too compelling when you think about it. Yes, it is going to cost something to get started, but the costs of not doing anything are often much higher.

Let's go back to one of the common themes for CI. The earlier you get feedback, the earlier you identify problems and the less costly they are to fix. Say you skip implementing CI practices for your project and live with some of the red flag issues I referenced earlier.

Are you really saving money in your project that way? Those issues tend to fester and compound themselves as a project goes, and they get even more pronounced after you launch your site and have to live with it for the long haul. Problems that you missed early in your project and patched over with fixes late in the game have a tendency to cost serious dollars later during support and during upgrades. There is often a very sharp rise in relative costs for fixing defects at the later stages.

Looking at our own experiences at Promet, we do a lot of support for Drupal sites that people bring to us that were built by someone else. We've seen our fair share of "the good, the bad, and the ugly." We frequently talk about the need for sustainable development and operational practices for Drupal sites. Our point is that you need an approach when building a site with Drupal that does not leave you with a pile of technical debt. Good practices like CI are a key part of this approach. The old adage, "pay now or pay later" definitely applies and shouldn't be taken lightly, especially you are dealing with multiple projects and sites that need to be maintained over time and will continue to change as your customer’s needs evolve.

 

Is my project the right type to use Continuous Integration? Can I wait and do it later?

Even after understanding that CI applies to web CMS projects and that its benefits will outweigh the costs, there are still often questions about the "type of project" for using CI and when you should look to implement CI practices.

The simple answer could be "all projects" that you do, but that is not necessarily the realistic answer depending on circumstances. There are scenarios where CI may not be worthwhile the first time out of the gate or ever (e.g. a project that is very small, very short, and static—a site that will never be revisited to add or improve).

Another typical answer is to use CI for large projects. Indeed, sometimes you will see CI suggested or recommended in best practices only for building "big" Drupal sites. For example, typical practices for a "big" Drupal project are often given as:

• Get your configuration into code ("featurize")
• Use Git for source code control
• Use Drush (the swiss army knife of Drupal)
• Use Continuous Integration (there it is!)
• Use Vagrant for local development environments
• Get your infrastructure into code (configuration management)
• Use multiple options for scaling Drupal (e.g. Varnish, memcache, database optimizations, high availability configurations, etc.)

However, it can be a mistake to think of CI as only a "big" project. First, if you don't get in the habit of using CI practices when you do get that big project you are likely to be behind and land in trouble. In addition, the cost tends to drive higher if you are waiting to implement CI for the first time until that big, supercritical project. Second, remember that visibility is important for all projects, and starting CI helps you make sure everyone gets used to seeing what's happening easily with build and test status on every project.

Business stakeholder tip:

When you are planning out multiple projects and have more complex projects on the horizon, take advantage of your smaller projects to start implementing CI and cut your teeth on them. If your development team or vendor is not familiar with CI, then bring on some extra help to get them introduced and skilled up with CI. Use the consulting help to get your team started on the small project and then be there to assist them on the big project.

While there is no “one size fits all” answer, here are some examples of types of projects where CI is key and often critical: