Open blake-mealey opened 2 years ago
Adding to milestone v1.0.0 because this definitely needs to be figured out before then (this is a pretty major change to the way things work)
Thinking more about this and I realized a more conceptual understanding of this is to split up creation of resources with updates of resources. One complication with this is resources which are re-created when updated. We may need to make this a known concept for the reconciler so that it can correctly split tasks between phases.
Also: reference the Azure DevOps CLI for example of how we could structure this. IIRC, there are separate phases like "init", "provision", and "deploy". Each phase has its own command, or you can simply run the "up" command to run all three. "init" isn't really applicable for us, but the others are.
In order to enable projects to use the IDs from the outputs command in their Rojo bundles before deploying, we could split out place deployments into a separate command. The workflow would then look something like:
What does this mean in terms of implementation? Do we create two resource graphs in each environment – one for prepare and one for deploy – and have the deploy graph depend on the deploy graph? This would be the second use case for having multiple graphs which can depend upon each other (see #63) so it seems like it would be a good idea to refactor this the resource graphs to support this.
I want to make sure I properly understand what is different between the prepare and deploy stages sufficiently here. Are there other operations that should be moved from prepare to deploy?
Also, does this affect the configuration format? Should deploy-related objects be defined separately from the prepare-related objects?
I titled this issue with "consider" because I'm still torn on this, but atm it seems like the right path forward.