Get up to speed fast on the techniques behind successful enterprise application development, QA testing and software delivery from leading practitioners.
How software testers can demonstrate value to the business
How DevOps teams are using—and abusing—DORA metrics
How to improve your observability systems
What people don’t get about value stream management
Usability: Where software testing tools fall short
Trends and best practices for provisioning, deploying, monitoring and managing enterprise IT systems. Understand challenges and best practices for ITOM, hybrid IT, ITSM and more.
4 things IT Ops teams need to know about data management
The new IT services model: Why you need to get product-centric
The 8 flavors of serverless: How to choose wisely
5 steps to becoming a data-sharing master
How AIOps is a game-changer for predictive analytics and CloudOps
All things security for software engineering, DevOps, and IT Ops teams. Stay out front on application security, information security and data security.
5 infrastructure security tasks your developers can automate
What you need to know about KVKK data-privacy requirements
Transform your security approach: 7 ways to shift to cyber resilience
3 best practices for locking down your hybrid cloud security approach
Let’s fight cybercrime like we did piracy in the 18th century
TechBeacon Guides are collections of stories on topics relevant to technology practitioners.
TechBeacon Guide: The State of SecOps 2021
TechBeacon Guide: Application Security Testing
TechBeacon Guide: Data Masking for Privacy and Security
TechBeacon Guide: Cloud Security & Data Privacy
TechBeacon Guide: Unstructured Data Security
Discover and register for the best 2021 tech conferences and webinars for app dev & testing, DevOps, enterprise IT and security.
DevOps World 2021
SKILup Days: 2021 – Observability
Webinar: Threat Hunting—Stories from the Trenches
Webinar: Cybersecurity Executive Order Challenges and Strategies
Webinar: Data Privacy and CIAM—Complete Your Identity Stack
Most developers have moved beyond understanding the business value of DevOps and on to how best to implement it. The former was easy to define, while the latter has been more difficult.
Why? The number and types of problem domains differ greatly from one problem domain to the next. The types of processes and toolsand DevOps skills—that developers and operations professionals can apply differ a great deal as well. For example, centralized release management processes can seriously impede success with DevOps.
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. 
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.
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…
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. 
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.
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.
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. 
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.
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.
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.
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.
The major tool categories include: 
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.
Keep up with QA’s evolution with the World Quality Report 2020-21.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon’s Buyer’s Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon’s Guide
Get the best of TechBeacon, from App Dev & Testing to Security, delivered weekly.

Brought to you by

I’d like to receive emails from TechBeacon and Micro Focus to stay up-to-date on products, services, education, research, news, events, and promotions.
Check your email for the latest from TechBeacon.