I manage CiviCRM installations on various servers (typically 1 client = 1 VPS). This usually includes roughly the same Drupal core and contrib modules, CiviCRM core and extensions, and translation files. While each client has their own specifics, I try to standardize as much as possible.

I was wondering what tools are recommended to 'build' the platform for production environments? Is buildkit recommended? If yes, any examples on how to use it with custom platforms? (my set of drupal modules + civicrm extensions)

I have been using "drush make" until now, but I find myself fighting with it more often that I should. For example, it cannot download "civicrm.mo" files (because it does not recognize the mime type). It also does not run composer automatically on projects, and I find it useful to use composer in extensions, to avoid bundling third-party libraries in my git repo. Custom build scripts become clunky shell scripts that re-invent the wheel.

Ideally, I would also like to manage the source code of CiviCRM itself in git, which means running composer/npm install on the code base. This makes it easier to backport patches when necessary, track local changes, and have the same tool chain in dev and prod.

Would composer be a good option for that? For example, I stumbled upon Using Composer to build your Drupal 7 projects, which uses PHP packagist.

1 Answer 1


I like that drush make or composer reduce the amount of code in your repository, and encourage IMO better development workflows (eg submitting and documenting patches rather than forked codebases).

However I am also running into challenges using Drush, which is quite Drupal-centric and requires some working around rather than with if you don't do what it expects (profile modules to profiles/ folder etc).

Best of both worlds if you build a deployment branch which is the complete codebase, but it does require that the whole team is OK with patchwork and building - this may be a factor.

Two nights ago I noticed that deploying CiviCRM codebase via Git had a cost of an extra 100MB per site (plus some). Not the biggest cost, but may be a factor if hosting many CiviCRM on a server.

  • Hi Chris, thanks for your response! Extrapolating on your comment, would it make sense to deploy a platform that is in a single git repo (Drupal + CiviCRM + modules + extensions), but without the civi tools/tests directories? Makes it easier to track local/temp changes when necessary, easier to deploy/update than rsync (and rollback). Although I still have the issue on how to do the actual build though (drush make/composer), and would love to hear about folks who have a strong opinion on a way or another.
    – bgm
    May 29, 2015 at 19:00
  • .. although one downside: translation .mo files will take a lot of space in the git repo, so I would avoid committing that. One upside: Jenkins could monitor Drupal/CiviCRM repositories and automatically triggers builds of the platforms, so clients would just have to git fetch/checkout.
    – bgm
    May 29, 2015 at 19:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.