#release-engineering (2023-06)
All things CI/CD. Specific emphasis on Codefresh and CodeBuild with CodePipeline.
CI/CD Discussions
Archive: https://archive.sweetops.com/release-engineering/
2023-06-02
For updating to newer AMIs (custom or public), what’s your release strategy to release up through dev->int/test->stage->prod?
We want to get to the point of fully automatic releases (with delays, and maybe PR approvals up to each environment).
Thinking of simple:
- renovate sends PR to pin new AMI to dev
- terraform automation (such as Atlantis) sees the change
- human approves the PR (or auto-approval after N days)
- renovate sees dev and int are different, so sends PR for int
- repeat 2-3
- stage ….
- prod …
Yes, that seems reasonable for an atlantis-style workflow
Said another way, what we would do is:
- Update the new version (e.g. via renovate PR).
- Merge to main → deployment
- Release to dev
- Release to staging (upon successful release to dev)
- Release to production (upon successful release to prod). In this model, we’re decoupling release from deployment. We want all environments to converge on the same version. We want to release the new version to each environment sequentially.
Thanks. Mind clarifying that? Are all the git changes done on 2. Merge? Or are 3/4/5 each separate PRs?
2023-06-06
2023-06-07
2023-06-20
This message was deleted.
2023-06-28
Hello, how do you deal with Docker in Docker builds that are being shared by multiple repos? I’ve got GitlabCI repos that share one Gitlab runner. Both repos have multiple stages and last stage is pruning volumes and images. If both pipelines run at the same time one of them finishes and prunes volumes that are being used by other pipeline at the same time. Should I not prune volumes? I know I can delete images older than x, but volume command does not have the same flag
I can see there is a way to remove only dangling volumes. I wonder if Gitlab cache is a dangling volume in between stages..
Sounds like it’s a self-hosted runner, I’d probably just setup a cron job on the runner to prune dangling images nightly (or whatever frequency makes sense) instead of on each run.
You could also use a scheduled pipeline instead of a cron job. https://docs.gitlab.com/ee/ci/pipelines/schedules.html
scheduled pipeline would be better than cron job I think. I guess I could edit the existing jobs to have prune as an optional stage and only trigger with scheduled pipeline. Thanks!