Update a project installed via composer_manager or drush to a CI based Composer template under Drupal VM

If you have to go for a Drupal core update from a previous install based on composer_manager or drush (both deprecated), consider installing something robust, Composer friendly, that excludes vendor and core for a lightweight repository and enables CI and automation tools like Phing, Behat, PHPUnit, CodeSniffer, ...

If you don't have Drupal VM installed, head to the documentation.

This post will focus on the steps to move from one install type to another and will not cover Git, CI and production deployment.
Also, by using Drush for other purposes, it will still show the differences between Composer and Drush and why they can live together.

Let's consider that you have a standard scenario where your current environment is into production or staging and you want to perform the update on your local (dev) environment. 

Well, this is probably not for the cool kids that have comfortable hosting platforms, but, if you are on a custom VPS instance, chances are that you could have some steps to follow.

Install pfrenssen Drupal Composer template

• Go to https://github.com/pfrenssen/drupal-project then download or fork it into a directory reachable by your Drupal VM (covered by vagrant_synced_folders).
• Rename it into the project name (myproject in the examples below), that will be defined in your shared vagrant_synced_folders
• cd into it.
• composer install will create the "web" docroot + download the core and dependencies ;
  vendor and config will be placed outside of the docroot for a safer setup. Composer can be executed on your guest or Drupal VM but for better performances, prefer the one that does not have XDebug installed (most probably the guest: Mac OSX, ...).
• Create the entries in Drupal VM config.yml: vagrant_synced_folders, apache_vhost but not the db, that will be created by Phing later. If your db is already defined in the mysql_databases section, remove the db entry and drop the db on your Drupal VM. Note that your apache_vhost will use "web" instead of "public_html" or "docroot" or anything else. See this issue and below for examples.
• Go to your Drupal VM install directory (the one where you cloned the Drupal VM repo) then vagrant provision and vagrant reload (if you have several sites to update, repeat what's above first, for all the sites).
• Create the build.properties.local at the vhost root (myproject). See example below.
• Go to your Drupal VM vhost: vagrant ssh then in the VM cd into your vhost root (not web, example: /var/www/myproject)
• Install your project with Phing ./vendor/bin/phing install

Example values of vagrant_synced_folders and apache_vhosts

vagrant_synced_folders:
  - local_path: ~/vagrant/myproject
    destination: /var/www/myproject
    type: nfs

apache_vhosts
 - servername: "myproject.dev"
    serveralias: "www.myproject.dev"
    documentroot: "/var/www/myproject/web/"
    extra_parameters: |
        ProxyPassMatch ^/(.*\.php(/.*)?)$ "fcgi://127.0.0.1:9000{{ "/var/www/myproject/web" }}"

build.properties.local template

This file will override the values from build.properties.dist
The minimal config should be covered by the following values. Here, the db name will inherit the project.name (see the .dist file for more info).

# The project name, also used for dbname
project.name = myproject

# Database settings.
drupal.db.password = root

# The base URL. This is used for doing functional tests in Behat and PHPUnit.
drupal.base_url = http://myproject.dev

Replicate your previous environment

• From your production or staging environment, get a lightweight db backup, without the cache tables, by using drush (cd into sites/default/files then drush sql-dump > dump.sql) or faster with backup_migrate. Also, you could consider using drush alias for that.
• Remove the sql dump after downloading it, if it was done with drush in the files directory.
• Replace your Phing created db by your db dump.
• Based on your production / staging environment or your git master, get a list of the contributed modules and themes that are installed. You can also use drush for that drush pm-list --status=enabled --pipe --no-core. The real benefit with drush is that you will only have a list of enabled modules, so it is the perfect moment for cleaning up.
  Then go back to your local environment on your project root (so, on the parent of web) and install your contributed dependencies that will now live by default in modules/contrib and themes/contrib, based on the Composer template.
  Remember to exclude composer_manager if you were using it.
  Simply run for each  composer require drupal/[module_or_theme]. Remember to use preferably the environment that have XDebug disabled.
• Copy what was in your previous install into modules/custom and themes/custom
• On your Drupal VM, rebuild the caches in the web directory with drush cr

Update

Now that you also have a fresh release of Drupal, update everything via your Drupal VM.

• drush updb
• drush entup
• You will now have a local environment to test the updates.
• If you still have your config into sites/default/files/config_xxx, consider that on the next drush cex it will live at the same level as vendor (so outside of the "web" docroot"). It should not be visible if you use a public repo. Also, while deploying into production, remove the sites/default/files/config_xxx directory because it will be useless now.

What's next?

You can now enjoy what's inside this Composer template, report to the Readme.