Refer to the page about location of deployed artifacts for environment information.
1. Branch Management
Guidance on branching strategy presents a typical pattern that we can apply to our work. In a nutshell, the feature branches are for work in progress, the non-versioned branches map to a specific deployment environment and the numbered branches for release and hotfix relate to work in progress on shippable and shipped code respectively. Once code is released, the master branch is tagged with the same release number of the corresponding branch.
2. Release Steps
Use the infrastructure pipeline to create and publish all Azure services to the correct resource group
Create/update application settings in the app service
Create/update all key vault values
Create/update the database schema
Create/update all application settings (ie appsettings.<environment>.json) in the solution
Ensure all API permissions needed by the application in the Azure AD app registration have been added
Expose scopes so that other applications can subscribe to them through API permissions. These are the same scopes that are referenced in a client application's app settings for making requests to the service.
Add the application roles so that Azure AD users and groups can be assigned to them. The roles map 1-to-1 with the API scopes that we just exposed.
From the app registration’s Overview settings, navigate to the enterprise application settings and assign Azure AD user groups to a role in the application. Since this is a shared API, there are obviously many more groups to be added. Also notice that 1 entry must be made on a per application role basis.
Deploy the application to the app service using appropriate pipeline
Depending on environment, the app service may need to be set to load the new build of the application by selecting the latest container. In example below, prod is shown and continuous integration is turned off.
