In my last blog, I discussed the sustainability of programming languages and the care that must be taken in selecting one for an enterprise IT project. In this blog, I wish to apply my thoughts toward Continuous Delivery automation mechanics.
In the book, Continuous Delivery, one of the foundational tenants purposed in the book is to use the same automation mechanics across all environments DEV through PROD. Additionally, I have found that companies quickly extend the automation use case after they get a taste of automated success. The way you extend automation tools, such as Application Release Automation (ARA) tools and others is through an extension or plugin architecture that is typically bound to a programming language.
Since the automation mechanics of Continuous Delivery ought to permeate all app environments, they will transcend many IT SMEs and cross the chasm of development and operations. This means the language employed by the extension architecture of your automation mechanics should be simple enough for any IT professional to understand and learn and must have proven staying power. Staying power is critical in automation systems because once an organization begins to rely on an automation system, it becomes the backbone of many core processes ? sort of keeping the lights on, if you will.
Organizations cannot afford to adopt an automation solution that employs a language that will be out of vogue within a few years. In my previous blog, I provided links to resources indexing and discussing programming language popularity trends. Automation development is not the same as building an app from scratch. To maximize the ROI of automation tools you want to minimize the amount of time it takes to setup and maintain an automation pipeline. The focus needs to be more on the processes rather than the engineering.
Over the course of my career, I have come to realize the power of one "programming" language that has stood the test of time, is easy to learn, and transcends IT SMEs. Being a developer in my past, it pains me to say this, but a Command Line Interface (CLI) seems to be the best language or interface for extending automation systems. It's not a sexy pick, to be sure, but CLIs exist for nearly every technology stack including modern cloud systems and most of the as-a-service stacks.
CLIs are more self-documenting than a programming language, which pays dividends when onboarding new employees and providing business continuity through employee turnover or DR use cases. CLIs have been around for about as long as IT departments have existed, so they represent the most sustainable option for codifying business processes or pre-approved change processes such as deployment pipelines.
When you are considering automation mechanics for your Continuous Delivery practice, I highly recommend considering how your solution can be extended.
- Do you have to develop a plugin?
- If so, what language is your personnel going to need to know?
- Can you just simply "build" integrations using a CLI?
You want a Continuous Delivery pipeline that will stand the test of time and will work in all environments and can be supported by all app-ecosystem SMEs.
