--- tags: adh --- # ADH Release Model ## General Ideas * `master` branch must be releasable any time and independently from any other service * We do rolling updates and/or blue/green deployments which has a few implications: * During an upgrade period, old and new versions of a service are running at the same time * There must be no breaking changes between two subsequent versions, neither on API level, nor on database level * Breaking changes must be introduced across a series of deployments using [parallel change](https://martinfowler.com/bliki/ParallelChange.html) mechanisms and [evolutionary database design](https://martinfowler.com/articles/evodb.html) * Feature toggles can help here * We should integrate on `master`only. Long-running feature branches are an anti-pattern, especially when you have multiple services that need new features that depend on each other. Cardinality can explode soon and integration can become painful. CI and deployment pipelines would have to consider multiple branches and would become very complex. * We should embrace feature toggles ## Feature Toggles * Cross-cutting concern * We need a central toggle server, no team-specific solution * Toggle server per environment? * Toggle server per tenant? * Links: * https://unleash.github.io/ * https://blog.codecentric.de/en/2019/02/feature-toggles-benefits-drawbacks/ * https://blog.codecentric.de/en/2019/05/feature-toggles-in-a-microservice-environment-part-2-implementation/