Usage

While you can re-use/fork roles or call playbooks directly from your deployment tool, it is recommended to use the provided wrapper scripts, as they will take care of setting up the needed environments.

Deploy with the “build” script

In the script folder, you’ll see a build.sh script. This is the easiest/safest way to trigger deployments, as it bundles all the steps in one.

Arguments

You will need to pass at least the following information:

• –repo: the git repo containing the codebase to deploy, alongside the deploy playbook to play
• –branch: the branch to checkout for the given repo
• –playbook: the path to the playbook to play, relative to the root of the repository to deploy
• –build-number: incremental number as generated by your CD tool

Steps

What this will do is:

• clone the given repository locally on the “deploy” server;
• call ansible-playbook in “deploy” mode
• in case of success:
• store the succesful build number for next time
• call ansible-playbook in “cleanup” mode (to remove older builds and artifacts)
• in case of error:
• call ansible-playbook in “revert” mode (to reset the state of the application to the last known good build)

Example

This how you’d call the build.sh from Jenkins:

/home/deploy/ce-deploy/scripts/build.sh --repo "git@gitlab.com:example/myproject.git" --branch "dev" --playbook "deploy/deploy-dev.yml" --build-number "$BUILD_NUMBER"

Deploy with individual steps

If you prefer having more control over the execution of steps, you can reproduce the same outcome using the other individual scripts.

Steps

• deploy.sh: call ansible-playbook in “deploy” mode
• revert.sh: call ansible-playbook in “revert” mode
• cleanup.sh: call ansible-playbook in “cleanup” mode
• track-get.sh: echo the last known good build number
• track-set.sh: sets the last known good build number