Eventless software releases - Jenkins Tutorial

- [Instructor] Do you ever feel like releasing a new product or feature is like participating in an action movie, dodging all sorts of unexpected twists? When we frequently come across unexpected deployment problems during stressful out-of-business hours interventions, releasing becomes a dreadful and scary activity. Everyone will want to avoid releases. Therefore each release becomes larger and more risky as multiple changes get bundled in. It's a vicious cycle, but it doesn't need to be that way. One of the principles of continuous delivery is, "If it hurts, do it more often." Instead of shying away from releases, we need to address the obstacles to safe and frequent delivery, not push the pain forward. We aim at including all necessary release activities in the delivery pipeline. This will not happen from one day to another, but if every unexpected problem or action effecting a release is addressed in our pipelines so they become detectable as early as possible, then we are reducing the risk of failure for all future releases and that's a worthwhile investment. Consistently and relentlessly earning out problems is the key to achieve eventless releases. We need a high level of trust that our delivery pipeline is repeatable and predictable enough to release as often as the business needs unhindered by technical constraints. Releasing software becomes more like grocery shopping an eventless, predictable activity that we can perform as often as we need rather than a big bank event. For example, imagine our software updates require restart of the application and occasionally it fails to boot leading to unexpected downtime. Can we test the restart action in the pipeline, perhaps reproducing its state by cloning the production database and anonymizing it first. Or could we avoid downtime altogether with rolling deployments instead? Or if we often encounter missing or conflicting third party dependencies in our production environment during a release. Can we provision test environments that are similar possible to production so we can identify these issues early on instead of during a stressful out of hours release. What about scaling? Are we anxious about releasing an important feature just before a big shopping holiday? Can we make it easy to simulate growing traffic levels and find out if and when our application breaks. And can we do this early in the delivery life cycle instead of just hoping for the best at production time? We might not be executing performance tests on every pipeline run, but we know we can do it whenever there's a business expectation of a surging demand or performance sensitive software change. The goal is to have a repeatable release process that includes all the necessary tests and validations in the pipeline so that nine out of 10 releases are eventless or more. And in the 10% of cases unexpected issues occur. Then for the most part, it should be fairly straightforward to roll back. We can then sort out the problem without the pressure of a stressful release event with dozens of people on hold. John Cutler calls this "Low-drama flow."" He says that low-drama flow doesn't look like progress to most people. There aren't the burnouts and the tantrums. This means we are instead continuously and blamelessly delivering changes while also continuously improving the delivery process as opposed to frequent firefighting and dealing with unexpected problems. Low-drama flow is ironically a strong indicator of high-speed softer delivery. This leaves us with more time and mental capacity to focus on the outcomes we want to achieve. Bringing features to customers, fixing issues quickly, improving performance and so on. It also decouple's business decisions from the Friday syndrome where we avoid releasing on a Friday or before a holiday out of fear of problems. With eventless releases, we have the confidence to release when it makes most business sense, even on a Friday. This doesn't mean we shouldn't be pragmatic however. If we don't have at least a daily delivery cadence and a given release is not time sensitive, then let's avoid Fridays. The point is that we can never guarantee release will cause no issues, but we know that we drastically reduce the probability of that happening.