Currently in Azure we have our live API server running on an Azure Web App Service (serverless Python runtime type of thing), deployed automatically upon a new Release tag created in the dGC server repository. This is rcpch-dgc-server-live
I think it would be worth creating a second Web App Service called something like rcpch-dgc-server-staging which deploys from the staging branch, and we could then mount this to the APIM at a testing URL. This would enable us to properly soak-test any new changes to the API in terms of testing, deployment, python versions, and the interplay with the Azure Python runtime. Only when we're happy do we then move that code into live and make a Release.
URL scheme comes mostly from config in the APIM. Currently the baseUrl is https://api.rcpch.ac.uk/growth/v1.
Options for scheme could be
use a different subdomain eg https://api-staging.rcpch.ac.uk/growth/v1 (feels like it's elegant and would work for all APIs
use a different path suffix eg https://api.rcpch.ac.uk/growth-staging/v1 (easy to do, less elegant)
use a different version suffix eg https://api.rcpch.ac.uk/growth/staging (I quite like this option)
This pattern could then be repeated across other APIs, as necessary, so we would have a live server and a staging server, with a regular naming scheme for the Azure resources, and a regular URL scheme for how they are mounted to the APIM.
pacharanero
commented
7 months ago
Currently in Azure we have our live API server running on an Azure Web App Service (serverless Python runtime type of thing), deployed automatically upon a new Release tag created in the dGC server repository. This is rcpch-dgc-server-live
That is configured as a backend for the Azure API Management Platform (APIM)
I think it would be worth creating a second Web App Service called something like
rcpch-dgc-server-stagingwhich deploys from thestagingbranch, and we could then mount this to the APIM at a testing URL. This would enable us to properly soak-test any new changes to the API in terms of testing, deployment, python versions, and the interplay with the Azure Python runtime. Only when we're happy do we then move that code intoliveand make a Release.URL scheme comes mostly from config in the APIM. Currently the baseUrl is
https://api.rcpch.ac.uk/growth/v1. Options for scheme could behttps://api-staging.rcpch.ac.uk/growth/v1(feels like it's elegant and would work for all APIshttps://api.rcpch.ac.uk/growth-staging/v1(easy to do, less elegant)https://api.rcpch.ac.uk/growth/staging(I quite like this option)This pattern could then be repeated across other APIs, as necessary, so we would have a live server and a staging server, with a regular naming scheme for the Azure resources, and a regular URL scheme for how they are mounted to the APIM.