DefangLabs
Local dev vs Defang (Prod) Configurations
We need to document the best way to run different configurations in development and production. Even things like environment variables etc. Sometimes you want to add a NODE_ENV=development in dev andNODE_ENV=production in prod. We can tell people to do something like:
defang compose up -f compose.yml -f compose.defang.yml
But that's pretty annoying.
I think it would be nice if the defang CLI looked for a *compose.defang.y*ml file by default, and if it exists, use it to override values in the main compose file.
It's not a full development workflow, but I think it's a decent starting point.
We added support for Compose "profile" and always have profile=defang set.
compose.defang.yml looks a lot like the compose.override.yml which Docker always loads automatically.
While discussing this in the office today, @lionello pointed out that local vs remote is not the same as development vs production. We want to be able to manage our configuration on all of these different axes.
I think multiple compose files are going to be necessary. Some of our samples are starting to use a pattern where the sort of remote production configuration is described in the default compose.yaml file, and a local development configuration is described in a compose.dev.yaml file which extends the default configuration, making overrides as necessary. I think this is a nice pattern as it keeps things simple for the fast demo case of writing a compose file and shipping it, but it leaves open additional space for further configuration as needs get more complex.
@raphaeltm pointed out https://github.com/DefangLabs/defang-mvp/issues/435 which describes introducing a defang dev command. I like the idea of introducing a defang local command (and maybe one day we could introduce defang remote to do development on a remote deployment). Maybe we should also have a compose.local.yaml file instead of compose.dev.yaml to stay consistent. We could use defang local to shell out to docker with something like docker compose -f compose.local.yaml, and it could even create one if it doesn't exist.
