You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In this issue, we suggest that azd up is made to support incremental changes, i.e., azd up is smart enough to detect deltas for both azd provision and azd deploy, skipping all unchanged steps.
A possible end-goal: if everything is unchanged, azd up should return within <1s, or near there.
High-level idea
Assuming we entertain such an idea, broadly speaking, we would have to imagine items along the following lines:
Implement client-side cache for azd provision. While azd provision today stores a server-side cache in the form of deployment state, this is still a 30s minimum operation for cache validation, which wouldn't meet "incremental up" standards. This proposal does not implement provision caching at the resource level (not possible with current Bicep technology).
Implement client-side cache for azd deploy. We will assume that the language-build-tool command invoked by package also supports incremental caching. With this assumption in mind, the work is then to examine and hash the binaries output, or for containers -- a docker image hash, for any deltas compared to what's stored.
Incremental execution treatment for hooks. As a preliminary design consideration, we could consider that hooks are not evaluated if things are unchanged. Assuming such, we would have to perform the cache-check prior to the pre hook and skip both pre and post hooks if the core logic is unexecuted.
Incremental execution treatment for non-azd workflow commands. This would not be in consideration for a preliminary implementation, but one can imagine either a pre-declaration of inputs/outputs in the workflow to speed things up. One could also imagine the idea that azd env values to be used as the source of truth for detecting incremental change, or sandboxing filesystem operations in such a way that would be azd-detectable.
The text was updated successfully, but these errors were encountered:
Proposal
In this issue, we suggest that
azd up
is made to support incremental changes, i.e.,azd up
is smart enough to detect deltas for bothazd provision
andazd deploy
, skipping all unchanged steps.A possible end-goal: if everything is unchanged,
azd up
should return within <1s, or near there.High-level idea
Assuming we entertain such an idea, broadly speaking, we would have to imagine items along the following lines:
azd provision
. Whileazd provision
today stores a server-side cache in the form of deployment state, this is still a 30s minimum operation for cache validation, which wouldn't meet "incrementalup
" standards. This proposal does not implement provision caching at the resource level (not possible with current Bicep technology).azd deploy
. We will assume that the language-build-tool command invoked bypackage
also supports incremental caching. With this assumption in mind, the work is then to examine and hash the binaries output, or for containers -- a docker image hash, for any deltas compared to what's stored.azd deploy
, which actually callsazd deploy <service>
in a loop, would also benefit from this caching, and addresses [Issue] Runningazd deploy
within an .NET Aspire app deploy all the services #4133.hooks
. As a preliminary design consideration, we could consider thathooks
are not evaluated if things are unchanged. Assuming such, we would have to perform the cache-check prior to thepre
hook and skip bothpre
andpost
hooks if the core logic is unexecuted.env
values to be used as the source of truth for detecting incremental change, or sandboxing filesystem operations in such a way that would be azd-detectable.The text was updated successfully, but these errors were encountered: