Currently, dev and staging are deployed-to simultaneously by the deployment pipeline, then later to prod. The current intent is that dev can be pointed at an experimental branch, while prod and staging stay pointed at the trunk.
- E.g. to update the
devenvironment to use an experimental branch instead of the trunk, retrieve the pipeline:fly -t fr gp -p my-pipeline > pipeline.yml
- Edit the pipeline file, for example with
vimvim pipeline.yml
- Unless the only change is to update which branch the pipeline is pointing to in
dev:- Retrieve credentials file from s3
- TODO: How?
- Validate the change you are making against the pipeline code in git by rendering the pipeline against the credentials file
fly validate
- Retrieve credentials file from s3
- Push the altered pipeline
fly -t fr sp -p my-pipeline -c pipeline.yml
Note: Concourse also forces you to view and approve the changes after running sp
Current proposed changes would simplify the deployment pipeline to something like the following:
- Make changes on short-lived branch
- Push branch
- Open PR
- Review/respond until reviewers are satisfied
- Branch gets merged to trunk
- Trunk deploys to
dev - Smoke tests run
- Trunk gets promoted to
stage - Smoke + acceptance tests + (optional) manual testing
- Trunk goes to
production