New to Visual Studio Team Services, previously Visual Studio Online
I have a couple .net core rc2 apps.
Example 1: Solution contains 1 .net core MVC app, 1 Web Api app, Multiple dependent assemblies.
I've got 3 on-premise servers (Dev, QA, Staging)
My dev server contains the build agent. My confusion is on how to best deploy these apps to my on-premise servers and finally to my production server on azure.
Do I generate webdeploy packages? If so, where and with what? In my build definition or release definition (on tfs)?
What would be the proper way to do the deployment part of these .net core rc2 apps and (using what, and in what order) is what im trying to figure out.
To my understanding so far, I believe on check in (CI build), I build/deploy to all 3 environments (dev, qa, staging). With dev and qa being automatic. Staging being either automatic or approved (authorized), depending on QA results. Finally production, being manual. I understand this is not set in stone, and certain things can be done differently, but does it sound right?
Oh, and all my servers are windows server 2012 r2
You can use build definition to build your project and generate the deployment packages and then use release definition to deploy the packages. In the release definition, you can add three environment to deploy to Dev, QA & Staging. For how to build and deploy Asp.Net Core app, please refer to this link for details: Build and deploy your ASP.NET Core RC2 app to Azure.
Related
Running ASP.NET Core websites under IIS on a Windows Server 2012 where we installed the .NET Core 2.2.7 Hosting Runtime installer.
With Azure Release pipline we want to run our migrations using commands but we got a message saying:
Did you mean to run dotnet SDK commands? Please install dotnet SDK from: https://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
So basically we also need to install the .NET Core SDK, but will this work when having the Hosting runtime installed? Can we drop the hosting runtime and only install the SDK? I guess not because I thoughed the SDK is for developing.
How to perform dotnet operations on staging and production environments?
UPDATE
To be more clearly about I am asking, I want to run my Entity Framework Migrations on the environment after the deploy process. So basically running the command dotnet ef database update -v after pushing the files on the staging and production enviroment. So not in the Azure container but on the real destination webserver.
I'm new to asp.net core and I'm trying to deploy the project into UAT and Release environment (server) via TeamCity.
With the help of https://www.youtube.com/watch?v=M1h3rWGKt44 I can build the project no problem, but it's the next step where I can publish and deploy into different environments.
NOTE: I can publish from Visual Studio 2017 having EnvironmentName set up, which will generate the , which then in turn picks up appsettings.uat.json file etc. But we want to do this via Team city like what we've done with all our other MVC and webforms projects.
Could anyone out there help please?
Currently we are using TFS 2017 update 1 on premises but we have to Migrate TFS at VSTS cloud platform. Also we TFS Build Servers on premises having XAML builds using customized build template. Our problem is after migration all XAML build definition would working as usual or not?
Currently we are using TFS 2017 update 1 on premises but we have to Migrate TFS at VSTS cloud platform. Also we TFS Build Servers on premises having XAML builds using customized build template. Our problem is after migration all XAML build definition would working as usual or not?
there is no code. Do we need to Re-configure all build server again?
After migration on VSTS can we configure All build servers on premises as well using old all XAML build definitions or not?
Please suggest on this.
XAML builds are still supported with Azure DevOps Service (with some limitations), see official response from Microsoft:
XAML build is still here until now. Current state :
If you have any XAML build data in your team project collection, you
will get a warning about the deprecation of XAML build features. You
will need to use VS or Team Explorer 2017 to edit XAML build
definitions or to queue new XAML builds. If you need to create new
XAML build agents, you will need to install them using the TFS 2015
build agent installer. Please refer to official document -XAML builds:
https://learn.microsoft.com/en-us/visualstudio/releasenotes/tfs2018-update2#xaml-builds
And we will keep it longer, how long does it can be used depend on
user feedbacks.
Installing TFS2015 Update 4.1 locally allows you to configure Build Server, Service and Agents that are connected to Azure DevOps Service, and run all your XAML builds from either Azure DevOps or Visual Studio.
XAML builds are no longer available in VSTS, so they will not work at all after a migration.
The good news is that TFS 2017 supports build vNext so you can convert your builds before you migrate to make sure you can still build after the migration.
Build vNext (Azure DevOps Pipelines) are much more flexible and easier to set up and customise than the old XAML builds. However if you have a lot of customised builds then it might take a while to convert them all.
One big advantage of the new build system is that the same build can be used across multiple branches, which might mean that you don't need to put as much effort in to converting builds as in the XAML system you needed a build per branch.
My suggestion is that you begin by familiarise yourself with the new build system and start to convert the builds before you migrate, then you can import you TFS database in to VSTS.
No matter how many times I attempt to deploy my recently migrated ASP.NET MVC Core 2.0 app from VSTS CD, I only see old builds that were created before I migrated the project and VSTS CI build steps.
No error messages. Everything is making happy noises. However, I have the build number injected into the appsettings.json so I can see which build is in production, AND I've made several tiny aesthetic changes just to know for sure there's a new build of the software out on production and I am 100% confident the latest build is not being served.
I migrated my web app from ASP.NET MVC Core 1.1.2 to ASP.NET MVC Core 2.0.0. The last two successfully deployed 1.1 builds were #259 & #260.
I updated the VSTS build process using the "preview" 2.0 steps and got it producing successful builds. This new build is #270.
The VSTS release process reported no errors when deploying to Azure Web Apps Websites in a Staging slot.
I swap the slots without any errors.
However, I only see builds #259 and #260 as I try and re-try to re-release build #270 manually and re-swap the slots after VSTS CD gives me a successful response.
At this point, I'm considering going into Kudu and just deleting everything to force Azure Web Sites Web Apps to give me an obvious error message.
Before I do that, however, I wanted to ask if there's anything obvious I'm missing? Unlike the CI feature, VSTS CD has no verbose logging (AFAICT) and I can't locate any logging on Azure Web App's side regarding deployment attempts.
Here's a history of the builds ... all successful:
For context, here's the overall pipeline:
Here's the definition for Azure App Service:
Update 8/24 10am:
This morning, based on #starain-MSFT's comment, I did the following:
In Azure, I stopped both staging and production slots.
Back in VSTS in the release definition, in the "Azure App Service Deploy" task, I checked and yes, "Publish using Web Deploy" was already checked.
I added a checkmark to "Remove additional files at destination".
I created a new release (#110).
I check the logs for the "Deploy Azure App Service" release task:
2017-08-24T14:53:01.7169084Z ##[section]Starting: Deploy Azure App Service
2017-08-24T14:53:01.7419076Z ==============================================================================
2017-08-24T14:53:01.7419076Z Task : Azure App Service Deploy
2017-08-24T14:53:01.7419076Z Description : Update Azure Web App Services, Web App On Linux , Function Apps, Mobile Apps using Web Deploy / Kudu REST APIs
2017-08-24T14:53:01.7419076Z Version : 3.3.13
2017-08-24T14:53:01.7419076Z Author : Microsoft Corporation
2017-08-24T14:53:01.7419076Z Help : [More Information](https://aka.ms/azurermwebdeployreadme)
2017-08-24T14:53:01.7419076Z ==============================================================================
2017-08-24T14:53:03.7273244Z Got connection details for Azure App Service:'beastmuffin'
2017-08-24T14:53:04.4099686Z [command]"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package='d:\a\r1\a\BeastMuffin-CI\drop\270.zip' -dest:contentPath='beastmuffin',ComputerName='https://beastmuffin-staging.scm.azurewebsites.net:443/msdeploy.axd?site=beastmuffin',UserName='********',Password='********',AuthType='Basic' -enableRule:AppOffline -userAgent:VSTS_3ba069a5-b836-4fd5-9b7a-158f8f07399f_release_1_110_110_1
2017-08-24T14:53:05.4251931Z Info: Using ID '5285835e-1d30-414e-bcb6-288c207678ac' for connections to the remote server.
2017-08-24T14:53:16.2964958Z Info: Deleting file (beastmuffin\Accessibility.dll).
2017-08-24T14:53:16.2964958Z Info: Deleting file (beastmuffin\Accessibility.xml).
... about 3000 lines later ...
2017-08-24T14:54:43.0840845Z Info: Deleting file (beastmuffin\zh-Hant\System.Spatial.resources.dll).
2017-08-24T14:54:43.0840845Z Info: Deleting directory (beastmuffin\zh-Hant).
2017-08-24T14:54:43.0840845Z Total changes: 3009 (0 added, 3009 deleted, 0 updated, 0 parameters changed, 0 bytes copied)
2017-08-24T14:54:43.0980858Z Successfully deployed web package to App Service.
2017-08-24T14:54:44.9961584Z Successfully updated deployment History at https://beastmuffin-staging.scm.azurewebsites.net/deployments/1101503586484042
So, it looks like it deleted the old files, but did not deploy / add the new build's files to Azure -- HOWEVER the COMMAND to deploy (per the logs) did not throw any exceptions.
Just to confirm nothing really got deployed, I visit the site and see this now:
So, I'm guessing there's no files in the production slot at the moment.
Update 8/24 1pm:
One new pertinent detail as I continue to debug this.
The new (preview) App Service Editor shows that the .zip file has been moved to the /wwwroot folder, however it does not unzip it.
Based on the logs and the .zip file, I'm beginning to think that the "Deploy Azure App Service" task doesn't yet support ASP.NET MVC Core 2.0.
To that end, I've opened a support issue on the vsts-tasks GitHub repo:
https://github.com/Microsoft/vsts-tasks/issues/5111
This issue was resolved out on GitHub (github.com/Microsoft/vsts-tasks/issues/5111).
In a nutshell, the new Build step "dotnet publish" (under preview as I write this) allows you to zip up the artifacts.
However, I already had the old "archive files" build step that I never removed from the previous build definition for ASP.NET MVC Core 1.1.
So, the result was the build was zipping up the zipped publish. During release, the publish was unzipped once, leaving the inner zip file unzipped as it moved it to the Azure website destination.
I have create a sample ASP.NET 5 application (pretty much the example one from New Solution), and pushed it to GIT hosted on Visual Studio Team Services (former Visual Studio Online). I want to set up continuous integration to Azure Web App (former Azure Web Site). I have tried to set it up from Azure portal itself, it did create a new build definition, but it fails to build ASP.NET 5. I have found a guide how to do this, but it never really worked for me, I get errors like this e.g.
Error parsing solution file at C:\a\1\s\Frontend\src\Frontend\Frontend.xproj: Exception has been thrown by the target of an invocation.
Predefined type 'System.Void' is not defined or imported
Another problem is that it seems it really takes a lot of time to install dnvm, get packages, etc. So all in all it's a pain to make it work.
So are there real alternatives for that or more importantly is Microsoft is planning to implement something like a Build ASP.NET 5, Deploy ASP.NET to Azure and such to make it easy as I suppose it's easy with the current ASP.NET 4 apps. I really hope that it will be an option soon since it's quite impossible to work with current build system.
For "System.Void" issue, please check the runtime version in "global.json" file and make sure it is consistent with the dependencies in "project.json" file.
For dnvm install issue, since AspNet5 runtime environment isn't installed on VSTS Hosted Build Agent for now and the different users may use different runtime versions, it requires the user to add a "PreBuild" PowerShell step to read the runtime version in "global.json" file and then install it. If you can make sure that you will always only use one version (For example: 1.0.0-rc1-update1), you can deploy your own build agent and install "1.0.0-rc1-update1" on it, then you can skip the dnvm installation during the build process.
Take a look on http://riffer.eu/wordpress/?p=112. There I have a solution vor asp.net core RC_1.
Amazingly you need only two powershell scripts - there is no compiling / visual studio necessary.