Weighing between a hardware- or a software-oriented approach
Let's go through pros and cons for a traditional vs "modern" approach to environments.
- Very easy to understand conceptually
- Should result in very good separation of environments
- You start expecting environmental parity between any other systems
- You start expecting that all systems are in similar, co-deployed stages
- The implicit reasoning starts becoming that you "should" or "can" only have a low degree of variability in configuration
- As a consequence, such "pre-baked" configuration tests may start becoming large-scale blocking, manual tests
- There may be significant cost overhead with a higher count of static environments
- There is most likely a significant complexity overhead with a higher count of static environments
- Less architectural complexity
- Cheaper with fewer environments
- No need to keep environments in sync
- Realistically promotes modern practices: "testing in production", trunk-based development etc.
- Scales to more intricate and realistic scenarios (such as testing system X in mode A with customer type B in configuration D etc.)
- Can add solution complexity
- Will become harder to work with in the local scope (i.e. the actual code), and more so if there are many branches
- Requires some degree of cleanliness and pruning (governance even) to control, so things don't grow out of hand
You can certainly use the patterns seen in this project in a more "traditional" hardware-separated environment. However, the benefits become more pronounced as you also shed some of the overhead and weight of classical environments.
Last modified 1yr ago