It is well known that DevOps processes are a great compliment to the Agile development methodology. Codifying and automating testing, deployment, security and infrastructure make it easier to release at an accelerated cadence. Too often though, DevOps and Agile get conflated and combined into a package deal – you can’t have one without the other. In order to apply DevOps you need to be Agile. Not true. DevOps-ifying your Waterfall projects can realize “benefits” without an Agile transformation.

Here are some examples across the standard SDLC:

1 - Requirements Gathering and Analysis

Build non-functional requirements in from the beginning. By leveraging automation in the development process, it becomes easier to think about performance testing. By defining infrastructure as code, you can spin up production-like environments with ease. Using secrets management tooling, you can define key and password rotation rules and you can have traceability from role-based access requirements to the code that defines those roles.

2 - Design

Because infrastructure is defined as code and deployment and testing is automated, the design process becomes much more concrete. Utilizing documentation tools that generate automated tests and stubs (Postman + Swagger is a great example) also means that your design phase is kick-starting your testing phase. The gates of the design phase can also be tied to the configuration that will be used directly to create the application. No more reviewing a network diagram, you can review the YAML that will define the networks where the application will be deployed.

3 - Implementation and Coding

Utilizing a code management tool (GitHub, BitBucket, GitLab, etc.) can tie code commits back to specific requirements either by utilization of branching, tagging, or direct integration with a requirements management tool (JIRA, etc). Once a release is locked for testing, you can isolate the changes going into that release by using branching and/or tagging. Unit, feature, integration, and performance testing can then all be automated on these branches and/or tags. Because infrastructure is defined as code, different environments can be created per feature (if desired and budgeted).

4 - Testing

Automating critical path user acceptance testing paths allows for more exploratory testing during the testing cycle. Various tools exist to translate “plain” English requirements into automated browser-based tests; however, their use still requires developer support to enable their seamless use.

5 - Deployment

Here of course is the most obvious direct application of DevOps methodology. Since the infrastructure and configuration has been codified and automated, the deployment process is much more controlled. Creating staging environments and deploying changes there first is also enabled and enforced by proper use of infrastructure and configuration tools.

6 - Maintenance

Now here is where I may fall back into Agile ways, but Maintenance becomes extremely easy using DevOps processes. Due to isolation of changes and traceability to specific branches, merging and cherry-picking changes enabled by code management tools, understanding what is deployed is kept clear. The ability to spin up an environment for releasing and deploying the proposed change in a controlled manner gives great insight into how the change will be employed in production. And if feature toggling solutions are used, deploying fixes into production and then slowly exposing them to users becomes possible.

So, there you have it. A DevOps approach for Waterfall without one mention of sprints, stand-ups, and product owners. Once the above is all implemented the release cycles can be shortened and may lead to a back-door Agile transformation. Afterall though, what is an Agile sprint, other a tiny little SDLC loop.

Photo by Robert Lukeman on Unsplash