Turn any signal into insight and action. See how PagerDuty Digital Operations Management Platform integrates machine data and human intelligence to improve visibility and agility across organizations.
Check out the latest capabilities we released.
Flexible schedules, escalations, & alerting
Automated, best practice incident response
Powerful context & noise reduction at scale
Quantify real-time business & technical impact
Improve with modern, prescriptive insights
Over 300 Integrations
Discover DevOps best practices with our library of webinars, whitepapers, reports, and much more.
Learn best practices and get support help with resources from our award-winning support team.
See how PagerDuty works with our live product demo — twice a week, every week.
We've created a maturity model to assist on the journey to digital operations excellence. Take our short assessment to find out where your team falls!
Interactive, simple-to-use API and technical documentation enables users to easily try updates and extend PagerDuty.
Engage with users and PagerDuty experts from our global community of 200k+ users. Become a member, connect, and share insights for success.
Get all your PagerDuty-related questions answered by exploring our in-depth support documentation and community forums.
In part 2 of our postmortem series, we dig into how to establish a culture of continuous learning, from getting leadership on board to invoking...
PagerDuty helps organizations transform their digital operations. Learn more about PagerDuty's mission and what we do.
Meet our experienced and passionate executive team.
We are risk-taking innovators dedicated to delivering amazing products and delighting customers. Join us and do the best work of your career.
With the PagerDuty Foundation, we are committed to doing our part in giving back to the community.
This is one of two PagerDuty posts on Continuous. Check out our first one: Are You Ready for Continuous Deployment?
If you pay any attention to modern software delivery conversations, it sometimes feels like you are being beaten over the head with a Continuous magic wand. Continuous Integration, Continuous Delivery, Continuous Deployment, Continuous Documentation, etc. The idea is so easy that it’s frustrating: Go fast. But the benefits of going fast are well beyond more builds to your user base. Perhaps the greatest value is long term, and hidden in how you can break the application continuously without fear because you can fix it continuously as well.
What does speed get you in the long term? Over a period of three months, can you say something more about your pipeline than “We had more builds”? More releases are one thing. But a delivery chain that does not support innovation is nothing more than a way to get from point A to point B. To demonstrate real success in a DevOps-driven organization, you need to be able to show that your software quality and functionality increases as well — which means all that cool functionality sitting buried in your backlog finally percolates to the top.
What Continuous affords us is the ability to break our applications with confidence — because we know we can rapidly alert on any issues, and iterate to a new build to address them. Teams can now implement a feature that they have been dying to implement but have avoided due to perceived risk.
What break/fail fast really means is that you can be opportunistic about your functionality, which quite possibly is the only way to build functionality that responds to user demands in near-real-time, or to learn how new functionality impacts the application and adoption. Without fail fast, applications may be doomed to purely linear releases, no matter how short your sprints are. And they can fall into the same trap we are all too familiar with — stagnation, also known as the eventual slowing of new functionality in favor of very small changes to existing functionality. When this happens your application gets stale, and can only be addressed with major rewrites, refactoring, or whole new applications. This is not Continuous at all, or at least not sustained Continuous.
The extreme of fail fast and fix fast is something called canary releases. In a canary release you have one or more new releases of the application in parallel to the existing production version. Once the release(es) are complete, you divert all or sub-segments of traffic from production to the new release environments. The purpose of sub-segments is to do A/B testing on slight variations of the releases.
If anything goes wrong with a canary release, you will know quickly with a robust alerting mechanism. Then, you’ll revert traffic back to production. The exercise might have a small negative impact on your users, but the response is so rapid that it seems like a glitch. New functionality could be developed within day-length time frames.
Because you’ve learned more about the new functionality, you can either drop it, or fix it within that canary release, and rapidly test again. This truly is an iterative model. And it can be set up as not just one iteration, but rather multiple iterations going on in parallel.
This model would also be considered the extreme of continuous deployment, though without some of the automated functional and system testing before releases. These processes can be too long to support the concept. It does assume a few things. The biggest is that your application has a high enough user base and volume to support quick tests of new functionality.
I have not figured out how this can work with a highly distributed microservices application, but I am sure it is possible, if you have:
Of course, such an advanced way of looking at both releases and application architectures requires great tooling to execute it. And the top three tools for fail fast are as follows:
The concepts around releasing faster, breaking faster, and fixing faster are not complex. But implementing them in existing environments can be. And this is where any experienced developer, operations and QA person knows that you cannot simply turn on the canary release switch.
Implementation is a journey, but the above process is a goal. And what is nice about the already popular process of continuous integration is that the experimental fail and revert process can be implemented in integration environments. There the impact is only on your internal team. In this case, the impact will mostly affect QA, as they will be responsible for testing releases as soon as they are built, so the biggest organizational change exists there. (Still far less than implementing team-wide and in production.)
The bottom line is the tools are available to build faster, fail faster, and fix faster — a process that will not only increase the number of builds you do a year, but also the innovation that can take place to produce newer functionality and quality. Because the tools already exist, the burden is on the team to find a path from their existing release processes to new processes.
This blog was co-authored by myself and Simon Darken. Once a year, PagerDuty’s SREs get together for a three-day, in-person offsite. With the team spread...
A release is a set of customer visible and operational features that together provide a completely new or improved product capability. It’s something that’s meaningful...
600 Townsend St., #200
San Francisco, CA 94103
905 King Street West, Suite 600
Toronto, ON, M6K 3G9, Canada
1416 NW 46th St., St. 301
Seattle, WA 98107
5 Martin Place
1 Fore St,
London EC2Y 9DT
© 2009 - 2019