Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: incremental azd up #4366

Open
weikanglim opened this issue Sep 20, 2024 · 0 comments
Open

proposal: incremental azd up #4366

weikanglim opened this issue Sep 20, 2024 · 0 comments
Assignees
Milestone

Comments

@weikanglim
Copy link
Contributor

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 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants