How can we create a multi-environment workspace in the Azure portal for Azure Data Factory (ADF), Logic Apps, and Azure Functions?

Question

I am interested in establishing development, sandbox, and production environments in Azure. The resources to be utilized include Data Factory, Logic Apps, Storage Account, SQL Server, and Database.

To clarify, I'm not discussing CI/CD and GitHub; my focus is on setting up distinct environments within the Azure portal. Post-environment setup, my intention is to deploy the same code to each of these environments.

Based on my understanding, the recommended approach involves creating separate resource groups for each environment. However, this may lead to duplications in Logic App and Data Factory code.

Could you kindly suggest alternative approaches to fulfill this requirement?

Answer 1

Thanks for clarifying in the comments above, @Sowjanya Mandalapu ! Can I ask why you're opting out of CI/CD?
I would like to establish the following 2 points in alignment with you before the technical steps and aspects are weighed in:

1. Managing multiple environments manually, that is to say, being able to deploy changes to different environments and reverting back between them, is still part of a DevOps practice; whether to incorporate CI/CD flow into that practice is merely a decision of introducing automation to it with a strong upside on reliability and minimal human errors :)
2. When it comes to managing multiple environments for Logic Apps, I would think of Logic Apps as just like any other app (be that as it may a Web app, an API app, or a mobile app) but the focus should remain on the DevOps practice part and whether it effectively gets the #1 done. The fact that it is an Integration tool shouldn't really hold you back from establishing a proper DevOps practice of your own.

With the above in mind, it is OK to deploy the same version of your Logic App per your example:

1. Develop new changes locally, and deploy to Dev RG (resource group)
2. If changes in Dev pass, elevate the changes to the Test by re-deploying to the Test rg.
3. If changes in Test pass, elevate to the Production.

Even though it seems like you're "duplicating the Logic Apps resources" by re-deploying to different RGs, you still have clear isolation between environments that, in reality, will probably carry different changes, which is consistent with the broader DevOps flow. I suspect the core of your question lies exactly here though: how can the changes in lower environments, say Test rg, be elevated to the higher environment like Production without you having to manually re-deploy? In the case of Azure WebApps, for example, they make it look easy with the Blue/Green deployment concept built as deployment slots, but under the hood, deployments slots are duplicate infra resources much like you would have to manually manage for Logic Apps as different RGs. I'm going to pause here for now and await your reply in the comments in case there's a question. If you're in agreement with me thus far, pls let me know if you'll be using the Logic Apps Standard vs Consumption SKU. That way, I'll update this answer with technical details & best practices specific to the type of Logic App you're using.