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.
- Your developers commit some code to a repository (e.g. in Git)
- They push that code up
- The update to the repository triggers a job on your CI server (e.g. on Jenkins)
- The job kicks off code deployment automatically
- It runs Drush commands to update the database and revert Features
- It runs some tests on the site build (e.g. automated unit, smoke, functional, regression, acceptance tests)
- 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 (I noted some open source examples and you can find more information in our additional posts and presentations on CI listed at the end).
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 for 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.
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.
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.