Starting with Production
Too many times, I have worked with clients where the client demands that we create a new system starting with a development environment. From there, they often want to create additional environments in front of production. QA, UAT and Staging perhaps. Then comes production. Unfortunately, this approach is a fallacy. It often ends with far more environments than are necessary, high infrastructure costs, and insane amounts of time and effort on initial creation and continued maintenance.
Depending on the particular scenario at hand, one of two alternative approaches serve can be much more effective.
Production First
If you don't have an immediate need to begin treating the environment labeled "production" as a production environment, then start by creating that environment and then build previous environments as necessary. Those last two words are important. Do you really need a QA, UAT, and Staging environment? Probably not. You can likely solve your problem with feature flags (hint hint ? ).
Staging then Production
In cases where you might need to immediately begin protecting what goes into production (typically very uncommon for greenfield systems), you might want to create a staging (or dev) environment and then create your production environment. Any additional environments can be dropped in afterward as necessary.
The Benefits
This approach provides the following value (and more):
- Quicker time to market
- Less process and technical overhead
- Lower complexity
- Reduced cost (if you can use 2 environments instead of 5, you've reduced your operating expenses by up to 60% for an entire system)
In the end, it's all about considering the impact that cumbersome processes have on productivity. And this is one place where processes can easily bend with the appropriate tooling and culture to still fit the same bill while also enabling higher performance among teams.