Deploying builds from AppVeyor

[xt0rted]

I'm using AppVeyor for PR builds and would like to have this handle my production builds as well since it's already building my master branch. From what I've read I should setup AppVeyor to produce a web deploy package which can then be pushed to my app service using the settings in the publish profile. I'm assuming if I switch over to web deploy that kudu needs to be disabled and isn't part of the process anymore, is that correct? Are there any other steps that need to be taken to switch my deployment process from kudu to web deploy?

I was also wondering if web deploy was the right option for deploying from a build server like this?

[PureKrome]

Hi @xt0rted - I've done heaps of AppVeyor work -> to -> Azure App Services.

If what I think you're asking is: Can I use KUDU for everything except production builds?? I'm not sure (sowwy) but what you will need to look at is if KUDU can only response to specific branches or any branch except a specific branch.

There is some Kudu Deployment documentation that suggests you might get kudu to only kick off on a specific branch. Bottom of that file it mentions having a deployment_branch app setting. This means you can't have any branch name, but only a specified one ... which could be a bit of a PITA for your usecase? To me, this all feels a bit clunky (if this is the way to do it).

My preference would be to use AV for build/test/deploy but if your repo is private, then you will have to pay.

If you do go down 100% AV, basically this is what I've been doing (OSS and private repo's)

• Turn off any KUDU stuff in the App Service
• Download the Publish Profile for the App Service. (see image below)
• Create an appveyor.yml file (case sensitive. yes. i just said that).
• Build my code, test my code, zip contents into a single zip and then web deploy to azure (either main slot or staging slots, if you use staging slots).
• 💰 profit.

The hardest part is making sure you

• figure out which parts of the Publish Profile you need to copy/paste
• encoding your secret password using AppVeyor.

So first up, here's two examples of 2x AV files I have used for OSS:

• .NET Core project
• .NET Full Framework project

To encode a secret password for AppVeyor, click this...

And to get more information about how to do all of this, I referenced this AV wiki page for my detailed help.

I'm happy to help with any Q's. No, I don't work for AV but just love it :)

[xt0rted]

Thanks @PureKrome. I've been using AppVeyor for a few years now for all of my projects but the only deployments it's doing are publishing NuGet packages for me. I'm pretty sure your high praises for it on Jabbr were why I switched to it from TeamCity in the first place.

Currently I have AV setup to build & test my PRs along with build any commits/merges to master. That's where it stops though. Those commits to master also trigger the kudu deploy which does its own build. This is what I'd like to get rid of since AV is already doing the build, it's just not being deployed.

I've had a continuous delivery process since the start of this project but there's a number of rough edges to it. The unused AV release build is one. The others are not using a slot to warm up the deploy, and running my EF migrations automatically on startup. None of that is ideal but it got me going so now I want to improve on it.

My dream setup is to have AppVeyor do the following:

1. Build the site, compile my views, run gulp, do ✨ things
2. Deploy to a slot on Azure
3. Deploy static assets to the CDN
4. Migrate my dB
5. Warm up the deployment slot
6. Swap to production
7. Ping Raygun or Sentry with the deploy info
8. Ping search engines that things have changed

I've read through a bunch of docs & blog posts on doing all of this but what seems to be tripping me up is how to handle EF and its migrations which throws a hissy fit the moment the schema changes. I've read plenty on setting up auto swap slots and deploying from AV, but nothing seems to cover how to properly handle dealing with EF migrations while keeping the site live.

For now my AV deploy changes are sitting in a dusty PR since I couldn't spend any more time on this. I'd love to pick it back up and get it done once and for all. I know moving away from EF could solve some of my problems, but for now it's too useful in such a young project that I don't want to move away until things become more stable (ripping out asp.net identity....that's another story and I can't wait to rip that 💩 out).

[PureKrome]

I only ever saw EF migrations with JabbR's source code which Fowler setup. We've always done it manually and made our live deployments a 3 step process

• code (AV CI/CD to staging slot)
• DB (if required, most of the time this is skipped)
• Flip switch

so that's our weakness in our CI/CD link.

[xt0rted]

After describing the process and thinking about it some more it might be fine to deploy to a slot, warm it up, then trigger the migrations and swap. The window for an EF schema error is small enough that it shouldn't be an issue at the moment (most updates while someone is on the site don't touch the dB anyway) and any that do come up should be gracefully handled anyhow. I have a test environment that mirrors production and deploys at the same time, so I could try switching the deploy process on that environment first then move it over to production when ready. Maybe later in the week I'll have to try dusting off that PR.

Thanks for bringing this back up and listening to me while I work through this.

[PureKrome]

👍 👍

[xt0rted]

@PureKrome I started setting up my web deploy step and it's generating the correct output, but I noticed it's not including any .pdb files aside from the one for the web project. Is there a magical setting I'm missing somewhere to include those? My kudu based deploy script includes them and the msbuild call is the same aside from including /t:Package.

[PureKrome]

@xt0rted Does this SO question/answers help?

[davidebbo]

I didn't follow this whole thread, but please do note that if you are deploying to App Service via msdeploy (whether from VS, AppVeyor, Octopus, ...), you are not using Kudu. Given that, maybe this issue is not actually Kudu related?

[xt0rted]

@PureKrome that was one of the pages I found while looking into this, but I already have that option unchecked. This is why it's annoying, running msbuild against my solution or projects does produce the .pdb files, but when building the web deploy package only the target project's .pdb is included. I guess it's off to SO with that question.

Update: turns out the web deploy task on appveyor includes all the PDBs, but when I run the process locally with my own script it doesn't.

@davidebbo in general what's being discussed now isn't kudu related. My original question was about what needs to be done to disable kudu in order to migrate to the web deploy process. That sort of went off the rails as we started talking about how to get the deploy package being built so I could then get to the point of disabling kudu. The only reason I've kept the conversation on here is because once I was finished I wanted to provide clear steps of what I needed to do for anyone else coming across this trying to do the same.

[davidebbo]

Understood. I'll close it since there is no Kudu issue, but feel free to continue discussing here.