A Sparkle of Build-Automation to Aid Data-driven Decisions at British Red Cross

• Learn how Zühlke supported the British Red Cross

• Valuable feedback is more easily achieved when the focus is on rapid value creation for the end user

• GitLab offers a lot of useful features

In an ideal world, developers get swift feedback on their work, allowing them to quickly validate their code. In an even more ideal world, the whole team behind a single product rapidly gets feedback on the features they make available to end users. While working with the British Red Cross I enjoyed seeing how we made this a reality.

Timely and quick feedback

Timely and prompt feedback is more easily achieved by product development teams when the focus is on rapid value creation for the end user, allowing this to become the centre of their delivery practices.

Before I take you through what the engineering team at Zühlke did to achieve a total cycle time of 10 minutes, think what the world is like for the British Red Cross. They face an ever-changing environment and need to make accurate and informed decisions driven by data, a key factor to implementing their strategy - for example deciding where in the UK they are most needed.

We learnt what to develop for the British Red Cross through a series of UX workshops however the engineering team still needed to figure out how we were going to rapidly deploy the solution, provide value and bring feedback quickly back to the team to confirm our findings.

We needed a solution that would:

• Offer a version control repository.
• Track stories and progress chunked into sprints.
• Give team members management and access control.
• Set up CI/CD pipelines in a declarative manner.
• Store docker container images in a private registry.
• Manage credentials to keep things secret and away from source code.
• Integrate with Azure.

GitLab was the best match for all those needs. It was handy in a number of ways, but it also surprised us to see GitLab’s behaviour when forking our project - but I’ll reveal the details later on…

What did we do?

First and foremost we were clear in our approach. Our practices involved pair programming, test-driven development, continuous build, test, and deployment process and limiting work in progress and user-tests to corroborate our decisions.

In order to create a fast and reliable way to deploy working software to a production environment in Azure we started by creating a `.gitlab-ci.yml` file in our project. This file describes our pipeline configuration information. GitLab identifies it and automatically runs the pipeline, designed to run in three stages: build, test, deploy.

A couple of useful points are that tagging and versioning docker images are easily done with managed secrets in key-value based variables stored in GitLab and referenced in the pipeline configuration file. Azure had to authenticate to pull images from the private registry using simple to create deploy tokens. Gitlab’s image registry was easy to use from the pipeline - this registry is a great alternative to using and configuring a private registry such as one from a cloud provider. For example, it allowed us to push an image directly from a pipeline job, all within the same host.

We found ourselves developing a robust pipeline, if anyone forks the project they’ll get a pipeline running up to the Deploy stage which needs of secrets defined in GitLab to succeed and no other party should really access this variables or they could deploy a non-working version to production.

In summary, we are extremely proud to have been involved in a project which delivers direct value and impact to the people behind The Red Cross in a fully automated way - contributing to the vital work they deliver.