To ensure a perfect system and tell the deployment system what it should do during a deployment, your Git repository requires an
.amazeeio.yml file to be present. It is written in YAML and needs to be in the root directory of the Git Repository.
The most minimal file looks at follows:
sitegroup is the only required key that needs to be present, all other keys are optional, but provide a lot of power. For a Drupal 8 with composer site and npm as frontend build system the
.amazeeio.yml file could look like following: (see more examples as subpages)
sitegroup: mysitegroup deploy_tasks: development: before_deploy: - composer install - npm install - npm run gulp -- compile after_deploy: - cd web && drush -y updb --cache-clear=0 - cd web && drush -y cr production: before_deploy: - composer install - npm install - npm run gulp -- build after_deploy: - cd web && drush -y updb --cache-clear=0 - cd web && drush -y cr branch_deploy_tasks: testbranch: before_deploy: - composer install - npm install - npm run gulp -- build after_deploy: - cd web && drush -y sql-drop 2>&1 - cd web && drush -y sql-sync @prod default 2>&1 - cd web && drush -y rsync @prod:%files default:%files 2>&1 - cd web && drush -y updb --cache-clear=0 - cd web && drush -y cr shared: production: - src: files dst: web/sites/default/files versions: node: 4
Explanation of keys
Defines the name of the site group this Git repository is in. You receive this sitegroup whenever you create a new sitegroup.
Group for all tasks that are automatically run during a deployment, unless there are branch specific tasks defined.
deploy_tasks: development: before_deploy: - npm run gulp -- compile
deploy_tasks: development: after_deploy: - cd web && drush -y updb --cache-clear=0
List of single tasks that are run before the releases folder gets public during a deployment to a site marked with the environment type production. These tasks are run inside the
releases directory for this release. No commands doing database changes should be executed here. See steps during a production deployment.
deploy_tasks: production: before_deploy: - composer install
List of single tasks that are run as after the releases folder is public to a site marked with the environment type production. These tasks are run inside the
public_html directory. Commands doing database changes should be ran here. Failed commands will trigger a rollback of this deployment. See steps during a production deployment.
deploy_tasks: production: after_deploy: - cd web && drush -y cr
Group for tasks specifically to a branch. If defined, they run instead of the defined tasks within
The structure is exactly the same as
deploy_tasks, just with the defined branch name as key instead of the environment type, example:
branch_deploy_tasks: testbranch: after_deploy: - cd web && drush -y sql-drop 2>&1
See Automatic Synchronization of Sites - Continous Integration for a real live example of using branch deploy tasks.
Applies only to sites marked as type production, as type development sites do not use symlinked and releases folders.
List of files or directories that should be symlinked from the
shared directory inside the home directory, into the
public_html directory. (the
shared directory is synchronized across all backend servers in a cluster stack).
Each element in this list requires two keys:
src- the source directory or file within
sharedthat should be symlinked. Need to exist of the deployment will fail and be stopped.
dst- the destination directory or file where the symlink to
srcshould be created. If already existing the deployment will be failed and stopped (to prevent data loss).
shared: production: - src: files dst: web/sites/default/files
This example will create a symlink that is as follows:
~/public_html/web/sites/default/files -> ~/shared/files
Defines installation and usage of software or tools on the CLI. (the PHP Version is defined during setup of the site and not in the
Defines the version number of Node.js that should automatically be installed and used. Can be defined as either just a major version number like
4 or specific versions like
6.3.0. We're using
nvm to handle the different nodejs versions, please check with nvm which versions do apply.
Performance Implications: Be aware that deployments and logins will be slower when a specific node version is defined.
If defined, every connection via SSH to a site or deployment tasks will have the defined version of nodejs first installed and all nodejs specific commands are ran with that version (like
If no versions of node is defined, the default of amazee.io (newest LTS version) is used.
versions: node: 4
This will install the newest available minor version 4 of Node.js.
Please see the examples for different Drupal Versions and other ideas as subpages.