Want DevOps Continuous Delivery? Don’t forget the quality
Modern web, mobile and cloud based applications are the only way to engage with customers at scale.
Savvy businesses understand this, which is why their point of differentiation has become the ability to deliver software releases faster than competitors.
But none of this counts for much if all you are accelerating is the delivery of poor quality applications for your customers.
More releases and frequent changes into production can also be risky, just talk to anyone in Operations who are on the receiving end.
So how do you ensure faster and more frequent releases doesn’t result in more defects released into production? At the same time, how can you ensure operations are agile enough to respond to this accelerated rate of release and change?
Customer experience is often only measured once an application is released to production and is considered exclusively an operational function. An odd situation, given that there a many functions in an applications lifecycle which have an impact on the customer experience.
The design, development, testing and release functions all have an impact on customer experience.
Change is the primary cause of incidents in Operations. When an incident occurs, the bulk of the time to restore service is spent identifying what has changed in the environment.
This does not need to be the case. With APM 10 “Timelines”, operations can visually chart all changes for a time period leading up to and resulting in the incident.
By automatically correlating these events to any resulting performance issues or service outage, cross-functional teams can dramatically reduce triage time.
APM solutions have traditionally been considered part of the Operations team monitoring arsenal; providing valuable insight into customer impacting service issues like, application availability, application performance and code based errors.
Having this level of visibility in Ops is incredibly valuable, but only if it is shared with the upstream functions during development, test and release. As anyone in Ops can attest, Ops can’t actually fix the root cause of these issues. Sure they can restart, reboot or rollback any number of things to restore service, but they don’t actually write any code to fix a root cause.
It’s essential therefore that Ops’ critical role is to facilitate the rapid sharing of information with development and the business to fix the root cause.
Experience has shown me that progressive organisations often reach a “light-bulb” moment – concluding that baking APM monitoring visibility into the software lifecycle cycle (dev and test) would be incredibly valuable to reduce defects. They understand that early problem detection leads to a higher quality experience, but also that and deeper analytical insights into user behaviors is critical to informing design considerations.
Smart developers know APM tools are not just the domain of Ops, but can actually help them reduce transaction response times, find code defects or address integration issues.
Developers want to spend time innovating, not chasing bugs, and APM tools can help them. Ultimately this leads to faster application delivery, at lower cost and don’t forget — with a higher quality