Question: Inquiry on Deployment Practices and Upgrade Strategies for Version Management

[ravikhunt-kyn]

Hello Team,
I have couple of question as below, if get answer for each that would be a great help, Thanks in advance

• Do you always recommend deploying a new version as a fresh deployment?

• Do you always test with upgrade versions from old code (V1.1.1) to the new code (latest release: V1.2) and identify any issues, such as conflicts at the infrastructure level (e.g., functions, web apps, storage accounts, Cosmos DB, etc.)?

• Is it always the best practice to deploy the new version in a fresh resource group?

• How do you handle migrating existing data when deploying a fresh version in a new resource group to ensure there is no data loss?

[lon-tierney]

Great questions.

Do you always recommend deploying a new version as a fresh deployment?
Yes. Try the new version and see if it is compelling for you to move to before you adopt.

Do you always test with upgrade versions from old code (V1.1.1) to the new code (latest release: V1.2) and identify any issues, such as conflicts at the infrastructure level (e.g., functions, web apps, storage accounts, Cosmos DB, etc.)?
Yes, but we don't guarantee upgrade. Remember that this is an accelerator and not a product.

Is it always the best practice to deploy the new version in a fresh resource group?
I personally do to keep resources separate. Once my new version is up and running, I delete the old resource group.

How do you handle migrating existing data when deploying a fresh version in a new resource group to ensure there is no data loss?
We don't currently solve for data migration. We will tell you when a version change requires data reprocessing (such as when we add a new index field). I'll repeat again that this is an accelerator. When you make your own version of this accelerator (make your own product from it), I'd suggest that you set up proper CI/CD pipelines and test your scenarios, including migration if necessary. As a general rule, 'upgrade in place' is always very risky, and for a production service you should always devise and test a rollback scenario before attempting.

[edoublec]

How do you manage environments? I would assume you would still want a dev stage prod if you are considering this for production for best practice. Even as an accelerator i would think you have multiple environments. Where they cloned? Branches? Whole new repos? etc.