Can the Waterfall method leverage CI/CD+ and still be considered Waterfall?

Question

Often it seems to be assumed or implied that DevOps is simply the Agile method expanded beyond programming to things like Operations and Configuration as Code, and so forth. So, this has left me wondering: Can a classic Waterfall method incorporate CI/CD and Configuration as Code and still be considered truly a Waterfall software development method?

Answer 1

I don't see why not.

Sequential SDLC models, like waterfall, are about the organization of steps. The requirements are "finalized" before extensive design begins. The design is "finalized" before the implementation begins. System testing happens after the requirements are satisfied. Some waterfall-like models, such as the sashimi model with some overlap between these phases or waterfall-with-subprojects, are multiple waterfalls after the overall system requirements and architecture have been completed.

There's nothing in the organization of these steps that would prevent continuous integration or configuration of code. Continuous deployment to a development environment is also possible, but continuous delivery or continuous deployment to production may or may not be possible, depending on the usability of interim builds before the requirements are complete. These practices can still be used once system implementation begins. CI and automated tests can help developers find issues during development before system integration and system testing activities begin. Configuration as Code can help with the configuration management of the system, allowing it to be versioned alongside the software system and rolled out to different test and production environments when it's time.

The key difference between highly sequential models and iterative and incremental models is responding to feedback, not the practices that can be used. Some practices may not make as much sense to use, especially if they are about getting and responding to feedback. If you have "finalized" requirements and "finalized" designs before you can start getting feedback on the system, stakeholder feedback will likely change those requirements and/or designs. Because of the scope of the work of requirements and design and the impact on the built system, late changes are expensive.