When deploying an app to an environment, the deployment will first deploy appmetadata + authorization policy.xml file to that environment for that app. Then the pipeline will start and can potentially fail. If it fails, the updated appmetadata and policy.xml will be deployed there even though the new app version has not been deployed.
To Reproduce
Steps to reproduce the behavior:
Go to an app
Update appmetadata
Deploy a version
Stop the deployment
The appmetadata in the environment you deployed to will be the updated appmetadata
Cause
Call to platform for storing metadata is sent before pipelines in devops are triggered. There is a single endpoint in Designer to trigger the deploy process.
Resolution
Designer backend should poll devops and wait untill deploy is successful until metadaa is pushed to storage.
Devops notifies the database that the deploy is complete and designer notifies the user.. The app isn't actually ready to use until det metadata is stored in platform, so there is a timing issue we need to consider here.
Expected behavior
The deployed version should have the correct files corresponding to that specific deployed version.
Suggested fix from Eirik and something we have previously discussed:The app should be self-aware and get its own files from a certain commit, create / update the files in Platform solutions.Applicationmetadata.json and policy.xml for a certain commit are files that Storage and Authorization needs and Designer used to upload these however the app should be in charge og handling itself.
This suggestion will give a lot of benefits beyond solving the bug, Designer will be freed from Platform, code in Designer that authenticates towards Platform can be deleted and certificates and secrets and so on can possibly be deleted from Azure. Moved to separate issue
Absolute minimum: Once we receive notification of deploy pipeline failing, we should push the old version of the files to Storage to ensure the metadata files there match the deployed version.
Describe the bug
When deploying an app to an environment, the deployment will first deploy appmetadata + authorization policy.xml file to that environment for that app. Then the pipeline will start and can potentially fail. If it fails, the updated appmetadata and policy.xml will be deployed there even though the new app version has not been deployed.
To Reproduce
Steps to reproduce the behavior:
Cause
Call to platform for storing metadata is sent before pipelines in devops are triggered. There is a single endpoint in Designer to trigger the deploy process.
Resolution
Designer backend should poll devops and wait untill deploy is successful until metadaa is pushed to storage. Devops notifies the database that the deploy is complete and designer notifies the user.. The app isn't actually ready to use until det metadata is stored in platform, so there is a timing issue we need to consider here.
Expected behavior
The deployed version should have the correct files corresponding to that specific deployed version.
Suggested fix from Eirik and something we have previously discussed:The app should be self-aware and get its own files from a certain commit, create / update the files in Platform solutions.Applicationmetadata.json and policy.xml for a certain commit are files that Storage and Authorization needs and Designer used to upload these however the app should be in charge og handling itself.This suggestion will give a lot of benefits beyond solving the bug, Designer will be freed from Platform, code in Designer that authenticates towards Platform can be deleted and certificates and secrets and so on can possibly be deleted from Azure.Moved to separate issue