What's the optimal way to install and track CiviCRM with Drupal and git?

Question

First, I know compatibility with Drupal 8 is not full yet. There are still open bugs, a bunch of open PRs and an apparent lack of code review.

But let's ignore that for a moment and consider civi d8-ready. I want to do a test install for a migration from Joomla, but also maintain some level of tracking, so it's easier to work with custom changes and any (knock on wood) malicious ones are easier to detect and revert. Looking at various docs, I've found at least these options:

• classical install: drupal, civi
• drush: nicely handles downloads, upgrades and backups (no idea if it has VCS support by itself)
• composer: seems to be unofficially preferred for drupal8; not that much info available; more dependency heavy
• civi-buildkit: seems like a complete overkill, as I don't need a full development environment

All of them can be preceded by initing a blank git repo and manually tracking from there. The buildkit is already fully based on git. Can any of the others track upstream automatically, to avoid the need for manual commits-on-update and working with tarballs? Did I forget an even better option, some combination?

Answer 1

Drush can support VCS deployments and you can tell drush make to keep the .git directory with "drush make --working-copy your-platform.make". However, unless it's changed recently, drush doesn't have post-install hooks, so it won't handle composer/bower/npm well.

Composer has support for "post-install-cmd", but civicrm itself is not on packagist. I'm not familiar enough with composer to comment further, but from experiences so far, I find Composer more interesting than Drush on many many aspects (not CMS-specific, huge community, great tool).

Personally, and this is not an ideal solution: I build platforms (drupal+contrib+civicrm+extensions) using the tar.gz of each project. Extensions/themes that are actively developed get added as git submodules. All my servers use the same git repo (except for site-specific extensions/themes/modules which are in their own repos) and when I do upgrades, I run a git pull everywhere.

The main down side to this is that I cannot cherry-pick patches from upstream, which was the main issue of your question. I usually apply patches manually.

The main issue I had with running upstream git in production, is that this means I have to run composer/bower/npm/gencode on all production servers whenever there is a new version. That has a too high risk of failing (I manage ~ 20 servers, some with a mix of 4.7-D6, 4.7-D7, 4.6-D7, 4.7-WP).