7 steps to choosing the right DevOps tools
Why? The number and types of problem domains differ greatly from one problem domain to the next. The types of processes and tools that developers and operations professionals can apply differ a great deal as well.
Best practices are starting to emerge, however, and most enterprise DevOps shops should be following them. These best practices go beyond common sense; they get at the essence of what DevOps means for your enterprise and how to get DevOps right the first time. For most organizations, this is new stuff.
DevOps best practices
If you’re considering DevOps, you have many moving parts to consider. Core to this structure are automated provisioning, automated testing, and automated build and deployment. At the same time, you need to maintain continuous feedback, with information continuously moving back and forth, as well as making sure that you log pretty much everything.
Figure 1: DevOps has many moving parts, and you need to have best practices and technology in place for each step.
As to the best practices for choosing DevOps tools you can use to approach your DevOps implementation, these can be boiled down to seven steps.
Step 1: Understand the collaboration and shared tools strategy for the Dev, QA, and infrastructure automation teams
DevOps teams need to come up with a common tools strategy that lets them collaborate across development, testing, and deployment (see Figure 1). This does not mean that you should spend days arguing about tooling; it means you work on a common strategy that includes DevOps...
- Communications and collaboration planning
- Continuous development tools
- Continuous integration tools
- Continuous testing tools
- Continuous deployment tools
- Continuous operations and CloudOps tools
Coming up with a common tools strategy does not drive tool selection — at least not at this point. It means picking a common share strategy that all can agree upon and that is reflective of your business objectives for DevOps.
The tool selection process often drives miscommunication within teams. A common DevOps tools strategy must adhere to a common set of objectives while providing seamless collaboration and integration between tools. The objective is to automate everything: Developers should be able to send new and changed software to deployment and operations without humans getting in the way of the processes.
Step 2: Use tools to capture every request
No ad hoc work or changes should occur outside of the DevOps process, and DevOps tooling should capture every request for new or changed software. This is different from logging the progress of software as it moves through the processes. DevOps provides the ability to automate the acceptance of change requests that come in either from the business or from other parts of the DevOps teams.
Examples include changing software to accommodate a new tax model for the business, or changing the software to accommodate a request to improve performance of the database access module.
Step 3: Use agile Kanban project management for automation and DevOps requests that can be dealt with in the tooling
Kanban is a framework used to implement agile development that matches the amount of work in progress to the team's capacity. It gives teams more flexible planning options, faster output, clear focus, and transparency throughout the development cycle.
Kanban tools provide the ability to see what you do today, or all the items in context with each other. Also, it limits the amount of work in progress, which helps balance flow-based approaches so that you don’t attempt to do too much at once. Finally, Kanban tools can enhance flow. In Kanban, when one work item is complete, the next highest item from the backlog gets pushed to development.
Step 4: Use tools to log metrics on both manual and automated processes
Select tools that can help you understand the productivity of your DevOps processes, both automated and manual, and to determine if they are working in your favor. You need to do two things with these tools. First, define which metrics are relevant to the DevOps processes, such as speed to deployment versus testing errors found. Second, define automated processes to correct issues without human involvement. An example would be dealing with software scaling problems automatically on cloud-based platforms.
Step 5: Implement test automation and test data provisioning tooling
Test automation is more than just automated testing; it’s the ability to take code and data and run standard testing routines to ensure the quality of the code, the data, and the overall solution. With DevOps, testing must be continuous. The ability to toss code and data into the process means you need to place the code into a sandbox, assign test data to the application, and run hundreds — or thousands — of tests that, when completed, will automatically promote the code down the DevOps process, or return it back to the developers for rework.
Step 6: Perform acceptance tests for each deployment tooling
Part of the testing process should define the acceptance tests that will be a part of each deployment, including levels of acceptance for the infrastructure, applications, data, and even the test suite that you’ll use. For the tool set selected, those charged with DevOps testing processes should to spend time defining the acceptance tests, and ensuring that the tests meet with the acceptance criteria selected.
These tests may be changed at any time by development or operations. And as applications evolve over time, you'll need to bake new requirements into the software, which in turn should be tested against these new requirements. For example, you might need to test changes to compliance issues associated with protecting certain types of data, or performance issues to ensure that the enterprise meets service-level agreements.
Step 7: Ensure continuous feedback between the teams to spot gaps, issues, and inefficiencies
Finally, you'll need feedback loops to automate communication between tests that spot issues, and tests that process needs to be supported by your chosen tool. The right tool must identify the issue using either manual or automated mechanisms, and tag the issue with the artifact so the developers or operators understand what occurred, why it occurred, and where it occurred.
The tool should also help to define a chain of communications with all automated and human players in the loop. This includes an approach to correct the problem in collaboration with everyone on the team, a consensus as to what type of resolution you should apply, and a list of any additional code or technology required. Then comes the push to production, where the tool should help you define tracking to report whether the resolution made it through automated testing, automated deployment, and automated operations.
Picking the tools
Here are the tools that are part of the DevOps mix and that relate to the best practices/steps listed above:
Figure 2: Tools for DevOps, by category
The number of tools from which you can choose for DevOps is both large and confusing, so break it down by focusing on categories and the functions you need.
Major DevOps tool categories
The major tool categories include:
- Version control: Tools that track software versions as they are released, whether manually or automatically. This means numbering versions, as well as tracking the configuration and any environmental dependencies that are present, such as the type, brand, and version of the database; the operating system details; and even the type of physical or virtual server that’s needed. This category is related to change management tools.
- Build and deploy: Tools that automate the building and deployment of software throughout the DevOps process, including continuous development and continuous integration.
- Functional and non-functional testing: Tools that provide automated testing, including best practices listed above. Testing tools should provide integrated unit, performance, and security testing services. The objective should be end-to-end automation.
- Provisioning and change management: Tools to provision the platforms needed for deployment of the software, as well as monitor and log any changes occurring to the configuration, the data, or the software. These tools ensure that you can get the system back to a stable state, no matter what occurs.
Unwinding the complexity
Selecting the right tools for DevOps is a complex undertaking, and these tools are new and largely unfamiliar to most enterprise development shops. However, if you follow the steps outlined here, and adhere to the objectives of DevOps as a concept, you should be fine.
Consider the changes your enterprise will continuously undergo over the next several years and be prepared to constantly evaluate the tooling in terms of what works and what needs to improve. Try creating a lab where you can explore the benefits of different tools, so you’re constantly experimenting with how to do DevOps better. The need to constantly monitor DevOps operations will continue over many years, so it's critical build into your plans and tool choices today.
Are there other best practices you would add? Do you agree with these steps? Share your experience in the comments below.