Last week, we posted part one of this blog series for our Stat customers and prospects, in which I stated our Stat users may already be doing DevOps and not realize it. I suggested the functionality in Stat empowers organizations to achieve the goals of DevOps, and the practices that underpin DevOps known as ‘The Three Ways.' This week’s blog will distill the goals espoused in ‘The First Way.’
‘The First Way’ seeks to create a delivery system that is able to release reliable software to the customer or end-user. DevOps breaks down the barriers, and stove-piped processes, and perspective of various team members such as developers, administrators, Q/A, and business stakeholders. In its simplest terms, developers, for example, must understand how their actions may affect others downstream. DevOps is about having greater visibility and transparency through the entire delivery system. This means all team members have visibility from the time a business owner submits a request to the time the request is implemented, and the customer is realizing the benefits they requested.
Stat supports this left-to right flow in the form of its workflow. Our Stat customers may design workflows to support the processes defined in the DevOps delivery system. The associated business rules, transfer rules, status rules, and approval rules ensure the process is not only defined, but also provides a quick view for all stakeholders into the status of the request and which steps have been completed and what needs to be done next.
For example, in the depicted workflow, the stakeholder is able to see the request is in the ‘Deploy to Dev’ stage and is not ready to be deployed to the Test environment. The stakeholder may click the ‘view details’ link to quickly see what actions need to be completed to proceed to the next stage.
In this example, the details reveal two required tasks are incomplete. No guessing, or having to schedule a meeting, to determine the status or needed action. Additionally, Stat supports business rules, such as sending a notification to an assigned user, group of users when a task is overdue.
In order to maximize flow of work, Stat supports small batch sizes and intervals. DevOps teams need Small batch sizes and intervals of work to ensure defects are never passed downstream. Small batch sizes and intervals of work are CSRs. CSRs containerize work that may be assigned and worked based on work type and priority. Multiple CSRs may be grouped together into a project and/or their archive sets (builds) tagged with releases so they are deployed to the target environment at the same time. If issues are identified with the release, stakeholders are able to make decisions on whether or not to hold up the entire release or exclude the archive set (build) with the issue. This allows good work to move forward and the defective build reworked. The net result, no defects passed downstream and good work moves forward.
I would love to hear how your organization has implemented DevOps and Stat’s role. Please respond to this blog with your comments and suggestions.
Stay tuned for next week’s blog on the ‘The Second Way’.
