How we structure DevOps delivery
The baseline we use when we set up DevOps for a client.
DevOps is the practice of development and operations teams working together so software reaches users quickly and reliably. Without a shared model, each team invents its own process, releases become unpredictable and security checks get skipped. We start every engagement from the same simple baseline, then adapt it to the client.
Why a common baseline helps
A baseline gives everyone the same picture of how code travels from a developer’s laptop to a live service. It makes responsibilities clear and shows where controls such as testing and approvals belong. It also lets us compare a client’s current setup with good practice and agree what to change first.
What the pipeline is made of
DevOps covers many tools and ways of working. We group them into six parts.
Developer environment
Developers work best with tools they know, so we let them choose their own editors and platforms. The rest of the pipeline brings their work together into one consistent delivery process.
Source code management
Source code management (SCM) is the shared system where code is stored with a full history of changes. It lets developers review each other’s work and see who changed what, and when.
Build pipeline
The build stage turns source code into a package that can be deployed. Along the way it pulls in third-party libraries, which need to be tracked and kept up to date. A good build can be repeated at any time and gives the same result.
Artifact repository
Finished packages, called artifacts, are kept in a secure shared store. If a release has to be rolled back, the previous version is ready to deploy.
Release management
Continuous integration and continuous delivery (CI/CD) automate testing and release. The team picks a release strategy that limits risk. In a canary release, a new version goes to a small group of users first. In a blue-green release, two identical environments run side by side and traffic switches from the old one to the new one.
Deployment environment
The last part is where the software runs. Staging is used for final checks and production serves real users. Either can sit in a private data center, a public cloud or a mix of both, and the baseline works with any of them.
Where security fits
Every one of these parts is also a natural place for a security check. Adding those checks early is what turns DevOps into DevSecOps, and it is usually far cheaper than fixing problems after release.
Contact us
If you would like to talk through your own delivery pipeline, reach us through our contact form.