--- description: Verkada backend service build and deploy workflow using vdev/just. Covers repo selection, build modes (CREW/invoke/local), deployment to staging/prod, and monitoring via ArgoCD and vdog. category: verkada --- flowchart TD _HEADER_["
Build and Deploy Service
Verkada backend service build and deploy workflow using vdev/just. Covers repo selection, build modes (CREW/invoke/local), deployment to staging/prod, and monitoring via ArgoCD and vdog.
"]:::headerStyle classDef headerStyle fill:none,stroke:none subgraph _MAIN_[" "] %% Phase 1: Preparation subgraph Prep["Phase 1: Preparation"] FIND_REPO[Find Free Repo
via repos] --> PULL[Pull Latest Master] PULL --> AUTOFIX[Run just autofix] AUTOFIX --> AWS_CHECK{AWS Creds
Valid?} AWS_CHECK -->|No| LOGIN[just login] AWS_CHECK -->|Yes| READY[Ready to Build] LOGIN --> READY end %% Phase 2: Build subgraph Build["Phase 2: Build"] READY --> MODE{Build Mode?} MODE -->|Default| CREW[CREW Remote Build
just build -c SERVICE] MODE -->|Invoke| INVOKE[Invoke Build
--use-invoke] MODE -->|Local| LOCAL[Local Bazel Build
--local] CREW --> BUILD_RESULT{Build OK?} INVOKE --> BUILD_RESULT LOCAL --> BUILD_RESULT BUILD_RESULT -->|Yes| HASH[Extract Build Hash] BUILD_RESULT -->|No| BUILD_DIAG{Diagnose Failure} BUILD_DIAG -->|Retry invoke| INVOKE BUILD_DIAG -->|Retry local| LOCAL BUILD_DIAG -->|Auth error| LOGIN end %% Phase 3: Deploy subgraph Deploy["Phase 3: Deploy"] HASH --> ENV{Target Environment?} ENV -->|Staging| DEPLOY_STAGE[Deploy to Staging
-e staging] ENV -->|Prod| APPROVE{Team Approval?} APPROVE -->|Yes| DEPLOY_PROD[Deploy to Prod
-e prod] APPROVE -->|No| WAIT_APPROVE[Get Approval] WAIT_APPROVE --> APPROVE DEPLOY_STAGE --> DEPLOY_RESULT{Deploy OK?} DEPLOY_PROD --> DEPLOY_RESULT DEPLOY_RESULT -->|Yes| MONITOR_START[Start Monitoring] DEPLOY_RESULT -->|No| DEPLOY_DIAG[Check ArgoCD
for Errors] DEPLOY_DIAG --> DEPLOY_FIX{Fix Type?} DEPLOY_FIX -->|Sync issue| ARGO_SYNC[ArgoCD Sync/Prune] DEPLOY_FIX -->|Code issue| READY ARGO_SYNC --> MONITOR_START end %% Phase 4: Monitoring subgraph Monitor["Phase 4: Monitor"] MONITOR_START --> ARGO_STATUS[ArgoCD App Status] MONITOR_START --> VDOG[vdog Pod Versions
by version tag] ARGO_STATUS --> ROLLOUT{Rollout
Complete?} VDOG --> ROLLOUT ROLLOUT -->|Yes| DONE([Deploy Complete]) ROLLOUT -->|No: stuck| ARGO_WAIT[Wait + Re-check] ROLLOUT -->|No: failing| ROLLBACK[Rollback via ArgoCD] ARGO_WAIT --> ROLLOUT ROLLBACK --> READY end %% CI/CD Alternate Path subgraph CICD["Alternate: CI/CD Pipeline"] CI_START[CI Trigger] --> CI_BUILD[just build -c SERVICE
-m text] CI_BUILD --> CI_HASH[Parse BUILD NUMBER
from stdout] CI_HASH --> CI_DEPLOY[just deploy
-m text] CI_DEPLOY --> CI_DONE([Pipeline Complete]) end click FIND_REPO "#" "**Find Free Repo**\nRun `repos` to see status of all Verkada-Backend-{1-10} directories.\nLook for: `FREE (master, clean)` in green.\n\nA free repo means:\n- On master with no branch checked out\n- Clean working directory\n- No unpushed commits" click PULL "#" "**Pull Latest Master**\nNavigate to the free repo and update:\n`cd ~/verkada/Verkada-Backend-N`\n`git pull origin master`\n\nCritical for clean builds -- stale code causes:\n- Build failures from outdated deps\n- Inconsistent artifacts\n- Deployment issues" click AUTOFIX "#" "**Run just autofix**\nFix linting, formatting, and BUILD files before building.\nMandatory step to avoid CI failures.\n\n`just autofix`" click AWS_CHECK "#" "**AWS Credentials Valid?**\nBuilds require valid AWS credentials for:\n- S3 artifact storage\n- ECR container registry\n- BuildBuddy remote execution\n\nIf expired, run `just login` to re-authenticate via SSO." click LOGIN "#" "**just login**\nPerform AWS SSO login.\nRequired when credentials expire (typically every 8-12 hours).\n\n`just login`" click READY "#" "**Ready to Build**\nAll prerequisites met:\n- Free repo on latest master\n- Autofix applied\n- AWS credentials valid\n\nProceed to choose build mode." click MODE "#" "**Build Mode Selection**\n- **Default (auto):** Uses CREW remote build if available, else falls back to local. Best for most development.\n- **Invoke:** Force local build via invoke. Use with `--publish` for artifact publishing.\n- **Local:** Force local bazel build. Best for quick iterations.\n\nThere is NO `--build-mode` flag. Use `--use-invoke` or `--local`." click CREW "#" "**CREW Remote Build**\nDefault build mode using remote CREW infrastructure.\n`just build -c SERVICE_NAME`\n\nFull-screen TUI with progress bars and spinners.\nAdd `-m text` for plain text output.\n\nReturns a build hash on success." click INVOKE "#" "**Invoke Build**\nLocal build via invoke, supports publishing.\n`just build -c SERVICE_NAME --use-invoke`\n\nUse with `--publish` to push artifacts.\nRequired for local builds that need to publish." click LOCAL "#" "**Local Bazel Build**\nDirect local bazel build, fastest for iteration.\n`just build -c SERVICE_NAME --local`\n\nNo remote infrastructure needed.\nBest for quick local testing cycles." click BUILD_RESULT "#" "**Build Result**\nSuccess: Build hash printed to output.\nFailure: Check error messages for diagnosis.\n\nIn text mode, look for:\n`BUILD NUMBER: abc123def456`" click HASH "#" "**Extract Build Hash**\nCapture the build hash for deployment.\n\nInteractive: note the hash from TUI output.\nCI/CD: parse from text output:\n`grep 'BUILD NUMBER' build.log | awk '{print $NF}'`\n\nHash format: 12-char hex string (e.g., `abc123def456`)." click BUILD_DIAG "#" "**Diagnose Build Failure**\nCommon failures:\n- **Component not found:** verify name and spelling\n- **Remote build failed:** retry with `--use-invoke` or `--local`\n- **Auth error:** run `just login`\n- **BuildBuddy errors:** check logs via buildbuddy-cli" click ENV "#" "**Target Environment**\nChoose deployment target:\n- **staging:** Test environment, safe for experimentation\n- **prod:** Production, requires team approval\n\nCan also target specific shards with `-s` flag:\n`prod1`, `prod2`, `staging2`, etc." click DEPLOY_STAGE "#" "**Deploy to Staging**\n`just deploy --component SERVICE -e staging -b BUILD_HASH`\n\nSafe for testing. No approval required.\nAdd `-m text` for CI/CD pipelines.\n\nMonitor with ArgoCD after deploy." click APPROVE "#" "**Team Approval Required**\nProduction deployments require team approval.\nVerify:\n- CI is green\n- Staging tests passed\n- No conflicting deployments in progress\n- Team lead or on-call has approved" click DEPLOY_PROD "#" "**Deploy to Production**\n`just deploy --component SERVICE -e prod -b BUILD_HASH`\n\nFor specific shards:\n`just deploy --component SERVICE -s prod1 -b BUILD_HASH`\n\nAdditional flags:\n- `--dry-run` -- preview without creating PRs\n- `--no-auto-merge` -- require manual merge" click WAIT_APPROVE "#" "**Get Approval**\nRequest approval from team lead or on-call.\nInclude:\n- PR link with CI status\n- Staging test results\n- Summary of changes\n- Risk assessment" click DEPLOY_RESULT "#" "**Deploy Result**\nSuccess: deployment PR created and merged (or auto-merged).\nFailure: check ArgoCD for sync errors.\n\nCommon issues:\n- ArgoCD sync failures (often need pruning)\n- Conflicting deployments\n- Resource limits exceeded" click DEPLOY_DIAG "#" "**Check ArgoCD for Errors**\n`just argo app get SERVICE-ENVIRONMENT`\n\nLook for:\n- Sync status and health\n- Failed resources\n- Out-of-sync manifests\n- Pruning needed" click DEPLOY_FIX "#" "**Fix Type**\nDetermine if the deploy failure is:\n- **Sync issue:** ArgoCD needs sync/prune\n- **Code issue:** actual code problem, needs rebuild" click ARGO_SYNC "#" "**ArgoCD Sync/Prune**\nForce sync with pruning:\n`just argo app sync SERVICE-ENVIRONMENT --prune`\n\nMost stuck auto-deploys are caused by lack of pruning.\nCheck vsuiteweb/ArgoCD/auto-deploy if issues persist." click MONITOR_START "#" "**Start Monitoring**\nAfter successful deploy, monitor the rollout.\nUse both ArgoCD and vdog in parallel to track progress." click ARGO_STATUS "#" "**ArgoCD App Status**\nCheck deployment health:\n`just argo app get SERVICE-ENVIRONMENT`\n\nWatch progress:\n`just argo app wait SERVICE-ENVIRONMENT`\n\nView history:\n`just argo app history SERVICE-ENVIRONMENT`" click VDOG "#" "**vdog Pod Versions**\nTrack running pods by version during rollout:\n`vdog metrics query 'sum:kubernetes.pods.running{env:ENV,service:SERVICE*} by {version}' --from 5m`\n\nThe version tag shows the git commit SHA.\nUse to verify new version rolling out and old version scaling down." click ROLLOUT "#" "**Rollout Complete?**\nComplete: all pods running new version, old version scaled to zero.\nStuck: mixed versions not converging -- wait and re-check.\nFailing: pods crashing or health checks failing -- rollback." click DONE "#" "**Deploy Complete**\nService is live on the target environment.\nAll pods running the expected version.\n\nNext steps:\n- Monitor Datadog for error spikes\n- Check service health endpoints\n- Verify key functionality" click ARGO_WAIT "#" "**Wait and Re-check**\nRollout in progress but not yet complete.\nRe-check in 1-2 minutes.\n\nUse `just argo app wait SERVICE-ENVIRONMENT` for blocking wait." click ROLLBACK "#" "**Rollback via ArgoCD**\nPods are failing after deploy.\nRollback to previous known-good version.\n\nInvestigate root cause, fix, and re-enter the build phase." click CI_START "#" "**CI Trigger**\nAlternate entry for automated CI/CD pipelines.\nAll commands use `-m text` for parseable output.\nNo TUI rendering, no interactive prompts." click CI_BUILD "#" "**CI Build (Text Mode)**\nBuild in text mode for parseable output:\n`just build -c SERVICE -m text`\n\nCapture output to log file:\n`just build -c SERVICE -m text > build.log`\n\nDefault mode uses remote CREW when available." click CI_HASH "#" "**Parse Build Hash**\nExtract build hash from text output:\n`grep 'BUILD NUMBER' build.log | awk '{print $NF}'`\n\nValidate hash is non-empty before deploying.\nStore in environment variable for next step." click CI_DEPLOY "#" "**CI Deploy (Text Mode)**\nDeploy using extracted build hash:\n`just deploy --component SERVICE -e staging -b BUILD_HASH -m text`\n\nAlways validate build hash and check exit codes." click CI_DONE "#" "**Pipeline Complete**\nCI/CD pipeline finished.\nBuild artifacts published, deployment triggered.\nMonitor via ArgoCD and vdog." classDef prep fill:#d1ecf1,stroke:#7ec8d8 classDef build fill:#e8daef,stroke:#b07cc6 classDef deploy fill:#dfe6ff,stroke:#5b7bce classDef monitor fill:#fff3cd,stroke:#f0c040 classDef cicd fill:#ffeaa7,stroke:#e0c040 classDef success fill:#d4edda,stroke:#5cb85c classDef error fill:#f8d7da,stroke:#e06070 classDef decision fill:#fff3cd,stroke:#f0c040 class FIND_REPO,PULL,AUTOFIX,AWS_CHECK,LOGIN,READY prep class MODE,CREW,INVOKE,LOCAL,BUILD_RESULT,HASH,BUILD_DIAG build class ENV,DEPLOY_STAGE,APPROVE,DEPLOY_PROD,WAIT_APPROVE,DEPLOY_RESULT,DEPLOY_DIAG,DEPLOY_FIX,ARGO_SYNC deploy class MONITOR_START,ARGO_STATUS,VDOG,ROLLOUT,ARGO_WAIT monitor class CI_START,CI_BUILD,CI_HASH,CI_DEPLOY cicd class DONE,CI_DONE success class ROLLBACK error end style _MAIN_ fill:none,stroke:none,padding:0 _HEADER_ ~~~ _MAIN_