Automated build and release pipelines
We replace manual deployments with automated pipelines in Azure DevOps or GitHub Actions, so every change is built the same way, tested, and released to a test environment before production.
What you probably want to know first
- Our releases are done by hand by one person. How do we change that?
- We write down exactly what that person does, then automate it one step at a time: build first, then tests, then deployment to a test environment, then production. Each step is checked against a manual release before the manual one is retired.
- Does it matter whether we use Azure DevOps or GitHub?
- Not much. Both do the job well. We usually work in whichever your organisation already uses, so the pipelines sit alongside your other code and permissions.
- What access do you need?
- Access to the source repository, permission to create pipelines in it, and deployment credentials for the test and production environments, held as secrets in the pipeline tool rather than in files.
- What have you done with systems like this?
- OpenIRIS releases through Azure DevOps Pipelines to separate test, release-candidate and production environments, with automated test runs and nightly dependency checks. Logtek's system also builds and deploys through Azure DevOps. This website builds and deploys through GitHub Actions.
Who this page is for
This page is for IT managers whose business system is released by hand, often by one person, and who want releases that anyone on the team can run safely and that leave a record.
Why manual releases are a risk
A manual release depends on someone remembering every step, in order, every time. When they are on holiday or leave, releases stop or go wrong. Builds made on a developer’s machine can include files that are not in source control, so the live system no longer matches the code anyone holds. We have seen production releases fail because the binaries, the database and the code had drifted apart, with no environment where the difference could have been caught first.
How we approach it
We do not start by changing how the system is built. We record how it is released today, automate that exactly, and only then improve it. The result is a pipeline that builds from source control, runs the tests, releases to a test environment first and keeps a record of what went to production and when.
Talk to us
Describe the system and what you need. You will hear back from someone who can answer technical questions.
Discuss your release process 0800 433 7990What a pipeline gives you
- The same build every time
- Code is built from source control on a clean machine, so a release never depends on one person's laptop.
- Tests before release
- Automated tests run on every change, and a failure stops the release.
- A test environment first
- Each release goes to a test or release-candidate environment before production.
- Releases you can trace
- Every production release links to the exact code and changes it contains.
- Dependency checks
- Packages with known vulnerabilities are flagged automatically, and routine updates are proposed for review.
- Secrets out of the code
- Passwords and keys are held by the pipeline tool, not in configuration files in the repository.
How we automate a manual release
Write down today's release
Every step the person who releases currently takes, including the ones they do from memory.
Automate the build
A pipeline that produces the same output as a manual build, checked file by file.
Add tests and checks
Automated tests and dependency checks on every change.
Automate deployment to test
Releases to a test environment with configuration for each environment held separately.
Automate production
Production releases from the same pipeline, with an approval step if you want one.
A good fit when
- Only one person knows how to release the system.
- Releases sometimes include changes that were not meant to go out.
- Configuration files with passwords are copied onto servers by hand.
Probably not for you if
- Packaged software whose vendor releases updates to you; the vendor owns their pipeline.
Questions we are asked
Can a pipeline deploy to our own servers, not just the cloud?
Yes. Pipelines can deploy to servers in your own data centre or office through an agent installed on your network, as well as to cloud hosting.
How long does it take to automate a release?
For a single web application with a database, usually days rather than weeks. Systems with several applications, scheduled services and manual database changes take longer, and the first step tells us how much.
Tell us about your system
Say what it does, what it is built on and what is worrying you. We will reply with what we would look at first and whether we are the right people to help.