4 ms·
This was very much valid before the docker workflows came to happen. Now maintaining two mainline branches forces you to break "don't build a container per env
by stonewhite 9y ago
This was very much valid before the docker workflows came to happen.
Now maintaining two mainline branches forces you to break "don't build a container per environment" cardinal rule. Trunk based development should be the go-to repository strategy for dockerized apps.
- icebraining 9y agoWhat's the purpose of that rule?
- stonewhite 9y agoIf you properly externalized the configurations, Docker provides bit-by-bit parity between environments granted you use the same image. This results in increased confidence to test environments and lessening the chances of a surprise during production deployments. It is the next logical step in immutable deployment paradigm[1]. [1]: https://martinfowler.com/bliki/ImmutableServer.html https://martinfowler.com/bliki/ImmutableServer.html
- icebraining 9y agoBut why not use the typical solution of having two testing environments, in this case based on "develop" and "master", with the latter being bit-by-bit equal to what gets deployed?
- stonewhite 9y agoWhat purpose does it serve but to double QA efforts. If you are testing the same stuff both in develop and master, why not just test only one and save some time. Ramming gitflow into a docker workflow efficiently is not really possible I believe.
- twic 9y agoThat's a good rule, and a correct deduction from it. However, it's not new to Docker workflows - you shouldn't build a good old fashioned binary per environment either!