Deployments Design results in complex Pipelines/workflows which duration is too long

[ezYakaEagle442]

Is your feature request related to a problem? Please describe.
If you create the App from the Portal, you will get a default Production deployment.
In real life most of the customers uses IaC such as TF or Azure Bicep.

Describe the solution you'd like
A clear and concise description of what you want to happen.

When a customer create the App with IaC and then deploys to Staging using ASA GitHub Action (providing all correct parameters including deployment name) it fails with :
Error: Action failed with error: deploymentName cannot be null or undefined.

==> this is because the Staging deployment needs a Production deployment as a pre-req to get the CPU&RAM sizing.
==> from scope wise, GHA doesn't offer feature parity thing with other customer interfaces like portal, CLI and the current scope is mainly on deployment part.

But if you use the GHA to deploy to Production, the first time it will fails saying that a Staging Deployment is required first, resulting in circular dependencies issues.

IMHO, the GHA should support RAM & CPU, this is the only way to get GHA to work. Also the sizing could be eventually different in Prod and Staging.

Describe alternatives you've considered
Then the only solution is to design a much more complex workflow using CLI only.
My GH Workflow sample takes 5 minutes and more than 200 lines of code just to deploy 1 App whereas it would take 1 line and 30s to deploy it to AKS.

The reason why it is complex is that you need to run many CLI commands to check if the deployment does already exist or not, to create it if it does not exist, then verify all other deployments, check if it is already a Staging or a Production one.

WORKAROUND :

1. Use CLI a first-time as a 'pre-flight' running 'az spring app deploy' that would create a default PRODUCTION deployment named 'default' for each App
2. Accept this naming convention and do not rename the default PRODUCTION deployment named 'default' for each App
3. You are then able to use the GHA , this would then shorten the Workflow length & complexity
4. Once the App runs in Production, you can delete the Staging deployment

• pros: that optimizes cost
• cons: but you do not have anymore a Deployment to rollaback to

Other consideration to test , use CLI to create a Staging deployment with a different RAM&CPU sizing compared to Prod :

az spring app deployment create \
--name $DEPLOYMENT_NAME \
--app ${{ env.API_GATEWAY }} \
--service ${{ env.AZURE_SPRING_APPS_SERVICE }} -g ${{ env.RG_APP }} \
--instance-count ${{ env.DEPLOYMENT_INSTANCE_COUNT }} \
--cpu ${{ env.DEPLOYMENT_CPU }} \
--memory ${{ env.DEPLOYMENT_MEMORY }} \
--version ${{ env.DEPLOYMENT_VERSION }} \
--runtime-version ${{ env.DEPLOYMENT_RUNTIME_VERSION }} \
--skip-clone-settings

Additional context

Doc links :

• Blue-green deployment strategies in Azure Spring Apps
• Use Azure Spring Apps CI/CD with GitHub Actions
• other B/G Workflows sample
• ASA Action from GH market place
• https://github.com/dantelmomsft/spring-petclinic-microservices/tree/master/.github/workflows

[julienbourgoin-maif]

Hello,

I agree with this issue title Deployments Design results in complex Pipelines/workflows which duration is too long :)

Here is my actual workflow to deploy new apps and deployments to azure spring apps:

I use Jenkins to automate applications deployments, therefore, I only use azure cli to interact with ASA.
We wan't blue/green deployments, deploy onto the staging deployment and switch it to production if all is ok.

My actual workflow:

I first check if the app exists, and how it is configured with az spring app show.

If the app does not exists:

1. create the app. (unfortunatly, with az cli, a default deployment is created and a demo app is installed. There is no way to tell azure cli to not create the deployment nor give it a custom name)
2. as I wan't deployments to be named blue and green, I delete the default one
3. give app identity role assignments
4. give app needed persistent storages
5. give app needed certificates to the truststore
6. give app a custom domain
7. give app a service binding or a service connector to database
8. create new deployment with good name and params with my jar artifact

If the app already exists:

1. I check if something need to be reconfigured (storage, certificates)
2. I list all the existing deployments and check which one is the production one, I also check if something need to be reconfigured
3. I check if the custom domain already exists, if not, create it
4. I check if the service binding exists, if not, create it
5. I check if the app identity has the required roles assignments, if not, create it
6. create new deployment if there is only one (greenif only blue exists for example) with good params and give him jar artifact. If the two deployments already exists, juste use az spring app deploy command on the staging deployment
7. restart the deployment if it was previously stopped
8. if app starts correctly, switch staging deployment to production
9. eventually stop or delete the old production deployment

Each step in the described workflow corresponds to an azure cli command.
I need to write a lot of groovy code to use the azure cli commands results.
This can take long to play all these steps

Regards

[allxiao]

@yangtony90 is working on the enhancements on the toolings.

[yuwzho]

Talked with Steve, we can update the deploy script logic like this pseudo code. Every function can be done by a single line of CLI command.

# determine which deployment to deploy
if deploy_to_staging:
   deployment_name = retrive_staging_deployment()
else:
   deployment_name = retrive_production_deployment()
if deployment_name:
    deploy()
else:
    # if no deployment found, create a new one, and set it to production if there is no production deployment
    create_and_deploy()
    if !deploy_to_staging:
        set_to_production()