There is no “one” or “right” way to implement DevOps. And while most people jump to tooling, the most important elements are culture and people.
Without understanding teaming dynamics and how the work actually gets done across teams and departments, there is a huge risk of implementing tools that are the wrong fit and at a high cost. Even worse, tools may enable established teaming dysfunctions by disguising them or distracting those who might recognize them. This can happen between all parties involved – including key business partners and customers.
Bringing the teams together to define and optimize the build and release processes in the best interests of the end customer is the real work of DevOps. As new processes and ways of getting work done take shape, the teams can better select tools that support them in ways that also encourage collaboration.
Types of Tools:
Typically, Development activities fall in the broad category of Build Management. The key tools include a Source Repository that begins to bring development and infrastructure into one location and support versioning, quality management, and team member accountability. The Build Console allows code to be organized and prioritized, enables status and error reporting, and brings enhanced visibility to the project status and schedule overall. A Package Repository, packaging for both infrastructure and software, enables consistency and security during release of the total value solution.
Most Operations activities fall within Release Management. These tools include a Deployment Console that enables a self-serve method for deployment and supports security, authorization, and traceability. These three aspects of Release Management build trust and confidence between teams and people. The Resource Model provides context and visibility to what is running on the system, where and why, which sheds light on areas that were previously “hidden.” People appreciate a deeper and more thorough understanding of the entire system and impacts of adding new components. The role of Infrastructure Manager supports targeted deployment, managing what software is included when, where, and why.
Connecting the Tools:
Both Build and Release management is easier to orchestrate with independent but complementary tools. Each tool should complement the other so that the output of one is the input for the next – building on the concept of an automated tool chain.
The programmability of each component needs to be considered to allow the tool chain to run at the push of a button. This makes as many phases of the development life cycle as possible automated. And, by keeping the tools independent, as opposed to integrated, each tool can be swapped out when new versions are released. The pen source tooling provides the most flexibility, creating a tool chain with swappable parts that can be replaced and updated as new technologies and needs arise.
Considering Infrastructure:
Bringing infrastructure into the build process provides key benefits, including disciplined versioning as opposed to cutting and pasting or cloning system images. There are pros and cons to having infrastructure configuration take place at such an early stage in configuration, when more detailed customization may need to take place during deployment, and the important point is to find the right balance. The overarching goal is to deliver packages of application and environment-independent information to the Package Repository.
Considering Deployment:
Deployment can take two different approaches: directed and convergent. Directed orchestration dictates what happens when and in what specific order. Convergent orchestration allows changes to be staged so that the system eventually converges on the target. Again, the goal is to strike a balance to get the best of both approaches. Seek tools that can support both approaches.
With the ground work around teaming addressed, the resulting system of tools will link together to form a programmable and automated tool chain that manages the build and release processes and enables the continued collaboration and partnership among Development and Operations teams. The infrastructure and tooling is a small component compared to the complete cultural shift that takes place when people work together.
