Good DevOps, Part 1: Take Your Time
Continuously delivering value to end users, the business, and the rest of the teams inside an organization has always been crucial. But why are we hearing about it so much now? What is this whole DevOps thing, and why put “continuous” in front of so many words?
DevOps, and its set of continuous processes called continuous integration, continuous delivery and continuous deployment, are hot. Why? Because it delivers continuous value to your customer.
This blog post is the first in a three-part series diving into what it means to continuously deliver value to your customers with DevOps.
Start Slow to Move Fast
But to get there, organizations must start slow to move fast. The word “continuous” doesn’t mean continuously delivering value slowly—it means to give your customers value ASAP. Right now. Deliver new updates as soon as you possibly can.
To do this, many organizations implement scripting, automation, testing tools, and cloud infrastructure. And while all of these tools work, they only work if the team is ready to work with them.
One of the biggest issues with tooling is the way companies market their products. Many vendors make it seem so easy to implement “the DevOps”: “Just buy a tool and your problem is solved!” This sentiment is far from the truth.
Organizations need to learn what DevOps is from a cultural and process perspective first, instead of thinking a tool will solve all their problems. Before purchasing a CI/CD tool, for instance, organizations should first learn “The Three Ways,” which describe the foundations of DevOps.
Once an organization understands how DevOps can transform their software deployment workflows, it’s time to ask some hard questions and follow some best practices, including:
- Notice patterns. Why does that application build keep failing?
- Start paying back technical debt. What workarounds and hacks have you put in place just to get the job done? Organizations must first fix the underlying issues before even thinking about taking an application and sprinkling a little DevOps on it.
- Use one new tool at a time. How many shiny services and tools has your organization rolled out recently? You may not be properly taking the time to learn how each work. Start slow and don’t get overwhelmed.
- When’s the last time you updated documentation? Just because one or two people on your team know how things are done doesn’t mean everyone else does. Document everything. Even include it with your builds, and make it a requirement for every new feature.
- Communication is key between both the engineers and management. Engineers have a habit of doing their own thing without regard to the business. DevOps is all about business value. It’s about bringing the business and the technology together. Bring in managers to your daily standup meeting, and build teams with representatives from all areas of the business to ensure everyone weighs in on changes.
If organizations start slow by learning not only tools but DevOps culture and how DevOps can deliver more business value, implementing one of the most important aspects of DevOps—the continuous pipeline—you increase your chances of success.
One of the most important components of DevOps tooling is the pipeline. Referred to as the build/release or just continuous integration/continuous delivery/deployment (CI/CD) pipeline, this construct is automation on steroids and is the crux to quickly delivering value to customers.
A pipeline typically has 2-3 different stages or phases, called CI and CD, thus the term CI/CD pipeline.
The first stage of a pipeline is CI. This is the practice of storing code in a repository that applies version control—Git, for instance—and automatically triggering a build. This build performs whatever necessary steps on the code to create an artifact or a single unit that can be deployed to an environment.
CI is also a great place to integrate testing. When a developer writes code, that code needs to be tested before allowing a customer to run it. Integrating automated testing in the CI phases allows organizations to build a gate. That gate will halt the stage unless all of the tests pass.
The second (and optional third phase) is continuous delivery/continuous deployment (CD). The terms are sometimes used interchangeably. Deciding when to use one or the other depends on the extent to which an organizations plans on automating the entire software development and deployment process.
The CD stage typically takes the artifact that the CI process builds and automatically deploys that artifact to a testing environment.
CD then takes automation one step further by sending the artifact to infrastructure and installing it. Infrastructure could be a virtual machine, a container, some serverless model, or even bare metal servers.
Once the software is deployed to a testing environment, other teams like QA could perform manual testing or other final validation checks.
When everyone is happy with the final result, organizations can go the final mile and implement a continuous deployment phase. In this optional phase, the pipeline is 100% automated. Software is built, tested and deployed in a test environment. The pipeline then runs various integration and acceptance tests in the test environment. If all tests pass, the software is immediately deployed to production, where it then goes through another round of automated tests. If all is well, the deployment is successful.
For mature DevOps organizations, you can only imagine how fast value is delivered to their customers and how quickly they can fix any bugs that arise. Some companies are building code with CI and deploying it with CD 50-plus times per day.
A complete CI/CD pipeline throws all manual steps out the window.
DevOps Is a Marathon, not a Sprint
If your organization develops software or wants a quicker way to deploy infrastructure and isn’t using DevOps and CI/CD pipelines, you’re missing out. These processes can transform organizations from slow-moving, unwieldy behemoths to nimble, agile gazelles. But first, teams must understand the underpinning of DevOps rather than simply throwing tools at a problem.
CI/CD, through its many “continuous” layers, allow organizations stepping stones to slowly but surely implement more automation into their software development lifecycle (SDLC). Start out slow. Document specific areas to improve upon, bring business stakeholders together and understand not just technical problems but business problems. If you do that, finding and buying the right tool to build your CI/CD pipeline will be the easy part.