Deploy via ArgoCD

All Meesho microservice deployments go through ArgoCD. deployArgoCD.groovy orchestrates a 4-step sequence per deployable: it first commits an ArgoCD Application manifest to devops-argo-config, then triggers a Helm values update in devops-helm-charts, and finally hard-refreshes and syncs the ArgoCD application.

TL;DR

4 steps per deployable: update_argo_repo → refresh_app_of_apps → update_helm_repo → refresh_and_sync.
Every step commits to a separate Git repo (argo-config or helm-charts), opens a PR, merges it, and deletes the branch.
The deploy waits for user input (checkbox UI) to choose which deployables to deploy, with a 300s timeout.
Multizone deployables are blocked — they must use Ringmaster.
JVM heap (xms/xmx) defaults to 50% of memory_limit, overridable via deployment_args.

Mental model

deployArgoCD treats Git as the deployment API. Every config change becomes a PR in devops-argo-config or devops-helm-charts, which ArgoCD polls and syncs. The pipeline commits the changes atomically for one deployable at a time in a for loop.

The user input step allows partial deploys — you can select "All" or individual apps from the checkbox list. If you skip input (timeout or skip_user_input=true), all apps in deployment_order are deployed.

Structure / data flow

deployArgoCD.run(repo_name, deployment_order, tag, ...)
  │
  ├─ [whitelist check] constructParam.allowedNonDevelopPrDeploymentToIntRepos()
  ├─ [user input] wait_for_user_input(deployment_order) — 300s timeout
  │
  └─ for each deployable:
       ├─ constructParam.isMultizoneEnabled(deployment) → ERROR if true
       ├─ constructParam.perDeploymentVars(value_binding)  ← sets env.argoURL, env.argoIncubator, etc.
       │
       ├─ stage: update_argo_repo()
       │    ├─ render argoApp.yaml template → devops-argo-config/applications_v2/<cluster>/<team>-<app>.yaml
       │    └─ commit → PR → merge → delete branch
       │
       ├─ stage: refresh_app_of_apps()
       │    └─ argocd app sync <argoIncubator>
       │
       ├─ stage: update_helm_repo()
       │    ├─ render values.yaml template → devops-helm-charts/<env>/bu/team/app/values.yaml
       │    ├─ [canary enforcement] enforce skipAnalysis=false for sp0/up0 services
       │    ├─ [dependabot check] block if CRITICAL CVEs on prd sp0-sp1 deploys
       │    └─ commit → PR → merge → delete branch
       │
       └─ stage: refresh_and_sync()
            ├─ argocd app get --hard-refresh <env>-<app_name>
            └─ argocd app sync <env>-<app_name>

Key code locations

Symbol	File	What it does
`run`	`src/com/meesho/stages/deployArgoCD.groovy:run`	Main entry — user input + per-deployable loop
`update_argo_repo`	`src/com/meesho/stages/deployArgoCD.groovy:update_argo_repo`	Renders ArgoCD Application YAML and commits to argo-config
`refresh_app_of_apps`	`src/com/meesho/stages/deployArgoCD.groovy:refresh_app_of_apps`	Syncs the incubator app-of-apps
`update_helm_repo`	`src/com/meesho/stages/deployArgoCD.groovy:update_helm_repo`	Renders Helm values and commits to helm-charts
`refresh_and_sync`	`src/com/meesho/stages/deployArgoCD.groovy:refresh_and_sync`	Hard-refreshes and syncs the ArgoCD app
`enable_backward_compatibility`	`src/com/meesho/stages/deployArgoCD.groovy:enable_backward_compatibility`	Fills in missing deployment.yaml keys with defaults
`dependabotCriticalCheck`	`src/com/meesho/stages/deployArgoCD.groovy:dependabotCriticalCheck`	Blocks deploy if CRITICAL CVEs found
`calculate_active_processors`	`src/com/meesho/stages/deployArgoCD.groovy:calculate_active_processors`	Converts cpu_request string to JVM -XX:ActiveProcessorCount

Sharp edges

Branch naming is environment-derived: helm_branch_name maps main/master→main, develop→develop, PR→feature or pre-prod. This is independent of cicd_environment — confusion between the two causes PR target mismatches.
Feature deployments use ingress namespacing: for envrn=ftr, Helm values go into values_properties.yaml under <ingress_val>/ subdirectory, and the app branch is prefixed with <ingress_val>-.
AppConfig gate: appConfigDisabledForbidden() blocks stg deploys for Maven/Gradle repos that have appConfigEnabled=false and are not in the app-config-disabled whitelist.
xms/xmx auto-calculation: for Maven/Gradle, heap is set to 50% of memory_limit. This can be overridden by Xms<val> or Xmx<val> tokens in deployment_args. If a service hard-codes -Xmx in JAVA_OPTS, the auto-calculated value will collide; use jvm_memory_override: true in deployment.yaml to suppress auto-calc.
Canary is mandatory for sp0/up0: deployArgoCD.groovy:run (src/com/meesho/stages/deployArgoCD.groovy:run) blocks a non-canary prd deploy when priority_v2 is sp0 or up0. There is no whitelist or flag to bypass this check — it happens before any Helm update.
The 4-step order is load-bearing: steps 2 (refresh_app_of_apps) and 4 (refresh_and_sync) are not interchangeable. Skipping step 2 on a first deploy means the ArgoCD Application object hasn't been created yet, causing step 4 to target a non-existent app.

ArgoCD sync — detailed step-by-step sync sequence
Ringmaster integration — when deployRingmaster runs instead
Whitelist system — multizone + allowedNonDevelop gates
Node pool selection — how nodeSelectorValue is computed

Notes

← Previous · Index · Next →

6.1 KiB Raw Blame History