4 ms·

What does your company use? 1) 0 non-production + production 2) 1 non-production + production 3) 2 non-production + production 4) 3 non-production + product

What does your company use? 1) 0 non-production + production 2) 1 non-production + production 3) 2 non-production + production 4) 3 non-production + production 5) N non-production + production 6) Something entirely different. I was thinking about branch based environments or per developer environments but was not sure how to depict that in a simple poll. Feel free to chat amongst yourselves.

jensenbox 4y ago
Where I work we use option [2] - It works well. All merges to the main branch auto deploy to our Testing environment. Properly formatted tags go to Production as a release. The front-end team get branch based deployments. The backend has their local docker development. Try as we might, creating all the infra even with 100% terraform is a challenge - mostly for the swallowing of the AWS bill. We just could not see the cost/reward for doing more than just non-prod + prod. Totally open to ideas why 2 non-prods is better than 1.
TranquilMarmot 4y ago
Last three jobs I've been at, we've had three environments. Staging - Continuous deployment; whenever code is checked into the main branch, it automatically goes here QA - Once/twice a week we "cut" a release from what's in staging and promote it to QA. Our testers go through all of the changes and make sure that nothing is broken. We also have more rigorous integration tests running against this environment. Production - After everything is vetted in QA, it gets promoted again to production. I've seen some places have this take two weeks (in Agile terms, once a sprint). I've seen others do it basically every day (which IMO is too often). Once a week is the sweet spot for me.
anshumankmr 4y ago
2 Non Prod, 1 Prod, One of those Non Prod projects is usually a replica of Production, unless it is cost prohibitive.
lokar 4y ago
Ideally you want the ability for every developer to quickly spin up a full ephemeral env, test, and then tear it down.
- funcDropShadow 4y ago
  These makes only sense if you have proper test data or test data generation.
  - lokar 4y ago
    It depends on your system. Ideally you could tee/replay real traffic.

jensenbox 4y ago

Where I work we use option [2] - It works well. All merges to the main branch auto deploy to our Testing environment. Properly formatted tags go to Production as a release. The front-end team get branch based deployments. The backend has their local docker development. Try as we might, creating all the infra even with 100% terraform is a challenge - mostly for the swallowing of the AWS bill. We just could not see the cost/reward for doing more than just non-prod + prod. Totally open to ideas why 2 non-prods is better than 1.

TranquilMarmot 4y ago

Last three jobs I've been at, we've had three environments. Staging - Continuous deployment; whenever code is checked into the main branch, it automatically goes here QA - Once/twice a week we "cut" a release from what's in staging and promote it to QA. Our testers go through all of the changes and make sure that nothing is broken. We also have more rigorous integration tests running against this environment. Production - After everything is vetted in QA, it gets promoted again to production. I've seen some places have this take two weeks (in Agile terms, once a sprint). I've seen others do it basically every day (which IMO is too often). Once a week is the sweet spot for me.

anshumankmr 4y ago

2 Non Prod, 1 Prod, One of those Non Prod projects is usually a replica of Production, unless it is cost prohibitive.

lokar 4y ago

Ideally you want the ability for every developer to quickly spin up a full ephemeral env, test, and then tear it down.

funcDropShadow 4y ago
These makes only sense if you have proper test data or test data generation.
- lokar 4y ago
  It depends on your system. Ideally you could tee/replay real traffic.