I've been trying to automate updating the runtime version of already existing Azure App Services. Currently I have around 20 running App Services (Windows), each on the same runtime stack (let's say .NET 5). I would like to manage versions and upgrade to .NET 6 (and later to .NET 7 etc.) with minimum manual work required. The current flow of the process looks like that:
Code is being merged with master in Pull Request;
Build Pipeline is triggered, runs project with tests, publishes artifact with the newest build (I've already updated it to use .NET 6, my project is configured for .NET 6 as well).
Release Pipeline is triggered, because new Artifact is published;
This pipeline has 20 stages, one for each app service - it deploys the code artifact using Azure App Service deploy task.
I would like to update all these app services without me going into azure portal -> app service configuration and changing the runtime manually. I don't really know what is the best place to put "something" that updates the runtime automatically/after changing some single parameter by myself to indicate that it should now update all these App Services to .NET 6.
What I've considered:
Run some inline azure cli script at the beginning of Release Pipeline (I believe there is an agent task for it) that updates the runtime stack of each app service to desired version - but I haven't found a way to achieve it via Azure Cli (the azure cli equivalent of going to azure portal -> app service config -> changing runtime). Did I miss something? Is it the right approach?
Make some Powershell Script that gets invoked somewhere in the flow that bumps runtime to desired version provided in parameter;
I've considered that there possibly is some nicer way to control the runtime version of already running App Services, but I cannot find any.
Could you guys guide me towards the correct approach? Thanks in advance, if any additional info is required I will, of course, provide it.
Related
I did create a single file application with C#. I have this executable located in a repository and I push it as an artifact. The former is used in build pipelines where I simply add the repo so I can use it. The latter is to use it as an artifact for a release pipeline.
Now during a build pipeline I can simply use it, have tested it and it works. Not really important but the application does 2 things, it sends out mails and updates work items.
When using that exact same application in a release pipeline I get the following error:
Failure extracting contents of the application bundle.
I/O failure when writing extracted files.
I don't know for sure, but could this have something to do with the release pipeline's agent running in a containerized environment? The reason I am asking so is because someone else had such an issue while using this approach on AWS with containers, see this Reddit link
[UPDATE]
The release pipeline was running on a self-hosted Azure DevOps agent. The environment where it is installed on has no .NET 5 runtime nor SDK installed. But I expect the single file application to contain the runtime as well, or am I wrong?
I did publish my application as a simple folder publish. Then putting all the files within the publish folder in the Azure DevOps repository.
Next I pushed all those files as an artifact with a build pipeline, had to install the .NET 5 current runtime on the environment as the release pipeline is running on a self-hosted agent, and then I am able to run the application.
I have created a new Blazor WebAssembly project and made it ASP.NET Core hosted (so, Visual Studio created three projects, one for the server, the actual WebAssembly client project, as well as a class library holding types used by both apps). Then, I just followed the documentation at https://github.com/ElectronNET/Electron.NET to electronize the server app. In theory, everything should be fine.
Problems occur when I try to run the app via electronize start. The build fails with the following error.
...Microsoft.NET.ILLink.targets(143,5): error NETSDK1102: Optimizing assemblies for size is not supported for the select
ed publish configuration. Please ensure that you are publishing a self-contained app. ...
Error occurred during dotnet publish: 1
Of course, I can imagine what the actual problem is. The Electron build tries to publish the assemblies for the current target platform, which is x64 in my case, but this is not supported for blazor-wasm projects. What I basically want to achieve is that the client build output gets included with the electronized server app.
Update
The following command successfully builds the electronized app, if the PublishSingleFile and PublishReadyToRun properties are set to false. Though, this is far from optimal since it creates an app that comes with a performance penalty (increased load time).
electronize build /target win /PublishSingleFile false /PublishReadyToRun false
Sadly, the switches currently do not work with the electronize start command.
How would I go about releasing or deploying (do those mean the same thing?) my WPF application (.Net Framework 4.7.2) through Azure Pipelines?
I'm a little confused on what to use. There's all these terminologies like artifacts, release, publish, staging. I'm not sure what task I need to use.
Let's go over a typical scenario so you best understand the terminology. This, of course, is just an example.
You have multiple git repositories in Azure DevOps Repos. One of those git repositories is a common library which is shared across multiple projects in your company. Another one is the companies flagship application, written in WPF, and used internally by 100 employees. Lastly, there is a web portal for external clients to submit orders. Each of these git repositories has branch policies in place to prevent checking in directly to the master branch (a pull request is required).
Development Team A works on the core functionality of your technology team, they update the common libraries. As part of the build pipeline, the library is compiled and a NuGet package is generated. The pipeline then publishes the package to your private Azure DevOps Artifacts feed, so that the other development teams can use the package.
Development Team B works on the flagship WPF application. As part of the build pipeline, the pipeline compiles the application. It creates a build artifact of the bin directory. Another stage in the pipeline takes uses the artifact and publishes it to the test environment, and sets a flag on the database that the current test version is the version that was just published. When the development team launches the test application, it is automatically updated because the version was incremented in the database.
Development Team C works on the web application. As part of the build pipeline, the pipeline compiles the application. It deploys the web application to the test web server. The test web application is available immediately for the development team to test.
At a later time, when the iteration cycle is completed, there is a code freeze. The code freeze involves the DevOps team manually running the build pipelines. Because the pipelines were manually run, the first pipeline will deploy the WPF application to the staging environment, and the version number is incremented in the database. The second pipeline deploys the web application to a green-blue server.
The development teams do a final round of testing to ensure there are no bugs which cause a stoppage. Once they are good to go, the WPF application is released from the staging environment by having it pushed out to all of the employee desktops. The release process for the web application involves flipping a switch so that the green server (updated web application) goes live, the network switch points to the green server, then the blue server (older web application) goes down.
If any major issues arise, things can be rolled back by flipping the network switch from the green server back to the blue, and deploying the older version of the WPF application to the employee desktops, etc.
This is just an example, it is not the only way to do this of course.
For an app for Windows 10 IoT Core on Raspberry Pi2, I need to use a launcher app or StartUp-Task, which creates a shadow copy of my app and launches it. I need to use this approach to be able to substitute DLLs during runtime, without having a lock on the DLLs and without disrupting running services. That's needed as the device running it, would be remote somewhere out of reach, deployed at a client's site and I need my app to be running to service the device. After updating my DLLs, I would restart it and it would run with the new libraries, start the launcher as default app, which then starts my app.
Before Windows 10 and UWP the approach was to use System.AppDomain from mscorlib.dll in the .NET Framework to create a new AppDomain in a cached directory. The config, executables and DLLs would be copied to a cache directory and run from there. That leaves the original DLL available for substitution and doesn't put a lock on them. This was also a very useful technique used in IIS and webapps, which needed to run without interruptions even if the code needs updating. The open threats keep servicing open requests until these are done and new requests will be serviced using the new updated versions.
Now in Windows 10 System.AppDomain is not available anymore. I tried Windows.System.ProcessLauncher but encountered several issues with it. First I have to register the EXE in the registry to allow launching it. Then it tells me I can only run it from an app container. I didn't get it to work as of now. It's just a tedious and messy approach IMHO.
Now to my question: What would you use as an alternative to the described old approach on Windows 10 IoT Core? Does anyone have a small snippet of sample code to share? Or perhaps a link pointing in the right direction? Any advice would be appreciated.
This approach is not compatible with the Universal Windows Platform app model.
You will have to push an updated package of your app.
I am completely new to Azure and PowerShell but have been tasked with setting up a build and deploy solution for several app services.
We currently have a build server (Azure VM) that is running CruiseControl.NET to build and test some C# .NET solutions that should be deployed in Azure.
This build server currently handles the following tasks:
Pulling code from source control when commits happen
Building the projects
Running some unit test cases
Copying output/binaries to an output location
However, as it exists now, developers of each of our app services need to 'Publish' their services manually from their development machines by clicking the button in Visual Studio once they have verified that the build and test cases have passed in the test environment on the server.
As I am hoping for a completely automated solution, I expect I need to use something like PowerShell or the Azure Cross Platform CLI (npm) to do this?
I'm extremely confused with the Azure Service Management vs Azure Resource Management versions with the new Azure Powershell 1.0. All of our services appear to be the newer Resource Management versions, not 'classic'.
The eventual goal is to have the build server do the following
Pulling code from source control when commits happen
Building the projects
Running some unit test cases
Copying output/binaries to an output location
If the build and test cases are successful, update the service in azure to the latest build
I am hoping there is a way to set up these projects, or take the existing binaries that result from the builds, and have them be deployed into Web Apps using the new Azure Resource Management Powershell features.
Any advice or resources for more information about how this can be done?
Hopefully this makes some sense. Please let me know if I am going about this completely the wrong way or direct me to a more correct forum.
Thanks!
have you consider to use Azure App Service? where you can get those build infrastructure for free. e.g https://azure.microsoft.com/en-us/documentation/articles/web-sites-publish-source-control/
Once you setup continues deployment, you will get below three when there is push event (if you are using git)
Pulling code from source control when commits happen
Building the projects
Copying output/binaries to an output location
and to "Running some unit test cases", you can create your own batch or powershell script with post deployment hook https://github.com/projectkudu/kudu/wiki/Post-Deployment-Action-Hooks