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.
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.
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.
So this is a C#-based .Net WebApp for a client on an Azure deployment on their network.
Testing locally, I can do dotnet run and test on http://localhost:5000 fine, but in the final environment, it'll need to be served by IIS. I believe dotnet run (Kestrel) and IIS have a way of talking to each other (there is a method called something like .useIISIntegration I believe).
But I'd like to skip any deployment script that requires I dotnet run to start the application if possible, but let IIS handle all of that. Once deployed, is dotnet run absolutely necessary? How does IIS handle it directly, if possible?
I guess that for your purpose you can simply:
run dotnet publish
create an application in IIS against the program
create an application pool and start it.
Don't forget to install the SDK/Hosting bundle in the destination server otherwise IIS will not be able to run it.
I'm looking to move an ASP.NET Core application into Visual Studio Team Services for continuous integration and continuous deploy. My application is currently built and deployed "manually":
Build by "publishing" to Web Deploy package in Visual Studio.
Apply DB-migrations (implemented using Simple.Migrations) by running a console application (built along with te web app in step 1) on the target server.
Deploy the built web app using Web Deploy on target server.
And now I would like to automate this process using Visual Studio Team Services. Building the web app (step 1) and deploying it to an Azure App Service (step 3)seems pretty straight forward. But I'm not sure how to apply my Simple.Migrations database migrations (step 2). Is it possible to run a console application (built along side the web app during the build phase) in the deploy phase? A task for running command line scripts certainly exists but I'm not sure what you can actually do with it.
Note that I would like to use the hosted agent (if that makes any difference).
There is a built-in task called: Deploy: PowerShell on Target Machines. This task uses Windows Remote Management (WinRM) to access on-premises physical computers or virtual computers that are domain-joined or workgroup-joined. This task can run both PowerShell scripts and PowerShell-DSC scripts.
Not sure if you could put your console application code in a ps script or directly Run a C# .cs file from a Powershell Script . Another way is using PowerShell run DB migrations. A sample for your reference: Use PowerShell to Migrate SQL Server Instances (db, logins, jobs, etc)
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