Continuous Delivery requires an entirely different mindset from classical artisanal delivery. For example, we always prioritize operations over development. If we cannot deploy something to our production environment, then nothing else matters. Therefore, the first feature to deliver is the ability to deploy to production. We deploy a Minimum Viable Deployable “hello world” UI or service to validate we can. Then we keep adding small changes very frequently to keep validating we can and to get operational feedback on those changes.
Another mindset shift is the definition of “Production”. Our primary product on a product team should always be the pipeline. It needs to always be green and it needs to have all of the quality and compliance gates coded into it to ensure our confidence to release. Only the pipeline defines releasable. If we are not releasable, our highest priority is to become so. The implications of this are incredibly important for teams who supply products and services to product teams to understand.
All of the following should be P1 issues from the perspective of platform teams:
- The product teams cannot deploy to production due to a production outage.
- The product teams cannot deploy to production due to instability in the testing/staging environments we manage.
- The product teams cannot deploy to production because our security tool is generating false positives.
- The product teams cannot deploy to production because our CI tool is unstable.
- I cannot deploy to production because my laptop is broken.
All of these are “production impacting issues” because if any of them are true then we cannot safely FIX production when something breaks. We do not downgrade an issue because “that’s only an issue in Staging.” We only downgrade issues that don’t prevent production delivery.
Written on November 1, 2021 by Bryan Finster.
Originally published on Medium