DevOps streamlines development, testing and operations processes, but it relies on strong feedback loops to complete useful work. Without feedback from start to finish, DevOps is no more useful for a business than waterfall.
DevOps can support continuous development and delivery models, which break up work into tiny pieces small enough to deal with efficiently and in real time to prevent problems from becoming bottlenecks. It's a step up from waterfall, where processes add significant time to project completion in the name of stability.
But DevOps itself is already wrong for the modern world: Streamlined processes between development and operations are only useful if the outcome supports the business. DevOps does not solve the problem of IT effectiveness, wherein IT must not just work quickly, but also must stay attuned to business requirements and project goals. DevOps is better christened BizDevOps, as everything that happens must be driven by the business.
Development teams can act too selectively: Instead of focusing on an issue identified by operations as critical, they spend time on technically interesting and intellectually challenging tasks that are less pressing. The standard help desk feedback loop system, wherein operations and users raise issues in production, is wrong for DevOps. A DevOps feedback loop enforces priorities and project goals so that the freedom and fast pace in development doesn't lead it astray.
What's the goal?
The first stage in a complete DevOps feedback loop is for the business to define a specific problem: Project leaders work with the IT team to develop a basic approach to a resolution. Developers then create an initial code layout -- just a strawman, not complete code -- and consult the project team for comments and concerns before the volume of code created makes editing unwieldy and complicated. This initial feedback loop between developers and the business can -- and should -- occur multiple times.
Once developers and project leaders agree on the application's direction, operations should join the conversation to ensure that proposed code is supportable in the operations environment.
Does the project work in real life?
IT operations extends the DevOps feedback loop begun between the app owner and developers. If code is not ready for the production environment, the teams must choose a course of action: Does operations need to acquire and provision more equipment -- or cloud computing power -- in production? Or do dev and ops take the issue back to the project team for a decision on resource management and deployment -- particularly for financial assets -- prior to moving the code along?
Once teams decide on code deployment and required IT resources, the DevOps feedback loop can resume rotation: Developers create and package the overall code, which the QA team must then test, providing the developers feedback in real time. The testing process should consider a code release's effect on the business.
For example, test users report a simple issue 100 times. On the surface, this looks like a major issue -- 100 reports, after all -- but, upon inspection, it's only a minor issue that each tester can work around and still complete tasks. On the contrary, a single report of an issue that prevents task completion likely portends a much higher business cost: DevOps feedback loops must enable these priority distinctions.
After testing, the IT team must provision the code easily and efficiently to the operational environment. This should be simple with the feedback loop between development and operations, because the required resources will be ready for the workload.
How is the deployment doing?
The project has reached the heartland of DevOps: The workload is live and functional, but the job is not done. There is still potential for issues, such as memory leaks or undiscovered coding issues, and ops must report each problem to development as soon as possible, with a focus on its business weight. This classic DevOps feedback loop, which involves performance monitoring and incident management, should be familiar to most IT organizations.
Users act as another stakeholder enforcing the project's business value beyond just deployment success. They encounter and report issues, but also identify practical improvements, or potential new functionality that will be more beneficial to their work process, and therefore the business.
These DevOps feedback loops must be easy for all parties to work into their processes. They should drive developers to work on a continuous development model to respond to the business' needs and operations to manage continuous delivery of incremental functionality.
Tools aid BizDevOps implementation
Each constituent group in the various DevOps feedback loops uses tools to do its job. And various tools can create a seamless platform that connects the sets of underlying tools. Dashboards, such as those provided by CA Automation, Electric Cloud and HashiCorp, are required for end-to-end process visibility to provide orchestration of reciprocal feedback.
Monitoring procedures must also exist in this BizDevOps environment for both the nitty gritty technical aspects and the overlying systems that manage them. BMC Software, CA Automation, IBM and SolarWinds all offer monitoring tools. Overlying systems, such as Jenkins and the enterprise distribution version from CloudBees, manage the bigger process picture.
The final remaining link in a DevOps feedback loop is issue reporting and resolution -- in other words, the help desk and a knowledge repository. ServiceNow and BMC Remedy are two help desk applications that can simplify and streamline this step.
IT is not a solution to all of the business's problems on its own. IT provides support and facilitation for the business -- the business always comes first. Business profits pay for the developers, testers and operations staff, as well as physical and cloud platforms. Each technical and working group must bear this in mind and ensure that all tasks support the business through a comprehensive and well-documented BizDevOps feedback model.