Azure is well-suited to publicly releasing developer-oriented artifacts like NuGet packages. And it's great at deploying Web-Apps and things intended for VMs. Plenty of release templates for those. But I can't find much discussion on deploying a simple standard Windows desktop application installer. Does such a facility exist?
Because our pipelines produce two main artifacts we give to customers:
a NuGet packaged SDK for developers
an installer for a standard old Windows Desktop application for end users
Getting #1 out there is easy. But what do I do about #2?
I'm not sure what I was expecting. Maybe something like an Azure-provided publicly-facing page with a list of installer builds I had released. Something my pipeline could feed into directly. Maybe even some provision to require people to enter contact information to download the installer, or a customer-specific URL that would record for us who had downloaded it.
Does this sort of Azure facility exist? Or is this a case where we should just expose a downloads page directly from our own company website?
Is there an Azure Pipeline facility for releasing a standard Desktop Application?
I am afraid there is no such specific Azure Pipeline facility for releasing a standard Desktop Application.
When we release a standard Desktop Application, we could use the copy task or publish build artifact task to deploy standard Desktop Application build artifact, to a network drive folder or target machine directly.
You could check this document and my previous thread for some details.
So,there is no such specific Azure Pipeline facility for standard Desktop Application.
If you really want to use artifacts to manage standard Desktop Application, you could try to use the Universal Package, which store one or more files together in a single unit that has a name and version. we could also publish Universal Packages and download it.
Related
Forgive me for asking a stupid question. I am from IT Infrastructure background & have been asked to create CI/CD pipelines based on my recent learnings on DevOps.
We have couple of applications whose source code is currently in TFS 2013 & those apps are written in ASP.NET C# language. Now, requirement is to migrate the source code from TFS to Azure Repos (Azure DevOps services) & further create a CI/CD pipeline.
Now for demo purposes, customer is asking us to do the deployment (i.e. Release pipeline) on a test server which is a plain windows 2012 OS without any SQL & IIS for both of these applications. Is that possible & how could we achieve the results to confirm release pipeline is funcioning properly?
In my opinion, it wont work as there is no application infra/configuration done for those applications on that plain test server. I guess we actually need a ready dev/stage environment which is replica of production to do the testing of release pipeline for those applications. Am I correct?
Just need expert advise for confirmation so I communicate the same to customer.
Azure DevOps Pipelines use an agent to perform the deployments. You can run the agent entirely in the cloud when deploying to Azure resources. You can also install an agent locally. Follow this link and scroll down to read about self-hosted agents. This is how you can deploy to your test instance from the pipeline.
Now, what you deploy there may require additional software be installed. You say it's an application in C#. Cool. Now, what's it do? Is it a windows program? Then just having the server there, with an agent installed, is all you need. Is it a web program? Then, yeah, it's going to need an IIS (or whatever) instance available somewhere to deploy to. Is it a database program? Then, yeah, it's going to need a database instance to deploy to. There's nothing magical about having a VM or a machine somewhere. All the same rules have to apply. There has to be an OS, drives, memory, and yes, supporting services depending on the needs of the application.
However, using a local machine instead of a hosted one, that works fine. Just follow the instructions in the link above.
I am doing some research for Powerapps integration with Azure DevOps.
However there is limitated information for it.
It is possible to integrate powerapps inside a Task for AzureDevops?
Based on, that we have a .zip file with the Powerapp, and we want to create a Build and Release/Deploy for several environments.
Thank You.
It is possible to integrate powerapps inside a Task for AzureDevops?
Yes it is.
You can leverage the Solution concept of the Microsoft Power Platform and the Power Apps BuildTools (preview) extension for Azure DevOps.
Update 11/2020: This is now GA and called Power Platform Build Tools
I've written a complete step-by-step guide on this topic:
A Continuous Delivery Approach for No-Code Solutions in Microsoft’s Power Platform
Bottom line:
With this build tool, you can automatically check-in a Solution into source control and deploy it using a continuous delivery approach with the help of Azure DevOps. See the screenshot for a sample configuration of the Export and Import Solution Task.
It works for everything you can organize inside a Solution, e.g.:
Power Apps
Power Automate Flows
AI Builder Models
Common Data Service Entities
It is possible to integrate powerapps inside a Task for AzureDevops?
I am afraid there is no such Task integrate powerapps for AzureDevops at this moment.
If you want to integrate powerapps with azure devops, you can follow the guide step by step:
Microsoft Teams – Integration with Visual Studio Team Services using PowerApps.
Besides, AFAIK, PowerApps should not be "Build/Deployed" through Azure Devops.
When you are developing with PowerApps, there is no way to do Source
Control. There are no source files. The only artifact you can version
control is the .zip file that you can export.
And
In PowerApps, you don’t have to build your code. Any change you make
to the application is live for you to test it. In that way it is very
productive. To publish the application you just click on the publish
button and it is live.
Check this great blog: PowerApps From A DevOps Perspective for some more details.
Hope this helps.
Solutions are a way to package your components in a single zip file and use Powerapps build tools to import your solution on to a different environment or tenant.
It is still a an improvement from manually importing each app or environment variable and then import it on to target system, but it lacks what we call as automation of deployment.
To provide an eg, I will explain what I have done, and what still constitutes of a manual task:
I created an enterprise level app using powerapp canvas model. My app consumes data from around 20 APIs. These API calls are implemented in power automate.
We have 4 environments, dev, sit, uat and prod. Now I cant keep on importing flows in each environment and change their api URLs to point to the deployed environment. So I used environment variables for each environment which stores api URLs for each environment. This can be done under solution.
Under the same solution, I added my app. So now my solution has 2 things, my app and the environment variable which consists of api URLs.
I then use powerapps build tools to move this solution from dev to sit.
Steps: use build tools tasks to perform the following
Export solution
Unpack it in git
Pack it
Import the solution.
This successfully moves my solution to sit.
But the solution environment variable still points to the dev url.
So I have to override environment variables to store sit URLs.
This manual intervention to edit environment variable is as good as doing all the tasks manually.
This was the case when PowerApps was first announced; however, this is no longer the case.
While it is technically true that there is no actual code that would be managed and deployed with a PowerApp or Flow but that doesn't mean that you can not use the power of Azure DevOps. Additionally, when creating a PowerApp / flow you would also be creating entities and even Model Driven apps - and these uses solutions - which naturally work well to deplooy within Azure DevOps.
Microsoft is building out this whole construct to enable all these to deploy...
While the whole incorporation of PowerApps and flows into Solutions is not fully baked yet - they are targeting to have this ready around the October time frame this year.
We have been talking to Microsoft about also enabling PowerApps and flows to follow the same expansion that solutions do so that they can take advantage of the full branching strategy.
So even though you would be simply exporting out zip files into your repo - you can still take advantage of the full devops pipeline which is highly recommended.
Use this component, it still on preview mode but is working fine on my side
https://marketplace.visualstudio.com/items?itemName=microsoft-IsvExpTools.PowerApps-BuildTools
I am using Desktop Bridge with a c# Winforms application to make a package to publish to the store.
If I make my package locally using Desktop Bridge then I can upload it to the windows store successfully.
I am also now able to build and create the package artifact using a pipeline and I can see it in the Artifacts explorer.
I am having trouble following the docs on how to get the package into the store.
It mentions
ps
$(Build.ArtifactStagingDirectory)\
AppxPackages\MyUWPApp__$(AppxVersion)_x86_x64_ARM_bundle.appxupload
Does ps mean powershell?
How do I get the YAML?
Or am I meant to build a release pipeline?
I tried looking at the release tasks but could not find anything that mentioned the Store.
This is a great article on how to build your package and deploy it to Hockey App (now App Center) but can be used to deploy to the store as well. I'm not sure exactly how you would convert it to YAML, but it shouldn't be too difficult.
https://mobilefirstcloudfirst.net/2016/02/continuous-deployment-of-windows-10-uwp-apps-to-hockeyapp-using-vsts/
Once you have the package built following the instructions in the article (It sound's like you already have), skip the Hockey App steps and instead publish to the store with this Azure DevOps extension task step: https://marketplace.visualstudio.com/items?itemName=MS-RDX-MRO.windows-store-publish
Instructions to use the extension are on the extensions web page. You'll have to have an Azure Active Directory account. If you don't have one, it's easy to set up and it's free!
To answer your questions
Does ps mean powershell? - I just browsed down through the article and I don't think so. Usually it's saying you need to give this value in a property in the build step.
YAML is pretty new, and there is not, as far as I know, an easy way to convert it to YAML.
You'll probably want to do this in two steps: 1) Build the package and upload the artifact. 2) Download and release the package. Step 1 should be done in a build, step 2 should be done in a release. I find splitting these steps into two very helpful when only the release fails. Then I don't have to rebuild the package to try again, I can just redeploy the release.
I'm trying to use TFS 2015.1 on premise to build a CI pipeline for our dev & uat. I've created a vNext CI build, which builds fine. But when I want to add a deploy step for on prem IIS server, I only then see Azure Web Deployment options.
Ideally I wanted to add a step which uses the existing deploy (MS Deploy) profiles, which I'm able to use from VS2015 directly, using 'Publish'. However I see no option to do so.
How can I deploy the latest build to internal dev servers (not Azure)? I would like to use the MS Deploy option, unless there's a better way of doing it?
The fact that their is no option to starts to make me think there's probably a different way to accomplish it!
Thanks.
If you're able to upgrade to TFS 2015.2, web-based Release Management came out with it that works similarly to Build vNext with flexible and open-source tasks. You can also customize tasks.
Here's a link for IIS Web App Deployment from the vso-agent-task's GitHub repo where Microsoft stores updated versions of their tasks that you can download for web-based Build and Release Management.
I'll be publishing a blog about web-based RM with TFS 2015 Update 2 or VSTS on my website in the next few weeks. To give you an idea though, the starting point (for a web application) is a folder in your web project called WebDeploy (no significance - any name will do) that contains a PowerShell DSC script that configures the server, deploys the web files and then replaces any tokenised configs. To give you an idea see this post about how to use DSC to configure servers. (Only covers part of the final script though!) The next steps are:
In the build hub create a Website artifact - containing your web files and DSC script.
In the release hub for an environment use a Windows Machine File Copy task to deploy the artifact to a temp folder on the target node.
Then use a PowerShell on Target Machines task to execute the DSC script. After configuring the server the script copies the web files to their proper location, sorts out config using xReleaseManagement and cleans up the WebDeploy folder.
See this article for general details of the route I'm taking, but watch out as it has some errors eg the firewall instructions are incomplete (file and print sharing through the firewall needs to be enabled).
I can thoroughly recommend the PowerShell DSC route - I've had a few glitches but on the whole it feels very productive and the right way to be going.
I am running a mobile service with an increasing amount of scripted functionality. I want to have these scripts somehow stored in a smart format for version control. I'm having hard time finding any information on such scenarios. Is it even possible Azure -> VS2012 (and TFS) or VS2012 (and TFS) -> Azure?
Currently that is not supported on the portal itself. You can do that by using the Command Line Interface, however, as was shown in this blog post. Basically, you can store the scripts in whichever source control system you want (the post uses Git, but it would work with TFS as well) and use the CLI to update your service whenever a new version of the script is checked in.
You can also vote up the source control feature suggestion on the UserVoice for the system, to have that functionality implemented in the service itself.
You can now link your Azure Mobile scripts to a git repo directly from the Azure Mobile Portal Dashboard, allowing you to edit scripts from VS2012 or another editor.