#release-engineering (2023-06)

jenkins_ci All things CI/CD. Specific emphasis on Codefresh and CodeBuild with CodePipeline.

CI/CD Discussions

Archive: https://archive.sweetops.com/release-engineering/


Sean avatar

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).

Sean avatar

Thinking of simple:

  1. renovate sends PR to pin new AMI to dev
  2. terraform automation (such as Atlantis) sees the change
  3. human approves the PR (or auto-approval after N days)
  4. renovate sees dev and int are different, so sends PR for int
  5. repeat 2-3
  6. stage ….
  7. prod …
Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Yes, that seems reasonable for an atlantis-style workflow

Erik Osterman (Cloud Posse) avatar
Erik Osterman (Cloud Posse)

Said another way, what we would do is:

  1. Update the new version (e.g. via renovate PR).
  2. Merge to main → deployment
  3. Release to dev
  4. Release to staging (upon successful release to dev)
  5. 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.
Sean avatar

Thanks. Mind clarifying that? Are all the git changes done on 2. Merge? Or are 3/4/5 each separate PRs?




SlackBot avatar
01:12:39 AM

This message was deleted.


Audrius avatar

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

Audrius avatar

I can see there is a way to remove only dangling volumes. I wonder if Gitlab cache is a dangling volume in between stages..

bradym avatar

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 pipelines | GitLab

Documentation for GitLab Community Edition, GitLab Enterprise Edition, Omnibus GitLab, and GitLab Runner.

Audrius avatar

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!