Effective DevOps hinges on automating a continuous delivery pipeline
Limited Time Offer!
For Less Than the Cost of a Starbucks Coffee, Access All DevOpsSchool Videos on YouTube Unlimitedly.
Master DevOps, SRE, DevSecOps Skills!
Source – theserverside.com
An organization has to be fully committed to an automated testing strategy if it wants to do continuous delivery right. But DevOps adopters need to be forewarned, as it’s not a process to be undertaken by the light of heart.
Continuous delivery means exactly what the name implies. It means putting together a continuous delivery pipeline that is fully automated and will take recently compiled code and move that code straight into production — just so long as every test the continuous delivery pipeline puts it through is passed.
Automating the continuous delivery pipeline
With a fully automated continuous delivery pipeline, there’s no active human oversight of the process. There’s no senior member of the IT staff moving files from a preproduction server to production. There are no emails to send, no buttons to push and there are no forms to sign off on. The automated continuous delivery pipeline takes care of all of that, and every task — from compiling code to bouncing the application server — is automated. The automated continuous delivery pipeline completely removes the human element from the equation.
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 advanced and requires a certain degree of human resource coordination. Emails are typically sent, sign-offs are required by the scrum master and the quality assurance team and, when code does get moved into production, all stakeholders on the development and operation teams all sleep with the ringer on their phone set to high. The software team rarely sleeps soundly when there’s an overnight promotion of code into 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?
“It’s all about testing: unit tests, acceptance tests, performance testing and all these types of things,” said Eberhard Wolff, a software consultant with innoQ. The continuous delivery pipeline is an automated process responsible for moving code through the stages of software development that span from inception to production. In order to do that with confidence, code must be tested in every conceivable way, and test coverage must blanket all aspects of the application.
Continuous delivery pipeline resistance
Eliminating the human factor can be a challenge for a variety of reasons. There is an understandable feeling that control over the production systems is lost, making stakeholders reticent to fully embrace continuous delivery. Another less technical aspect of the reluctance to embrace continuous delivery is the fact that some participants in the deployment process equate their manual task with a sense of status. Being the person who gets to say yes or no as to whether they believe the application is meeting their standards of quality can be intoxicating, and it is a politically powerful position to be in to be able to send out an email to every member of the team chastising them for a subpar software release. 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 for whether the development team or the operations team is fulfilling its automated needs, and it doesn’t play politics or power games, which is another, often overlooked, benefit to using it.
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, are things that have traditionally fallen under the purview of operations personnel. But the continuous integration pipeline has no need for roles such as developer or operations. All it wants is the resources it needs to be available when they are needed, and it is essentially out of this nondiscriminatory need that DevOps was born. After all, DevOps in its truest form is simply the drive toward the automation of software development tasks that allows code to go from inception to deployment with the least amount of friction possible. An organization that succeeds at implementing a continuous delivery pipeline is, by definition, working with a DevOps-based approach.
But to do continuous delivery right, the key is to eliminate all manual processes and implement a continuous delivery pipeline that is fully automated and capable of pushing code out to production servers without any human intervention being involved in the process. 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.