I have several Power Platform components, such as a Power App and some Power Automate flows that are part of a larger application. This application also consists of a Python package, a SQL database and so on.
I am trying to deploy this application on a client's environment. Now, in terms of the Python package and SQL database, for instance, this would mean deploying it into their Azure subscription or tenant.
How would this work for the Power Platform components? How can I deploy it on their subscription?
Note: I am not sure if subscription is the correct term to use here. As far as I know, Power Platform is not a part of Azure, but it comes under an O365 or D365 subscription?
I know Power Apps and flows can be exported and imported into other environments/subscriptions. But, is there some way I can maybe set up a CI/CD solution in order to achieve this? Maybe using Azure DevOps?
I have come across this, but from what I understand, I believe this is about deploying these components in different environments within the same subscription?,
https://learn.microsoft.com/en-us/azure/architecture/solution-ideas/articles/azure-devops-continuous-integration-for-power-platform
When you use Azure as part of you Power Platform solution, the right term is "tenant". 1 tenant can have multiple power platform environments and azure subscriptions.
https://learn.microsoft.com/en-us/power-platform/admin/environments-overview#environment-scope
Devops for Power Platform is simpler. Best way to authenticate is using service principal:
https://learn.microsoft.com/en-us/power-platform/alm/devops-build-tools#connection-to-environments
The Azure part is more complicated. if you want to fully automate you will need to write some infrastructure as code to create resources like an azure function or a database and after that the pipeline to deploy the code to those resources.
Related
Apologies if this is a silly question but for the last 2 hrs. I have been reading about the difference between built-in and managed connectors for Azure logic apps and it's driving me crazy. Can someone please explain in simpler language? Initially, I thought built-in connectors are for Azure services like Azure function or table storage whereas managed are for Microsoft services like O365 & Sharepoint, but after going through the list of connectors on Microsoft documentation, its not true.
Is this tenant based? For example, built-in connector will only allow connecting to azure services in that tenant but if we need to connect to an Azure service in a different tenant, we need managed connector. Even if this is true, how can something like SMTP be an inbuilt connector?
Is the difference on the basis of authentication? The mechanism to authenticate is different for built-in / managed
I think there are some differences between the two under the hood regarding how they are hosted, but I don't know how much difference that makes for you as a user. You can read a bit more here.
However, the main difference that I have noticed and that makes me prefer the built-in connectors (when applicable) is how you can set up the authentication. Especially when trying to set up CI-CD for Logic Apps (and devloping locally in VS Code) this makes a big difference. For the managed connectors, a managed api connection is created in the portal and it's a nightmare trying to parameterize that when developing in VS Code and incorporating that to Devops-pipelines.
Built-in connectors run in the same platform where your logic apps is hosted whereas Managed connectors are hosted in public cloud. When you use built-in connectors the information configured for the connector will not be sent to public cloud for processing it will run natively in your Logic Apps. This makes it more secured. There are many differences for example authentication method, api connection file, and many more.
We have a bunch of Windows Services. We need to be able to continue to deploy our code as Windows service on premise, but would like to deploy to Azure where appropriate. The goal is to manage less infrastructure. I'm not keen on deploying dozens of bits an pieces as Azure Functions, but not entirely opposed to it either. Azure Batch / Webjobs are also another option. However, the long term goal is to move all of our services over to an orchestration server like Service Fabric so that all the services can be deployed and orchestrated from the one place. This is mainly a deployment consideration.
We will break the existing C# code in to .NET Core class libraries and reference them from either Service Fabric hosted in Azure, on-premise Service Fabric, or on-premise Windows Service. Is Service Fabric an appropriate choice? Or, is there a strong reason to run background jobs as Azure Batch / Functions / Webjobs?
This is Microsoft's diagram from here:
The answer to the question is that we don't really need full fledged orchestration right now, but it will become more important moving in to future. I have to balance being able to deploy all our code in one hit with the ease of ad hoc deployment that Azure Functions offer.
(Stateful) Services can be an excellent way to run background jobs. They offer the RunAsync entry point, in which you can run your job, check (and store) progress. SF really shines when multiple services collaborate on tasks, offering SF Remoting as a communication channel, with built-in retry support.
You can choose to containerize your software, which would free you from platform lock-in, but prevent you from using some platform features.
By automating delivery of services (CI/CD), you can deploy to any platform you choose. This is not something that is specific to SF.
I am using azure Standard service plan and developing Logic Apps Work flows. Now i want to deploy it to different environment like QA/UAT.
I have referred few MSDN blogs and found out We can do the logic apps deployment to different subscriptions via Visual studio with Azure SDK. However I am using API Apps in the logic apps work flows like SQL connector, Transformation service, BizTalk Xpath Extractor etc..
Can you please let me know how do we deploy API Apps to different Environment. Please suggest.
Thanks,
Vinoth
One way is to create the logic app with the connectors you want and then export that ARM template LogicApp -> Settings -> Export Template. Of course this template might not be the ideal approach since it will have lot of stuff hard coded specific to that LA.
The good approach will be to create a new Azure resource Group project which has
the logic app ARM template,
just copy the defn part from you existing logic apps int the template definition section
make sure you have the connection resources creation added as part of you template.
Some useful resources
1. Checkout this MSDN link.
2. There is a utility also to get the LA templates, read this
Is it possible, using the Azure portal or some other means, to export the subscriptions configuration, for example as an XML file?
I mean things like details of web sites / roles, virtual machines, the size of the machines etc?
Then I could export every day and use a diff tool to check nothing has changed by mistake....
Just thought I'd ask before I write a giant PowerShell script.
I agree this would be a nice feature to have. It's often easier to build out the environment via the portal, but copying that from one tenant (dev) to another (prod) would be much faster and easier if it could be exported to JSON or XML and processed via PowerShell.
Azure Resource manager however does not support resources like Cloud Services, API Management, Mobile Services, Azure Scheduler, Azure Automation, Azure Active Directory, Recovery Services, Media Services, etc. ...
So the summary is - No, there is no such service yet to help you export all your subscriptions configurations.
If you just look for Virtual Machines and Web Sites, then Azure Resource Manager may be in help. But if you look for a complete backup - there is no way to easily achieve this today (2015-03-17).
Probably you could write some Powershell script combining the power of Azure Service Management + Azure Resource Manager, but frankly I am not really sure whether that would also help.
I created my custom Azure Worker Role. This code is ready. What I'm trying to do is to create instances of this Azure-Worker-Role in specific Azure data-center, at the requested time. For example, I'm want to send command to Azure to create 10 instances of my Custom-Azure-Worker in West-Europe data-center - now.
It's important to pass this command also a parameter that will be the input problem to be solved by my workers.
I pretty sure that this automation task must be covered by Azure automation. Is that true? Looking for more information\directions.
Thank you!
You can use Azure Management Libraries to create and deploy your cloud services from C# code. Just create application (eg ASP.NET MVC) to manage your cloud services by sending commands and deploy it also on Azure or even keep it locally.
See this article for more details http://www.bradygaster.com/post/getting-started-with-the-windows-azure-management-libraries
You'll want to leverage the service management API to spin up and tear down roles. It can be accessed any number of way, including directly via REST.
RE: providing a parameter to the worker role, one option is leveraging the cloud service configuration file that you provide with the cspkg. Define specifics for the role there.
Depending on the complexity or simplicity of your scenario, you may also get away with simply having a table in storage that you personally poke with desired configuration values and that the worker can read to retrieve.
The Azure Automation service should definitely be able to automate this task for you. Anything you can script via the Azure PowerShell module, can be imported as a runbook and called manually, via a third-party system, or on a schedule in Azure Automation.
Whether there is an existing runbook for the specific task you are looking to automate, I do not know. But Azure Automation has a gallery of community-contributed content for many common processes, so this may be available there.