DefangLabs / DefangLabs/defang

How to avoid rebuilding images between staging and prod?

Open
#948 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

question
Dominant language
Go
Stars
166
Forks
24
Avg merge
10h 8m
Merged PRs (30d)
33

Description

In Defang monorepo we deploy to staging, and if successful we deploy to prod, but the latter deployment does not rebuild any images. We do this to ensure we actually end up using the images that were tested in staging. If we'd rebuild all services, we might have new surprises and the prod could fail even though staging passed.

When using the Defang CLI, there's not obvious way to do this. Deploying twice, defang up --mode staging followed by defang up --mode production --project-name defang-prod would result in two builds. We could overwrite the staging by not specifying --project-name, but this is also not exactly what we'd want, since it replaces the staging deployment.

  • Perhaps we can rely on the image cache to work across different projects? Ie. deploying with --mode production after --mode staging should result in exactly the same image(s).

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing how the Defang CLI handles defang up, project names, modes, and Docker image building or caching. Compare the staging and production commands described in the issue. Done means production can use the images tested in staging without rebuilding them or replacing the staging deployment.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker
Domain
cli, cloud, devops
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.