Automated deployment with Bitbucket and Bitbucket Pipelines

Software is not built once and then left alone. It changes for as long as it is in use. The more manual steps lie between finished code and the running platform, the more expensive every single change becomes, and the greater the chance that a step gets forgotten the hundredth time. That is why we automate delivery as far as possible. Here is how our deployment works and which tools are involved.

What an automated deployment takes off your hands

A deployment is the provision of software on an environment. Traditionally it consists of several steps:

• Put the release together
• Prepare the configuration for the target environment
• Create the build and run the automated tests
• Deploy to the acceptance system
• Acceptance by the users
• Roll out to production

Everything that does not need a human decision is automated. What remains is acceptance. A release can therefore be deployed by the person who wrote the change. Nobody with special knowledge has to step in. And the path from staging to production is the same as the one from the development environment to staging.

The terms involved: continuous integration means merging and testing the code on an ongoing basis, continuous delivery a version that can be shipped at any time, continuous deployment delivery without a manual trigger.

From commit to environment

It starts with a change to the code: new files, changed lines, sometimes an adjustment to the database. Development happens in your own environment. The changes are bundled in a commit that is pushed to a branch in the repository, and that is exactly what starts the pipeline.

In the pipeline, the automated tests run in parallel. Behat checks behaviour-based scenarios, that is, the flow from the user’s point of view. PHPUnit checks the individual building blocks of the code and how they work together. If a test fails, the change goes no further.

If the commit passes the tests, a pull request follows. A second team member reads the code and approves it; only then is it merged. The merge triggers the deployment to the corresponding environment. While code and data are being swapped on the target branch, the system is briefly unavailable, and then the new version runs.

Three tools carry the process:

• Git for versioning the code.
• Bitbucket for repositories, commits, branches and pull requests.
• Bitbucket Pipelines for the build and test runs that start in parallel for each commit.

What this brings day to day

• The process is the same in every project, so a release no longer surprises anyone.
• Fewer manual steps mean fewer places where something can go wrong.
• Deployments take less time, because nothing is prepared by hand.
• The development team is not pulled away from its work for every release.
• The effort per release goes down, and with it the cost.

The process is part of our platform stack and runs the same way everywhere. Anyone joining a project finds the same pipeline as in the last one. That is the real gain from standardisation.