BLT for Development Platform.sh for Hosting

Tags: Platform.sh, Acquia Site Factory, BLT



At Axelerant, we use platform.sh during development and testing as part of our development workflow. It has many advantages. It allows the testing of new code with the production database before it is merged to develop/master, and supports many languages. Automation is at its core, and the latest versions of tools are rapidly made available (for example, PHP 7.2 support was added on the same day on which it was released). It also provides integration with GitLab—and the list goes on.

There are many tools available today to set up the local environment efficiently. Check the list here. We are going to discuss BLT (Build and Launch Tool). It provides an automation layer for testing, building, and launching Drupal 8 applications. There are a few advantages to choosing BLT for Drupal development:

  • Entry points already created for unit testing with Behat or PHPUnit
  • By default, all the code is validated against latest Drupal standards before every commit (I know this can be easily skipped, but it is still there)
  • Unified way of building setup scripts (BLT recently changed from XML based PHing to PHP based ROBO commands)
  • Integration with Drupal-VM (For Docker fans - Drupal-VM now supports Docker too)


I was evaluating whether we can keep using BLT for local development and still use platform.sh for testing by developers as well as testers and for external automation tools. This looked complex initially as BLT is tightly coupled to the Acquia ecosystem but the solution was actually very simple. Below are the steps required to make a project using BLT to deploy to platform.sh.

    1. Set up your BLT project as usual; you can check BLT onboarding documentation for more details.
    2. Add platform.sh specific files in your code.
      1. .platform.app.yml in GIT ROOT
      2. Make sure you use ‘build: flavor: none’ as BLT will deploy all the files*
      3. .platform directory with routes.yaml and services.yaml
    3. Add platform.sh specific changes, check platform.sh examples.
      1. Add settings.platformsh.php in sites/* directories.
      2. Modify settings.php to use settings.platformsh.php file on platform.sh env.
      3. Add drushrc.php in sites/* directories (will change to .yml in future).
    4. Main change - use platform.sh GIT url in blt/project.yml. BLT allows setting multiple remote URLs here. For now there is no way to push to only one remote; it will push to all the remotes provided here.

      Platform.sh-Project-Code

    5. Use ‘blt deploy’ as usual.

Pretty simple, right? Well, there was lot more going on in my mind before it actually got working, as BLT seems very tightly coupled to Acquia Cloud and its hooks. 

* This is something debatable. We are kind of moving away from the advantage that platform.sh provides. Quick answer to this - this is not the only advantage provided by platform.sh; we can still run post deployment commands through deploy hook in .platform.app.yaml. Also, all the files are still not committed to GIT for the main development repository which could be on Github or Gitlab.

While it may still be debatable whether to use BLT or not, but it is for sure a good candidate to look into.

Nikunj Kotecha, Back-end Developer
Posted by

Nikunj Kotecha, Back-end Developer

Guest Blogger