[stonewhite]

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.

[twic]

That'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!

[icebraining]

What's the purpose of that rule?

[stonewhite]

If 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

[icebraining]

But 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]

What 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.