Every diverse task, collaboration and technology on a DevOps team shares one simple goal: get working code to production. Yet, organizations struggle to map the path from start to finish.
Gary Gruver, author and president of Gruver Consulting, advises that DevOps teams draw a deployment pipeline diagram, starting with the environments that they run. For example, an organization probably has multiple development environments, which feed into quality assurance stages, then to user acceptance testing, performance testing, staging and then production.
How does code flow through your deployment pipeline stages? How long does it take? Answer these questions, then figure out the issues specific to your DevOps environment. Once they map these flows, teams can apply metrics to their processes. And once the pipeline's functional problems are corrected, Gruver said, add automation so it flows faster.
Gotcha deployment scenarios
Every organization's and every team's deployment pipeline diagram is different, so there won't be the same issues in every shop.
"If it takes six weeks to go from dev to the stage environments and you're finding 90% of your defects in stage, the feedback to developers is so slow [that] they don't even remember what they were doing," Gruver said, by way of example. Once the team sees the problem, they can address it -- in this case, by moving feedback on defects closer to the source in development.
Another example is code that passes tests in one part of the pipeline but fails in production. This problem can be traced back to the different hosting setups in each of the deployment pipeline stages. It isn't solved with new processes, but instead with technology, such as containers, to standardize deployment.
In yet another setup gotcha, two teams use the same performance test environment simultaneously and mess up the others' resource utilization results despite using the right tool, process and methodology.
The goal is to be boring going into production, Gruver said. "You want to be able to deploy hundreds of times in [quality assurance] or other environments the same way you will do it in prod."
Love the tool you're with
It helps in the pursuit of boring deployments to use the same processes and tools throughout, from build and test to production.
"If ops are using completely different tools and environments, you should expect to find new things every time you deploy to production," he said.
While standardized tools matter, the specific capabilities of the products that you choose are less important than your opinion of and familiarity with them. There are a lot of great tools for a lot of purposes, Gruver notes, but they all have pros and cons. Go with the management, monitoring and support tools that you've picked already and like, because you'll overlook the "warts" and focus on the value, he said.
"If you force that tool upon [workers], and they don't get to pick ... all they'll see is the warts and frustration."
Gruver presented "Starting and Scaling DevOps in the Enterprise" at DevOps Enterprise Summit 2017. The 2018 conference will take place October 22-24 in Las Vegas.
- Learn how to get started with continuous integration and continuous delivery
- Learn how Git, GitHub and distributed version control is impacting source code management
- Get your builds under control with Maven, Gradle and artifact repositories
- Start developing RESTful microservices with Jakarta EE or Spring Boot
- Test your skills with these Git and CI/CD quizzes
- See how you would do on a Jenkins or DevOps job interview