1

I have a question how to deal with ArgoCD Rollout for different Environments.

For my continuous deployment pipelines, I follow the principles you can see in below image.

enter image description here

As explained in these blogs blog1 blog2, in its current design the pipeline behave same for my all environments, 'dev', 'test', 'staging', 'production'.

I like to implement 'blue/green' deployments for 'production' environment but only for 'production', naturally I don't want to have different Helm constellations for 'dev', 'test', 'staging' and 'production' in Helm, so no 'rollout.yaml' for 'production' and 'deployment.yaml' for the rest, so I need a clever solution.

I can do something like that as here

spec:
  replicas: {{ .Values.replicaCount }}
  revisionHistoryLimit: 3
  selector:
    matchLabels:
      app: {{ template "helm-guestbook.name" . }}
      release: {{ .Release.Name }}
  strategy:
    {{ tpl toYaml .Values.rolloutStrategy . | indent 12 }}
  template:
    metadata:

and in 'values-dev.yaml' (or '-test.yaml' or '-staging.yaml).

rolloutStrategy:

and in 'values-prod.yaml'

rolloutStrategy: 
  blueGreen:
    activeService: {{ template "helm-guestbook.fullname" . }}
    previewService: {{ template "helm-guestbook.fullname" . }}-preview

but I am not really fond of this solution, can you think anything better?

posthumecaver
  • 1,584
  • 4
  • 16
  • 29
  • to be honest, drifting release mechanisms between environments is something id be weary of - i develop expecting failure and that we will iterate on an initial implementation. In your above, where only prod has B/G, how do you improve this release mechanism? If you're worried about cost, then lowering requests/limits and replicas for lower level environments will help mitigate that concern. – LostJon Mar 17 '23 at 13:18

0 Answers0