Project-as-Code: The Catalyst DevOps Needs

If you are familiar with , , and the CI platforms (eg: Jenkins, CircleCI, Codeship), you already know the power of . It can make development easier by being repeatable, predictable, and fast. Supporting technologies both hide complexities and offer important reuse by supporting simple structured syntax in an easy to create and read file. Each technology has codified much of its domain allowing developers to author and instrument with nothing more than a text editor. Try something. Don’t like it? Make a quick change and try again. Need an Ubuntu image? Done. How about a MongoDB instance? You got it. Need to do something completely custom? Go for it.

I suggest reading "What is Everything-as-Code? Examining the Explosion of "as Code" Buzzwords" by Mitch Pronschinske and watching by Seth Vargo of Google. If automation is the orchestration of DevOps, declarative DevOps is its sheet music. It provides a readable format to perform the intent of its composer.

Importantly, it simplifies the learning curve of using many traditional tools in the chain. Sure, it takes time to set up all the distinct and disparate pieces of DevOps, but once done, it typically hums along rather nicely and mostly uninterrupted.

If DevOps Is An Engine, Your Application Is Its Fuel 

Did you notice that many DevOps tools are directly or indirectly dependent on a Git Repository? A CI/CD pipeline is rather useless until a project is flowing through it. The fullest benefits of DevOps and automation are not realized without a project, yet the industry focus is/was to automate the engine without also addressing how to better source its fuel. Imagine your driving experience if you had to source the fuel for your automobile beyond the pump at the gas station.Without the fuel, a well configured DevOps tool-chain only has the potential of automation. The fuel...the project is what causes the actual automation. Until the first meaningful commit, the full potential of a tool-chain is not completely understood. Although DevOps is all about automation, its setup and fuel source are still very manual.I define a project as a “meaningful code base” resulting in a deployable application, along with all the scaffolding required to fully make all aspects of the DevOps toolchain work. Many IDEs and CI platforms generate a simple tech stack specific “Hello World” app with stubbed out/empty files to get the ball rolling. Forget starting with a fully functioning app, or a ready to go Dockerfile, CI YAML file, or Terraform file. These platforms simply do not know enough about a project’s requirements to produce a meaningful project.In order for DevOps to grow in adoption, the hurdle of getting to the place of automation needs to be lowered or removed entirely. The benefits of DevOps and CI/CD are easy to understand but the ROI is still a factor for many organizations. Some adopt aspects of DevOps while attempting to integrate their current development methodologies. The DevOps tool-chain can be a rather large one, so which ones to choose and how to make them work cohesively is part of the learning curve.  Even though vendors like GitLab offer an all-in-one DevOps platform, it too is dependent on your project.Quickly being able to stand-up an operational DevOps toolchain would benefit every project, especially for those on the fence concerning DevOps. By automating the provisioning of best-of-breed technologies, the power of DevOps from pipeline to orchestrated application container is more easily accomplished. In this way, the fuel source for the engine must more easily be sourced.

Automating the Automation With Project-as-Code

So let's consider automating the set up of DevOps itself and its fuel source. There is Container-as-Code with Docker, Orchestration-as-Code with Kubernetes, Infrastructure-as-Code with Hashicorp'a Terraform, and Pipeline-as-Code with many CI platforms. So why not ?If a project’s DevOps requirements can be described, then those requirements can be declared and codified. Just as an operating system can be declared in a Dockerfile, project declaration system should hide the messy details of the "how" in order to create the "what". Just like other "as-code" implementations, it should be easy to use.Simply stated, would allow the following example declarative statement to be turned into a running CI pipeline with a functional application flowing through it:

"I have a business model I would like to apply to an Angular7 tech stack. I want to store data using MongoDB.  I would like the resulting project files to be committed to my GitHub repo, the source files to be built and tested using CircleCI, and the resulting application pushed as a Docker image to my container repository then finally deployed to a designated Kubernetes cluster on GCP."

The above statement could read declaratively:

This is just as straightforward as we have come to expect from Declarative DevOps.  Now feed these declarations through a system that can generate and commit the code and required config files and instantiate the DevOps pipeline to build/test/containerize/deploy the resulting app. 

is a single YAML file fed into a “system” to turn project declarations into business contextual tech stack specific source code along with CI, container, and orchestration config files. That’s a mouthful but worth considering.

By infusing the business context it means no more “Hello World”. Instead, teams start with a deployable application with (likely) tens to hundreds of thousands of lines of scaffolding that are the foundation of a typical project.

What Does It All Mean?

Fitting seamlessly into the existing "as-code" narrative, will simplify adopting and using DevOps by automating its automation. The risks of Enterprise and are lowered when the time and effort from idea to container are reduced. The project starting line is moved closer to the finish line and the overall timeline in.

The upfront work required to create a single declarative YAML file would pay massive dividends in saving weeks to months of time to the first meaningful project code commit. Every project has certain things that are more important to work on than others. We should continue to seek to automate the mundane and predictable to focus more on the critical dev. If so, imagine how much more productive and innovative you, your team, your company, and the industry as a whole would be.