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 eliminate the enigma that comes with any new business practice, Danilo Sato published a book, DevOps in Practice: Reliable and Automated Software Delivery, which discusses the basics of DevOps and Continuous Delivery practices.
Sato found that clients were easily able to understand the 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.
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 in 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 bridges the departments and unifies their goals. Developers are responsible for new features and operators keep things running smoothly. One way in which people misunderstand DevOps is they create DevOps teams. But DevOps is not a singular entity; it’s a company-spanning change in philosophy, culture, and action.
Some components of DevOps are quite easy to implement. Keeping everything in source control, for example, is one element that 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 advantage against those not using automation, and their customers are often more satisfied.
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. Businesses are able to always re-evaluate their methods, but the cost of doing so is basically nothing.
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 DevOps. The trick is realizing that.