DevOps is a revolutionary way to release software quickly and efficiently while maintaining a high level of security. While it has proven to be the wave of the future, many still have yet to hop aboard the DevOps train.
In an effort to demystify the unknowns associated with new business practices, Danilo Sato wrote DevOps in Practice: Reliable and Automated Software Delivery, with a mind to upack any anxieties that may besiege an operation considering the move to DevOps.
Sato found that clients were able to appreciate the theory and benefits of DevOps, but putting them into practice seemed to be difficult for most. He found that solving a problem through technology was only possible when users were coached to understand the root of the issue.
You Cannot Do What You Do Not Understand
One of the major problems companies have is that often a process is only introduced as a way to prevent a failure that occurred in the past. The implementation of the process usually solves the problem, but often it introduces new problems, creating a vicious cycle.
To alleviate this problem Danilo recommends investing in automating the process of releasing software, breaking the cycle of piecemeal solutions to large overarching issues.
Sato sees DevOps as an attempt to break the barrier between developer and operator teams. Traditionally two independently operating units in the process, DevOps partially combines these departments and unifies their goals. Developers are responsible to new features and operators keep things running smoothly.
One expression of Sato’s refrain (that a fundamental understanding of the root issue is key) is given substance here. People think that by simply creating “DevOps teams,” they’re practicing DevOps. But DevOps is not a singular entity; it’s a company-spanning change in philosophy, culture, and action. In other words, it’s not enough to put Dev and Ops in the same work place, refer to them as DevOps, and call it a day.
DevOps, Between Theory & Implementation
Some components of DevOps are quite easy to implement. Keeping everything in source control, for example, Sato says, is a good way to begin. The process allows both application and infrastructure changes to be tracked and traced while being quality tested.
Automating the build and deployment process is also at the top of Sato’s list. He states that it reduces human errors and speeds up the software production process.Sato encourages his teams to develop on production-like environments. This process reduces the lack of compatibility often found between development and production (e.g. a developer using a Windows-based machine and deploying to a Linux server or having different visions of libraries and dependencies), allowing problems to be found more quickly.
Automation is vital in many of the processes discussed in the book. Automated processes enable more frequent deployments and shorter cycle times. This, in turn, gives companies metrics which can be used to further improve and build on DevOps. It also allows for businesses to gain a competitive advantages against those not using automation and their customers are often more satisfied.
DevOps: Putting Source Control and Continuous Delivery to Work
In many ways, DevOps is simply the structure that allows for the achievement of continuous software delivery. To this extent, in order to succeed, an operation needs a healthy appreciation for both the philosophy and practical side of things. For most operations, source control is an excellent case in point for DevOps practice, while the goal of truly continuous delivery should underly the philosophy.
Accordingly, DevOps, source control and continuous delivery are the three pillars of a healthy, modern software operation.
DevOps enables continuous improvement. It is constantly hypothesizing, experimenting and collecting the data of the experiments to either validate or reject a hypothesis. This increasing the deployment frequency and it allows for the process to improve every time it runs.
Source control ensures that this experimental, iterative process doesn’t undo any of the good work already validated and built upon further. While continuous delivery, if all goes right, is the outcome.
Following (and indeed understanding) this process is key to empowering businesses to constantly re-evaluate and improve on their existing methods, and at the same time, ensuring that this recursive self-examination does not jeapordize system integrity or cost management.
For those looking to get the ball rolling, Sato recommends teams assess their current process and ask how long it takes and how it can be made faster without compromising quality or security. The answer to these questions are usually found in the canon of DevOps. The trick is realizing that.
