DevOps best practices

DevOps best practices

https://techbeacon.com/7-steps-choosing-right-devops-tools

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...

• Processes
• 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.