Answers.Body: <p>I like that <code>drush make</code> or <code>composer</code> reduce the amount of code in your repository, and encourage IMO better development workflows (eg submitting and documenting patches rather than forked codebases).</p>
  
  <p>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).</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-29T19:00:07.827Z
Answers.Text: 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.
Answers.UserDisplayName: bgm
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-29T19:07:30.913Z
Answers.Text: .. 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.
Answers.UserDisplayName: bgm
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2015-05-28T23:00:33.193Z
Answers.LastActivityDate: 2015-05-29T02:26:17.690Z
Answers.LastEditDate: 2015-05-29T02:26:17.690Z
Answers.UserDisplayName: Chris Burgess
Body: <p>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.</p>
  
  <p>I was wondering what tools are recommended to 'build' the platform for production environments? Is <a href="http://buildkit.civicrm.org/" rel="nofollow">buildkit</a> recommended? If yes, any examples on how to use it with custom platforms? (my set of drupal modules + civicrm extensions)</p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Would composer be a good option for that? For example, I stumbled upon <a href="http://cambrico.net/drupal/using-composer-to-build-your-drupal-7-projects" rel="nofollow">Using Composer to build your Drupal 7 projects</a>, which uses <a href="https://packagist.drupal-composer.org" rel="nofollow">PHP packagist</a>.</p>
  
Tags: <sysadmin><hosting>
Title: Mass hosting best practices for source code management of CiviCRM platforms?
ThreadText: # Mass hosting best practices for source code management of CiviCRM platforms?
  
  (Asked by: username_0 on 2015-05-28)
  
  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](http://buildkit.civicrm.org/) 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](http://cambrico.net/drupal/using-composer-to-build-your-drupal-7-projects), which uses [PHP packagist](https://packagist.drupal-composer.org).
  
  **Tags:** sysadmin, hosting
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2015-05-28. Score: 3 | Accepted answer
  
  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.
  
  > **Comments:**
  > **username_0**: Hi username_1, 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.  
  > **username_0**: .. 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.  
  
  ---
  
  