Implement deployment state caching for `aspire deploy`

[captainsafia]

Currently, the aspire deploy command requires users to re-enter deployment configuration on each deployment and regenerates secrets/passwords, leading to:

1. Configuration fatigue: Repeated prompts for subscription, resource group, and location
2. Inconsistent secrets: Generated passwords change between deployments, breaking data persistence
3. Developer friction: Extra steps that slow down iterative development workflows

Scenario 1: Deployment Configuration Re-prompting

When using aspire deploy, users are repeatedly prompted for:

• Azure Subscription ID
• Resource Group name
• Azure Location/Region

This information should be cached after the first deployment to the same environment.

Scenario 2: Generated Value Regeneration

Resources that generate passwords/secrets (like Redis with WithAccessKeyAuthentication()) create new values on each deployment:

var redis = builder.AddAzureRedis("cache")
                   .WithAccessKeyAuthentication();

This causes:

• Loss of cached data in Redis instances
• Connection string mismatches in dependent services
• Need to manually set persistent passwords via user secrets

Scenario 3: ParameterResource Re-prompting

The implementation will also reprompt for any ParameterResource instances that are referenced in the AppHost, which introduces additional friction:

var apiKey = builder.AddParameter("api-key", secret: true);
var storageAccount = builder.AddParameter("storage-account-name");

Users must re-enter these parameter values on every deployment, even when the values haven't changed.

Implementation Notes

When evaluating solutions we should consider that:

• The deployment state should be queryable from the AppHost so that custom deployment implementations can query it.
• azd has an existing mechanism for managing deployment state. We should consider interoping whether or not we ewant to interop with it.
• Deployment state should be scoped to a certain environment/scope. We'll need to figure out how users define the environment/scope that a given deployment is associated with.

[captainsafia]

Some notes from playing around with a prototype that hooks into the UserSecrets-based approach that we use for storing state in RunMode. High-level details:

• Secrets are scoped in the config depending on whether publish/run mode is used. The schema used for the keys is as follows. EnvironmentName is the name of the AzureEnvironmentResource in this case which is a stable hash generated from the AppHost.
  • RunMode: Azure:* (as before)
  • PublishMode: Aspire:Deployments:{EnvironmentName}:*
• Changes need to be made to ProvisioningContext, BicepProvisioner, and ParameterProcessor to support saving all the reuired values to user-secrets.
• AzureDeployingContext is updated to use the same BicepProvisioner.ConfigureResourceAsync/BicepProvisioner.GetOrCreateResource flow to avoid redeploying resources that haven't changed.

Some gotchas to consider:

• The UserSecrets/IConfiguration APIs don't scale nicely to having to have multiple scoped secret. We definitely need to come up with a nicer deployment state API here.
• There's some tension between values that are read into IConfiguration by other parts of Aspire, like Parameters, and scoped values that get saved during deployment. We'll need to refactor anywhere that state is loaded to go through the DeploymentState APIs.

Most of the state that we are trying to save here exists in app model already and we're talking about how it gets saved. Maybe the right API here is something that allows us to mark a Resource as IResourceWithDeploymentState where the interface captures some logic around what values get saved to which kind of store... 🤔

[captainsafia]

Some more notes on this after prototyping around with modeling a DeploymentStateManager around IConfiguration. Probably the most annoying aspect of this is that reads/writes are split up when interacting with IConfiguration. Reads happen via the standard APIs but any writes that we do have to be managed independently so you end up with something like this:

class DeploymentStateManager(IConfiguration forReading, IConfigurationProvider forSettingAndWriting)

The other thing that is kinda awkward about it is the fact that the IConfiguration instance that we currently flown around places like the BicepProvisioner is the composite instance registered on the builder. For this particular API, we want to make sure that both the source is always a single one (user-secrets or file-based) depending on the deployment environment.

IMO, it feels ick to re-use IConfiguration to model what has essentially become at this point application state. We're probably better off modeling this with a completely separate source.

[captainsafia]

Marking this as closed since the bulk of the work is done. Documentation issue is opened at dotnet/docs-aspire#5187.

[antsok]

@captainsafia it would be nice if prompt choices like rg group name were saved either in a session or as an env variable so we don't have to retype them every time when battling through the failed deployment attempts. Thanks.

[captainsafia]

@antsok This is implemented in the Aspre nightlies (but not 9.5). After you provide the provisioning details, we save them to a deployment state file on disk. Are you seeing issues with this?

[antsok]

@antsok This is implemented in the Aspre nightlies (but not 9.5). After you provide the provisioning details, we save them to a deployment state file on disk. Are you seeing issues with this?

@captainsafia I am on 9.5.1+286943594f648310ad076e3dbfc11f4bcc8a3d83

[captainsafia]

@antsok Yep, you'll need to be on the nightlies. Docs on how to use them here.