Welcome to the second part of this topic regarding using the deployment settings file (DSF) in release pipelines in Azure DevOps when deploying Power Platform solutions.
In the first part of this series, I explained why the DSF is relevant in CI/CD scenarios using Azure DevOps and that it can solve the issues with deactivated cloud flows when deploying to downstream environments by pre-populating connection references. I also explained the differences between a connector, a connection and a connection reference, and why understanding these differences is crucial for effective deployment of Power Platform solutions.
In this second blog post, I will explain what actually happens when we are not using the DSF to pre-populate connection references and environment variables and explain what we ultimately aim to achieve with the DSF. In the third and last blog post, I will provide a step-by-step guide on how to actually use the DSF in your Azure DevOps release pipeline.
What happens when not using the deployment settings file in your release pipeline?
To make it easier to describe what happens when deploying through Azure DevOps without using the DSF, I have created an illustration (Illustration 1) that demonstrates and provides a clearer understanding of the challenges.
In the example below, we start with "Solution A", which is an unmanaged solution in the DEV environment. The solution contains two cloud flows and four connection references (CR1, CR2, CR3, and CR4). These connection references are linked to the cloud flows within the solution and to connections within the environment but outside the solution (remember that connections are environment-aware and NOT solution-aware). The connections in this example are for Dataverse, SharePoint, Outlook, and Teams.
In this example, everything works perfectly with the solution's cloud flows in the DEV environment. The cloud flows are turned on, they are connected to the solution's connection references, which are linked to active connections, and the flows execute whenever a trigger is fired.
Now, Solution A is deployed to UAT through Azure DevOps, and suddenly nothing works. The solution's cloud flows are turned off. This happens because the connection references in UAT are trying to find the connections they were originally linked to, but these connections do not exist in UAT. Since they are still tied to the connections in DEV, the connection references in UAT end up being empty and not linked to anything, which is why the arrows from the connection references to the connections in DEV are red. As a result, the cloud flows in UAT are turned off, as they need active, linked connections in the same environment to function properly.
Even if you create the necessary connections or they already exist in the UAT or PROD environment, you still need to ensure that your connection references are correctly linked to these connections. This is exactly what the DSF helps with. By using the DSF, you can automate the process of linking your connection references to the appropriate active connections in the target environment, ensuring that your cloud flows remain active and functional.
What do we want to achieve?
We want to avoid the situation described above, where the connection references in our solution in UAT or PROD are still linked to the connections in our DEV environment. Instead, we want to ensure that when deploying to UAT or PROD, the connection references in the solution, which are linked to the solution's cloud flows, are connected to active connections in the same environment. Exactly what Illustration 2 below demonstrates.
Here, we have an architecture that allows us to confidently deploy managed solutions, as we ensure, through DSF, that the solution's cloud flows do not stop due to connection issues. We have a best-practice architecture, where the environments operate separately, and the solution's connection references in the downstream environments are not linked to the connections in the DEV environment.
Next steps 👉
I hope you enjoyed the second part of this series and that it gave you an understanding of what happens when you do not use the DSF and how essential it is to include it in your release pipeline in Azure DevOps when deploying to your downstream environments.
In the next blog post (part 3), I will provide a step-by-step guide on how to generate the DSF and how to actually use it in your release pipeline in Azure DevOps.
Here is a link: https://www.serhatyildiran.com/why-use-deploymentsettingsfile-part3/
Please add a comment below or reach out to me through LinkedIn if you have any questions. See you in the next blog post 😎
Join the conversation