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:
- 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.
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.
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
florista project. This project contains these files in
docroot/sites/default/settings.phpcontaining tokens with database credentials
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
The end result is that, after scaffolding, the project root for this environment looks (ignoring any existing, other files) like this:
docroot/sites/default/settings.phpcontaining actual database credentials
The next step is for the system to read
platform.deploy.yml, if it exists, and sync specifically the scripts mentioned
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.
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.
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.
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.