We want to get new features and fixes into customer's hands as quickly as possible. We also don't want features and fixes to stack up because large batch sizes can slow us down. If we are to deploy frequently, we need (all the more) for deploys to be fast and to be free of adverse side-effects.
Meanwhile, other teams have processes (e.g. updating documentation, announcing releases) that need to be tied to certain deploys, and those efforts should be synchronized.
These processes should ensure:
- that regressions are minimized
- that deploying is resilient and reliable
- that deploying is inexpensive (so that deploys can be done frequently)
- that colleagues are informed of releases
- We write code that is "Hot Compatible" so that deploys have as little impact on running software as possible.
- Developers work on topic branches and create Pull Requests so that we can track changes and deploy them independently of each other.
- Another developer (usually the Project Maintainer) reviews the Pull Request. Code Review helps to disseminate insights, prevent regressions, and improve the quality of the codebase.
- We deploy Pull Requests to staging and "snag a tester" when they require testing.
- Project Maintainers regularly merge Pull Requests that have passed testing and review, and deploy them to Production.