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.
Related
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.
My company has recently switched from automatic migrations on our Entity Framework databases to now relying on a command being run to migrate and afterwards seed the database.
We want this to run on the database of each environment that is being deployed to via Appveyor, so when pushing to a specified branch Appveyor builds, deploys and then runs the migrate and seed command on each environment after the deploy is completed.
We usually place all build and deploy configuration in a yaml file, but there doesn't seem to be any way to run commands after deploy on the environment itself. The yaml script command after_deploy runs command as part of the build process, not the environment.
The Appveyor environment has a setting After deployment command that seems to be the key, but it requires the "runCommand" provider to be allowed on the server side. The reason for this is understandable, but how do I go about setting this up?
The guides I've found haven't really given anything. Nothing applicable on SO, and the link to Microsoft that Appveyor prints as an error in the deploy process is no longer accurate.
Because environment deployments run on shared worker severs, custom scripting is not allowed. But you could try a deployment project approach. This divides your project into a "main project" and "deploymnet project" thus simulating a deployment environment, allowing you to decouple builds and deployments.
Assuming you are deploying to azure, you could then use this script my colleague wrote to run your commands on the server.
If you are not deploying to azure, you could switch to AppVeyor deployment agent which uses web deploy behind the scenes.
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
We have an MVC 5 application that is based on modules (a groupe of functionalities). We also have teams dedicated to each module. So my question is: is it possible to do some sort of partial deploy where we only publish the changes we need?
Maybe is better for me to explain how we are working today:
Right now, when each member of any team commits code we run the CI build and the unit tests and the site gets deployed to a test server where the dev that made the commit tests it's own code and once they are happy with that we deploy that version to testing. But that brings a problem as THAT developer was happy with HIS functionality but other dev may not be at the same stage with other part of the development in other module, so that unwanted change gets deployed to testing.
When I was using ASP.Net Webforms with other project we usually deployed at a Page/Code behind level and it was just fine but now everything (Controllers, helpers, etc.) gets bundled into one assembly and also if we change something on the Bin folder the AppDomain gets recycled so the app basically restarts.
Of course that we are taking care of this testing deploy issues, just by communicating with the rest of the teams before publishing something to test but I was wondering if there is something more that we could do, that's why I thought about a partial deploy.
If you have different teams working on the same project, you should probably take a look on branch strategies. In your particular scenario, branch per feature (or per module) might work fine.
In your case CI has to be enabled on "main" branch. When a team starts a feature, they create a branch. During development they commit to that branch (you can enable automated test execution and deploy to dev on "feature" branches as well). After finishing a feature, they merge changes into "main", CI create a build and deploy it to server. However there is one drawback, possible conflicts during merging, so you need to make sure that your teams commit to main branch as often as possible to minimize these problems.
We are switching to an actor based architecture for a subsystem in our product (We use C#), and we are considering either Akka.NET or Service Fabric actors. We have experience with Akka and Akka Clusters (in Scala), but the Service Fabric actors suits our purpose perfectly. It is, however, really difficult to find any material about deployment.
Is it possible at all to deploy on Azure at the moment (or can you join any preview programmes)? I can't find any indications of when a preview will be available, if it is not possible already.
Azure deployment is not available yet. It will be launched as a preview later this year.
Update: Service Fabric is now available in public preview.
Update: Microsoft now provides Service Fabric Continuous Integration documentation
I have continuous delivery running w/the development SDK (all nodes on one VM) like this:
push to github.com
github.com tells Visual Studio Online to trigger a build.
A custom build definition with a custom #PowerShell script step who 7z’s the build artifacts and curl’s the file to the Windows Server 2012 R2 Azure VM instance
IIS is loaded on the VM to host basic auth over TLS, & the WebDav module simply for this upload (easier to configure than FTP or WebRM on Azure, for sure)
I wrote custom open-source code who monitors for a trigger file (https://github.com/corlib/trigger) and invokes a command, configured to invoke a custom deployment script. (very early, but functional for this purpose)
The deployment script decompresses the archive, loads the ServiceFabric application manifest to obtain the application type version. This version is used to deploy the application package to a unique location in the cluster, register it, and then start a monitored application upgrade (w/rollback to previous version on failure)