What is DevOps? If you ask 10 Different People you will Likely get 10 Different Answers
I have given up on finding a single, common definition and shifted my focus to the problems that DevOps solves. From my perspective, they are improved software quality, developer velocity, deployment repeatability, deployment time, traceability, time to market, audit compliance, and risk reduction. If you are like most people you are asking yourself: That sounds great, but how do we get there?
When trying to explain what DevOps is and how it should work, I like to reference the movie “The Karate Kid” (1984). There is a scene in which Daniel, the lead character, gets upset that he hasn’t yet learned any Karate, because he has been doing nothing but chores, in very specific motions, for his teacher Mr. Miyagi. However, when Mr. Miyagi asks Daniel to repeat the chore motions (such as wax-on, wax-off) and throws corresponding punches at Daniel, the light bulb goes off; as he is deflecting the attacks, he realizes he has actually been learning Karate moves.
How does this relate to the mythical state of utopia known as DevOps? It largely boils down to investing in automation around the common, repetitive chores your organization is already doing. The end goal is an automated software delivery pipeline through which all changes must run before reaching production.
DevOps boils down to investing in automation around the common, repetitive chores your organization is already doing. The end goal is an automated software delivery pipeline through which all changes must run before reaching production
I like to break the pipeline down into stages.
Build Stage - This is where you compile your code and invoke your unit tests. Ensure you have unit tests (at least some) and wire it up to run in a Continuous Integration/Delivery (CICD) tool on every code commit. If the tests don’t pass the defined threshold, the build should fail and be addressed immediately by the developer who did the commit. For those of you who don’t have unit tests, start with one and get that configured in your CICD tool. Then you can set goals to increase the percent coverage over time.
Packaging/Versioning Stage – All build and deploy artifacts should be packaged and tagged with version metadata. Additionally, these need to be placed into a repository for easy retrieval at deploy time. This helps ensure you know exactly what is deployed where and gives you the ability to rollback to a previous version should things go sideways.
System Testing Stage – Types of testing at this stage are known as functional, regression, and integration to name a few. I assume every organization does at least some level of this testing before going to production. The key is to wrap that in automation and configure your CI tool to run it automatically on all code before it goes to production.
Security Testing Stage – One of the most overlooked aspects of the Software Development Life Cycle (SDLC) is security testing. It is challenging enough to write working software and get it to pass a barrage of system tests, but you can’t stop there. This is where you perform tests such as penetration, cross-site scripting, and SQL injection to ensure the bad guys can’t get in. Be careful not to assume that all threats come from outside your organization because they frequently come from within.
Performance Testing Stage – In this stage, you will identify what your bottlenecks are and where you need to focus your tuning efforts. Additionally, you should have automation that can scale the system up when hitting certain thresholds. It makes sense to put this towards the end of your pipeline because you don’t want to waste time performance-testing a buggy system that may behave completely differently once the bugs are resolved.
Putting it Together - To tie all these stages together we have what we call pipelines, and we codify them in our CICD tool. When software changes happen, they must run through all stages successfully before being allowed to go to production. No manual intervention is allowed except for manual testing that has yet to be automated. Each stage has a home in one of our CICD jobs:
• Build (code inspection/compilation)
• Release Candidate (packaging/versioning)
• Development Environment (smoke tests/deployment automation tests)
• Test Environment (system tests)
• Stress Environment (security/performance tests)
• Production Environment
It’s important to note that all automation should be treated the same as any other codebase. In other words, it lives in a source code repository and finds its way into your pipeline without manual intervention. You can now pinpoint any change that was applied to a given environment and a specific time. This makes solving challenges such as audits much easier as it’s now part of your ecosystem at its very core.
If you made it this far, congratulations! Sit back and enjoy a bag of popcorn while you watch your pipeline dashboard work. However, it doesn’t stop there. A far less tangible aspect of DevOps is a culture change. It’s never easy and takes dedication to see it through.
With the discipline of a pipeline, you gain trust in your software as it makes its way to production. Trust is a large part of what helps or hinders the organization’s ability to move faster. The goal is to make that production deployment easy, reliable, and repeatable. It frees people up to focus on more important things such as getting that new feature developed.
There are many other opportunities to optimize how your organization does its work. I encourage you to question and rethink everything. Here are some ideas:
• Does that CAB meeting become easier or maybe go away altogether?
• Do we need tickets created for deploying to each environment? If so, can we automate them?
• Can we reduce the number of people needed for deployments? Can we do deployments during the day?
Here at ACT, we have been embracing DevOps for approximately 2.5 years. Prior to that, we were a traditional IT shop. We have covered a lot of ground, but still, have much more to do.