Last week we posted part two of this blog series for our Stat customers and prospects in which we examined the The First Way and how users can use Stat’s functionality to achieve goals and the practices that underpin DevOps. This week’s blog will distill the goals espoused in ‘The Second Way’ and how Stat can empower your organization to achieve ‘The Second Way’ practices.
‘The Second Way’ emphasizes the right-to-left constant flow of feedback at all stages of the value stream. The primary objective of this feedback is to identify problems as quickly as possible in order to prevent problems from reoccurring again or enable faster detection and recovery. As a result, quality is created at the source by creating and embedding knowledge where needed.
Stat does a good job of providing immediate feedback at all stages of the value stream. For example, Stat’s Business Rule Editor may be used to send Email notification messages to all or selected stakeholders when an event has occurred such as a request’s task, status, approval, or transfer has not occurred timely or a migration (deployment) has completed with a warning or error.
Stat also allows individual users to define personal rules to keep them in the loop when events occur for which they wish to be notified.
In all, ‘The Second Way’ consist of the following five practices:
- “Stopping the production line” when builds and tests fail
- Constantly elevating improvement of daily work over daily work
- Creating fast automated test suites to ensure that code is always in a deployable state
- Creating shared goals and shared pain between Development and IT Operations
- Creating pervasive production telemetry so everyone can see whether code and environments are operating as designed and customer goals are met
“Stopping the production line” when builds and tests fail
You may recall me saying in a previous blog DevOps borrows from manufacturing principles. The main point here is you do not deploy builds or code with defects to your production environment or to any environment. DevOps espouses stopping the deployment and fixing the issue before proceeding. You do not deploy defect and fix them in the target environment. For example, the Development team should never throw code or testing defects “over the fence” to IT Operations for them to “figure it out” and fix.
Fortunately, Stat’s status and transfer rules may be configured to prevent builds from being deployed or advanced to the next stage in the process. Further, Stat provides functionality to capture issues and track them through resolution ensuring issues or defects are not passed downstream. Issues are documented in Stat all the way through to resolution thereby providing the team visibility into the cause and resolution. This helps the DevOps team continually improve their practices, which leads us to our next Second Way practice of constantly elevating improvement of daily work over daily work.
Constantly elevating improvement of daily work over daily work
I was actually told one time that I, as a manager, had to choose whether I wanted quantity or quality. I could not have both given the amount of work and resources. Rework or break-fix also known as unplanned work in the DevOps world should be limited or eliminated. It is what impacts schedules and causes the consumers of our applications to lose confidence in the ability of the DevOps team to deliver working applications on time.
DevOps teams should be constantly looking for ways to improve the quality of their applications instead of just trying to complete their assigned work. Automation is, in my mind, key to helping teams get out from under the quantity is key mindset so more time may be spent improving applications. For example, instead of developers spending as much as fifty (50) percent of their time doing non-developer tasks such as sending Emails to users, providing status of work in process, and performing manual deployments in non-prod environments. More automation means more time to develop quality code. Alternatively, another way of saying it, get the job done right the first time.
Again, Stat users are able to automate builds and deployments, notifications, approvals and status reports.
Creating fast automated test suites to ensure that code is always in a deployable state
Let’s face it; some developers do not like testing their code. Especially if the testing is manual and when pressed for time. If it compiles it is good to go.
Augmenting Stat with the code testing automation capabilities of Toad for Oracle is a great way for developers to automate the testing process. Testing automation also makes developers more productive and leads to higher code quality as well as prevents code defects from moving downstream.
The manner in which Stat versions and creates builds, aka archive sets, ensures code is in a deployable state.
Creating shared goals and shared pain between Development and IT Operations
DevOps is all about breaking down silos between Development, IT Operations, and other stakeholders such as Quality and Business Owners. There should be no room for finger pointing, excuses, circumvention, or cover-up in DevOps teams. For many organizations, this is a significant culture change. It is a culture of winning together and a culture of continual learning and improvement.
Creating pervasive production telemetry so everyone can see whether code and environments are operating as designed and customer goals are met
Stat does a good job of capturing a lot of information about environment changes as well as code and object changes. DevOps teams may leverage this information in the form of seeded reports that may be scheduled and distributed via Email to business and other stakeholders such as quality and internal audit. Additionally, key metrics such as the velocity of changes by priority may be developed using available report data in Stat.
Performance Monitoring solutions such as Foglight for Oracle, Foglight for E-Business Suite, and Foglight for PeopleSoft help monitor the health and performance of your applications and databases as well as help diagnose issues.
I would like to hear how your organization has implemented DevOps and how you have used Stat, Toad, and/or Foglight to meet any of ‘The Second Way’ practices. Please respond to this blog with your comments and suggestions.
Stay tuned for next week’s blog on the ‘The Third Way’.
