Why Your Project's 1st Commit Should Have a Working App & CI/CD Pipeline

Automating The Automation Behind DevOps

I am a big advocate for software reuse, and an even bigger advocate if that reuse comes in the form of software automation. My team and I rely on reusable software processes that accept simple inputs to produce predictable results. We have tight deadlines with requirements that often seem impossible. Automation makes us more efficient and our work more predictable. 

Once upon a time, we used glue and bubble gum to cobble together means by which to build, then test, and then eventually deploy application versions. It worked until it didn’t work and industry opportunities arose for mechanization.

Enter Continuous Integration (CI), Continuous Deployment (CD) and DevOps, in part.

You likely know this and have already taken advantage of CI/CD platforms like Jenkins, CircleCI and others. The simplicity of the “as-code” model allows us to turn easy-to-create declarations into the otherwise complex provisioning of servers, databases, caches, and file-systems, along with the execution of code to leverage what was provisioned. 

Life as a developer has been made better using these “as-code” tools in the tool chain. Spinning up a Kubernetes cluster on Google to (re-)deploy an image built, tested, and pushed to DockerHub from a CloudBees/CodeShip pipeline is something I rely upon each time I commit to my Git host.

In this article I am going to talk about “project as-code” to extend automation to the first code commit with a working app running through a functional CI/CD pipeline and deployed to a production like environment.

Barriers Keeping Many Enterprise IT Departments From Coming Along For the DevOps Ride

Unfortunately, basic usage of all these great tools comes with the added complexity and cognitive load cost. Understanding Docker image creation, HashiCorp Terraform syntax for infrastructure-as-code, Kubernetes cluster deployment, and more are just a few of the competencies developers and operators need to have. 

Learning a new set of tools every few years comes with the territory, but there’s no reason to ignore new potential avenues for automation. I’ve wondered if there is a better way to abstract and automate the setup of these common pieces in the modern software production pipeline. 

Another common issue I’ve noticed—these pipeline components often get set up sequentially, with the first “meaningful” code commit being the blocker to setting up all the other pieces of the CI/CD pipeline. Without this commit, these tools sit relatively idle while waiting to provide value.

For those of us who work on new projects regularly, getting things started has always had its issues, especially for consulting scenarios where requirements and team dynamics differ between clients. We are disciplined enough to first reach in our toolbox to reuse as much as possible. Still, DevOps has yet to be adopted wholesale in a standard way by many enterprises. 

For these situations, I find the benefits of DevOps are easy to explain and understand. Developers like reuse and fewer barriers, the business likes savings, and an enterprise likes productivity and innovation. However, to inject those benefits is still a very manual, time consuming process, making the overall sell of DevOps harder.

The purpose of DevOps automation is to simplify tedious error prone manual processes. I see another opportunity for automation: entire DevOps projects using the same “as-code” model we have become accustomed to. 

Generating Your First Meaningful Commit “as-code”

Why not use a straightforward declarative model-driven means of not only generating tech-stack specific application source code, but all the config files that lead to DevOps being automated. With this, the toolchain learning curve is minimized and idle tools now are immediately called to action.

The result is a self-sufficient operational DevOps environment working through an application code base that comprises a fully deployable executable first code commit.

Developers then get their reusable assets and environment(s), the business sees cost and time savings, and the enterprise gets the productivity and innovation necessary to stay competitive.

In an article written by Pete Hodge titled “Hello production”, he goes into great detail about the value of quickly standing up a flowing CI/CD pipeline leading to a functioning app deployed to production. 

He contends deploying even a useless application into production, as soon as you can, is the right way to start a new project because it pulls unknown risk forward, opens up parallel streams of work, and establishes good habits.

Project-as-Code standardizes this thinking with model-driven automation.

The next generation of DevOps is unfolding with automation remaining a key component to expand scale, velocity, and productivity. As automation has worked its way up the tool-chain, “automating the automation behind DevOps” will shift the paradigm to improve how projects are created, how DevOps is implemented, and the quality and features of the first commit into a Git repository.

What now takes weeks to months could instead take hours to days, falling in line with our expectations now met by other successfully mechanized aspects of DevOps. 

Hopefully this article will serve as a starting point for your next DevOps project and how Project-as-Code automation can be a part of getting you started easier and faster.