You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the pipeline will trigger and deploy in prod when a change only affecting staging is made. We want to separate these resources to ensure this doesn't happen. Production config (for example the number of job instances) should not have to flow through staging first. This will allow us to scale more quickly.
Acceptance Criteria
GIVEN a change is made affecting only staging
THEN a production deployment is NOT triggered
GIVEN a change is made affecting only production
THEN a staging deployment is NOT triggered
Security considerations
When all changes have to go through staging first, we cannot scale quickly. The number of VM instances in prod should not have to go through staging first.
The text was updated successfully, but these errors were encountered:
Currently, the pipeline will trigger and deploy in prod when a change only affecting staging is made. We want to separate these resources to ensure this doesn't happen. Production config (for example the number of job instances) should not have to flow through staging first. This will allow us to scale more quickly.
Acceptance Criteria
GIVEN a change is made affecting only staging
THEN a production deployment is NOT triggered
GIVEN a change is made affecting only production
THEN a staging deployment is NOT triggered
Security considerations
When all changes have to go through staging first, we cannot scale quickly. The number of VM instances in prod should not have to go through staging first.
The text was updated successfully, but these errors were encountered: