35 lines
1.5 KiB
Markdown
35 lines
1.5 KiB
Markdown
---
|
|
title: >
|
|
Fail fast, fix fast
|
|
pubDate: 2023-12-17
|
|
permalink: >-
|
|
archive/2023/12/17/fail-fast-fix-fast
|
|
tags:
|
|
- software-development
|
|
- continuous-delivery
|
|
- continuous-deployment
|
|
- deployments
|
|
- feature-flags
|
|
---
|
|
|
|
I recently listened to a podcast that discussed Elon Musk and quoted something like, "If 20% of attempts aren't failing, you aren't taking enough risk".
|
|
|
|
In a software context, I'm not advocating that one in five production releases should fail, but I like trying new ideas and approaches.
|
|
|
|
If you're releasing small changes regularly or practising continuous deployment, changes are easy to revert if there's a problem or the smaller the deployment and the more recently the code was written, then it should be easier to resolve the issue and "fix forward" instead of rolling back.
|
|
|
|
Using feature flags lets you quickly turn off a feature flag while investigating and resolving the issue without needing another deployment.
|
|
|
|
If you have an appropriate plan to follow in the case of an issue, that mitigates the risk and minimises the impact of a potential issue - making it quicker to resolve and restore the service.
|
|
|
|
Two of the DORA metrics refer to failure rate and restoration time:
|
|
|
|
* Deployment frequency
|
|
* Lead time for changes
|
|
* Change failure rate
|
|
* Time to restore service
|
|
|
|
Then, it depends on your organisation's tolerance for risk and what's acceptable.
|
|
|
|
But, the more frequent the releases, the lower the failure rate and the quicker it will be to restore the service if there is an issue.
|