Executing ce‐deploy

ce-deploy has a script called build.sh which is uses to trigger a code deployment. Essentially it runs through these steps:

• Looks up its location
• Loads _common.sh
• Parses the arguments passed in
• Exits if any required arguments are missing
• Checks out the infra repo we're building
• Sets up Ansible's extra variables
• Runs the target playbook

Although it's actually a little more complicated because it has a sense of succeeded and failed and can react accordingly. It has three possible "operations", which are documented in _common.sh. The intended operation at any given step is passed in as an additional argument like this. It defaults to deploy but if something goes wrong and it needs to roll back a build it will run itself again with "operation" set to revert to put back the previous build.

For added flexibility, each "operation" has its own shell script so you can call them separately, say for example if you needed to manually revert a build you could run revert.sh alone, or if you wanted to blindly deploy some code without a possibility of reverting you could use deploy.sh.

You'll note that in the scripts directory there some other shell scripts too. Mainly, there are a couple of helper scripts for managing the "track number". That's the current build number so ce-deploy knows where it is in the sequence when it has to carry actions like delete the last five builds or revert to the previous successful build. We rarely need to touch these scripts, but it's worth being aware of them.

Here is an example of what an execution of ce-deploy might look like in a GitLab CI config file:

    - /bin/sh /home/deploy/ce-deploy/scripts/build.sh --workspace "$CI_PROJECT_DIR" --playbook deploy/deploy-prod.yml --build-number ${CI_PIPELINE_IID} --build-id cewww-prod --own-branch 1.x --config-branch 1.x

We can see the workspace is set to a GitLab CI environment variable to the working directory of this job. We can also see playbook points to a path relative to the repo root, where our Ansible playbook lives. In GitLab for build-number we use the unique ID of the pipeline, but you can choose other variables in different CI products. build-id is a unique name for this particular version of this application, used to set a track file that stores the ID number of the last successful build.

Then we get to --own-branch and --config-branch - these are important arguments, they default to 1.x but they can be set to other values, such as devel for bleeding edge changes, or even a feature branch. This will make deploy.sh check out the devel branch of both ce-deploy itself and the ce-deploy-config repo prior to executing Ansible itself.

We can optionally set the boto profile that the boto3 Python library, using --boto-profile, for connecting to the AWS API from Python will use. The AWS secrets are in /home/deploy/.aws/credentials and any valid profile can be passed. Ansible will error out if the profile doesn't exist or the credentials are wrong.

There are other options you can see in the USAGE block, but those are the key ones. If you take the time to look at _common.sh more closely you can see all the actions I describe above and how they work.