General Deploy Flow

The general deploy flow is used by all non-Drupal projects and selected Drupal projects.

It replaces the hardcoded exceptions the Drupal flow uses with reading in a file from the repository so the project itself can determine which folders must be synced and what scripts, if any, must be executed afterwards.

The structure of this file is as follows:

Deploy File

• Filename: platform.deploy.yml
• Location: after scaffolding, should be located directly in the project root. If the contents are identical for all environments, can be committed directly in the root of the project instead of inside a scaffolding folder.
• Structure (example):

sync:
  exclude:
    # A list of folders and files to exclude from syncing. 
    # By default the entire repo gets synced to the application folder
    - docroot/media
    - tmp
    - docroot/app/config/local.php
    - docroot/index_dev.php
    - ...
tasks:
  before_sync:
    - type: shell # Currently we only support type 'shell'
      script: "pre-deploy.sh" # Any paths here should be relative to the application folder.
  after_sync:
    - type: shell # Currently we only support type 'shell'
      script: "deploy.sh" # Any paths here should be relative to the application folder.

Scaffolding

All projects that use the general deploy flow have support for a scaffold folder inside the .dropsolid folder, located at the root of the project.

Inside the scaffold folder are two types of folders. __templates folder, which will be copied one level up when a new environment gets created and environment specific folders named after the environment they are for.

The first step of the deploy process is to scaffold these files. As an example, we will deploy the dev environment for the florista project. This project contains these files in .dropsolid/scaffold/dev:

• docroot/robots.txt
• docroot/.htaccess
• docroot/sites/default/settings.php containing tokens with database credentials
• platform.deploy.yml
• pre-deploy.sh
• deploy.sh

We first replace any tokens in these files (see ‘Tokens’ for more info). Then, we copy the contents of the entire .dropsolid/scaffold/dev folder to the application folder, overwriting any files that may exist.

The end result is that, after scaffolding, the project root for this environment looks (ignoring any existing, other files) like this:

• docroot/robots.txt
• docroot/.htaccess
• docroot/sites/default/settings.php containing actual database credentials
• platform.deploy.yml
• pre-deploy.sh
• deploy.sh

Pre-deploy script

The next step is for the system to read platform.deploy.yml, if it exists, and sync specifically the scripts mentioned in tasks.before_sync. Those scripts will get synced to the actual application folder on the server and executed as the environment user. These scripts can be used to verify the integrity of your application, or create a backup before actually starting the 'real' deployment process. If any of these scripts fail (exit with a code higher than 0), the deployment will be stopped.

Syncing

After this the system reads the platform.deploy.yml file, if it exists, to determine what folders, if any, to exclude from the rsync. Then, in a single rsync taking into account the excludes, all files get moved to the application folder on the server.

Afterwards, the system once again reads the platform.deploy.yml file to determine what to do now. If a shell script is defined under the tasks.after_sync key, the system runs said script as the environment user.

__templates

The other type of folder inside .dropsolid/scaffold is used when creating new environments. All contents from the __templates folder get copied over to .dropsolid/scaffold/<new_environment> so each environment can start with the needed scaffolding files immediately.

local

Sometimes, there will also be a local scaffolding folder. This contains files for use locally. Launchpad currently does not support scaffolding these files yet, so you may have to manually call a script or create a script to place them in the current spots. Alternatively, the files you commit in the repo can be used as the local equivalent, as scaffolding overwrites any existing files.