What makes any practice continuous?

It's been about 2 years since the quarterly releases were mandated, and one year since the systems administration team had first been formed. The most recent release party resulted in a very low impact release. The engineering organization was able to significantly reduce the years of ignored technical debt. The company's product roadmap, promising a new product every year, recently went into effect. As a result, the automated delivery pipeline was now supporting two separate products in a repeatable, reliable, and scalable way.

A design choice that the systems administration team had pursued was building out an imperative configuration method for the automation solution. Looking back, the team realized that they would have had an easier time scaling through declarative methods instead. The need to quickly move away from the previous high-touch process drove the team to make some rushed decisions. Although variables could be added to the execution process, every new product required the team to clone and change the automation scripts to be successful. The new automation solution could only scale through this cloning process, resulting in heavy administration and storage costs.

The system administration team realized that for a tool to support their scaling requirements , the tool would need to support declarative configurations and executions. This requirement became abundantely clear as the architecture support requirements grew and changed. For now, the team could convert their scripts into more declarative templates to implement a short-term scalable solution. The system administrator team needed to get a new process in place, and fast. The previous process was error prone and highly manual, resulting in a mountain of technical debt. But to develop the MVP in time, the team took a risk of piling up technical debt of their own. They assumed that they would have enough time to fix and refactor the solution to pay off the technical debt. But this time, the creditor came back much sooner than expected.

Business executives were impressed with the lack of issues relating to the recent product launches. The reliability of their main product was better than ever. In fact, these recent changes resulted in the company gaining significant market share.The success of the two products in the market meant that the company could double their efforts. And to ensure that the recent success would continue, the company executives decided to hire a new Chief Digital Officer. This new CDO was well known in the industry for implementing signficant change in engineering. One of the major changes that the CDO was bringing to the company was adopting DevOps practices.

The following month saw a host of changes across all of engineering. Every team was now required to attend DevOps training and enablement. Anyone in engineering leadership was required to read a lengthy handbook on DevOps. The different teams were now also being tasked with documenting their current process, as well as anything that they were working on. Each team would also be incentivized to learn about Git, containerization, and different continuous practices.

The infrastructure, network, and security teams were tasked with learning about containers, container orchestration, and cloud infrastructure. The operations team became the DevOps team, and the system administration team became site reliability engineers.

These changes required the teams to migrate from current process to DevOps practices. The development team had more time granted for their migration requirements. But the DevOps and SRE teams were required to rapidly migrate current platforms over to cloud native ones.

The significant shift in direction towards DevOps and cloud native technology resulted in a major staff change. Some of the more senior engineers left the company, while a host of new hires brought in fresh perspectives. The goal was to get the company out of the Waterfall software development life cycle method and into the continuous world of DevOps. The CDO wanted an integration, deployment, and delivery process that was executed at least once a day.

Many companies that existed at the time when the Waterfall software development life cycle was the industry best practice have been confronted with this need to change. The shift from Waterfall methods to Agile, and now to DevOps has rocked the engineering industry. The ability to execute a delivery or deployment process at any time seemed too risky. The perspective was that only the largest companies with the most money and the largest engineering staff could achieve these extreme capabilties.

The DevOps and SRE teamsrealized that the best way to support the new DevOps requirements was to rebuild their automation solution. They would need to set up a best practice process for the developers to use. This included the tools, solutions, platforms, and steps needed to enable continuous delivery and deployments.

Different members of the DevOps and SRE teams would still need to maintain the old process in a weekly rotation schedule. Others on the team would work on setting up the new platform in the desired cloud provider and learning the steps to get an artifact there. After choosing a container orchestration platform, the DevOps and SRE teams needed to work on automation. Configuring and scaling the new platform required the teams to learn how to use Infrastructure as Code. A declarative method of delivery and deployment is one of the most scalable options for a DevOps practice. Most major platforms today natively support declarative configuration practices. This support allows for teams to easily adopt the platform and scale it out to meet their needs.

After the platform was set up and an artifact was deployed to it, the teams started looking at different templating options to make the administration requirements light. This led to a bake-off across different declarative deployment styles, some natively built into the platform and others leveraging an underlying templating engine. As the teams got closer to the desired end state, they had to find a new tool that would enable and assist them in the cloud-native world. The two main questions they needed to answer now were the following:

• Do they need to support the old applications as well as the new?
• Should they look for a continuous deployment tool or a continuous delivery tool?