Usage Costs and Benefits of Continuous Integration in Open source Projects

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:

• If you have multiple developers on your team, especially ones that may be changing over time.
• If your site is being developed by a distributed team, especially geographically spread out across different time zones.
• If your project includes integration with other systems.
• If you are handling transactions in your site.
• If you are treating your site like a product where you are regularly gathering feedback and releasing features over the lifecycle of the site.

Even in cases where you are a "one-man band" developer, CI may be of benefit. Just like we always recommend source code management for a project even with single developers, some of the other CI practices also apply. If you are using an open source platform like Drupal, be a good steward for the company or organization you are working for and follow best practices so that the next person in the door can pick up where you leave off.

Summary

At the end of the day, if you are building a web application or website with a CMS platform such as Drupal, getting started with Continuous Integration for your project is a good thing to do.

• It will help you mitigate risks and improve quality.
• The cost to get started with CI is probably not as high as you think. Remember, some of the setup costs will be used in all of your future projects, so the long-term costs of CI as overhead will be greatly reduced.
• Many types of projects can benefit from CI, not just the big ones. Your breakeven point for implementing CI is not based on the size of the project or the size of your development team, but much more on the lifecycle of your sites. The longer you live with them and continue to build and develop them, the more CI will help reduce your costs and improve on the return.
• Automating builds and tests with CI processes can eliminate hours and often days in a project each time new features are developed, tested, and released. Multiple that by multiple projects or sites and the answers to the questions of need and value for CI become readily apparent.

Business stakeholder tip:

If your development team or vendor doesn't mention any of these kinds of things related to CI or share visibility with you into their development and testing processes, you should run for the hills (no, not really). Instead, you should ask them to explain their processes and how they will ensure best practice development and QA for your site. You may never drill down into their code commits in Git or site build tests, but it is nice to know that you can and even nicer to know that they are practicing quality development and testing with CI.

Developer tip:

Be open with your stakeholders or customers about what you know and don't know. Offer to bring on more experienced developers to backstop you and help skill up your team. Drupal is a pretty friendly open source community and lots of folks are often willing to help out and augment another development team to build up the collective ability. Also check out a local DrupalCamp or Meetup. CI practices are a hot topic and often brought up as point of conversation and sharing.

Drupal strategy tip:

If your company or organization is heavily invested in Drupal, and you are using Drupal strategically across the board as the web CMS platform of choice (a university or state or federal agency who is standardizing on Drupal for all sites is a good example), pay extra attention to CI. Being able to run any of your Drupal site projects through a standard CI process is key to ensuring long-term quality, resilience, and support.

Want to know more about Drupal development?

Check our training schedule.

waldenothy1988.blogspot.com

Source: https://www.prometsource.com/blog/continuous-integration-worth-it

Share this post