Effective DevOps hinges on automating a continuous delivery pipeline
Many organizations struggle with bringing development and operations together, only to realize that effective DevOps means successfully automating a continuous delivery pipeline.
An organization has to be fully committed to an automated testing strategy if it wants to do continuous delivery correctly. But DevOps adopters need to be forewarned because it's not a process to be undertaken by the faint of heart.
A fully automated continuous delivery pipeline takes recently compiled code and moves that code straight into production, so long as it passes every test along the way.There's no active human oversight in the process and no senior member of the IT staff moving files from a preproduction server to production. There are no email messages to send, no buttons to push and no forms to sign. The automated continuous delivery pipeline takes care of all of that, and every task -- from compiling code to bouncing the application server -- is automated.
For many organizations, the chasm between full automation and the need for human interaction is far too wide for them to take the required leap of faith to engage in true continuous delivery. In traditional IT shops, moving code into production is a strict process that is scheduled in advance and requires a certain degree of human resource coordination. Email notifications are typically sent; sign-offs are required by the scrum master and the quality assurance team; and when the code is moved into production, all stakeholders on the development and operation teams sleep with the ringer on their phone set to full volume. The software team rarely sleeps soundly when there's an overnight promotion of code going through production.
So how does an organization move from a traditional mindset of manual checks and balances to one that unequivocally trusts a fully automated system?
Just having Jenkins and ... a deployment pipeline is not the key challenge. The key challenge is going into production without sign-off.
Eberhard Wolffsoftware consultant, innoQ
"It's all about testing -- unit tests, acceptance tests, performance testing and all these types of things," said Eberhard Wolff, a software consultant at Germany-based innoQ. The continuous delivery pipeline is an automated process that moves code through the stages of software development, from inception to production. To handle that process with confidence, code must be tested in every conceivable way, and test coverage must blanket all aspects of the application.
But if testing is the magic bullet, automation is the gunpowder, and the integration server is the trigger that fires off the continuous delivery pipeline. But to make sure everything works smoothly -- without interruptions in the continuous delivery system -- the human element is completely removed. "Just having Jenkins [automation server] and just having a deployment pipeline is not the key challenge," Wolff advised. "The key challenge is going into production without sign-off."
Continuous delivery pipeline resistance
Eliminating the human factor can be a challenge for a variety of reasons. There's understandable fear that control over the production systems will be lost, making stakeholders reticent to fully embrace continuous delivery.
Another less technical aspect in the reluctance to embrace continuous delivery is that some participants in the deployment process equate their manual task with a sense of status. Having the power to decide whether an application is meeting quality standards can be intoxicating. A person with the authority to send out an email to the entire team chastising them for a subpar software release comes with having a politically powerful position. There will always be people who have ulterior motives for not wanting a continuous delivery pipeline to be implemented, and organizations looking to embrace DevOps types of practices must be cognizant of them.
When fully automated, the continuous delivery pipeline itself is highly egalitarian in nature. Its purpose is to execute a set of automated steps, which upon success will move a new release of code into production. The pipeline has very little concern whether the development team or the operations team is fulfilling its automated needs, and it doesn't play politics or power games -- an often-overlooked benefit of using that method.
DevOps and continuous delivery
Some of the steps the continuous integration pipeline performs -- such as compiling code -- fall strictly within the domain of the software developer. Other steps -- such as load testing the promotion of code into production -- have traditionally fallen into the purview of operations personnel. But the continuous integration pipeline has no need for the roles of "developer" or "operations"; all that's required is for resources to be available when needed.
It was essentially out of this nondiscriminatory need that DevOps was born. After all, DevOps in its truest form is simply the drive toward automation of software development tasks that allow code to go from inception to deployment with the least amount of friction. An organization that succeeds at implementing a continuous delivery pipeline is, by definition, working with a DevOps-based approach.
But to do continuous delivery properly, the key is to eliminate all manual processes and implement a pipeline that's fully automated and capable of pushing code out to production servers without human intervention. It's not necessarily an easy goal to achieve, but there are innumerable benefits to embracing this DevOps-based approach that continuously delivers code into production.
