Using built in msdeploy to publish nodejs site to web azure app and run deploycmd

I am following this guide:

when octopus deploy pushes files to an azure web app I believe it uses webdeploy to do it. Unlike when you push from GIT it doesn’t seem to know what type of app it is. The above guide seems to suggest that creating a .deployment and deploy.cmd should be run when the files are pushed.

Is this possible?

I used azure-cli to produce the files and checked them into SC, pushed them into the Octopus package. I can see that they do end up in the “D:\home\site\wwwroot”. but npm doesn’t get upgraded or node modules installed

Hi Jon,

Thanks for getting in touch! The custom deployment script described here only gets executed when you are using the Git deployment process built-in to Azure Web Apps which is called Kudu.

Octopus can’t use the Kudu deployment engine, but instead uses the WebDeploy interface to Azure Web Apps to synchronize the contents of your package with the Azure Web App.

To my knowledge there is no way to execute custom startup scripts when using WebDeploy.

My personal preference is to make sure my deployment package contains everything I need to deploy. So I would prefer to have my build process prepare everything (npm etc) and package up the entire result ready for deployment. This way I guarantee the same code is deployed to each environment in a repeatable manner, and there are less chances an NPM outage will cause a production deployment to fail.

This also means you don’t need any custom scripting after deployment - the web app is completely ready to run when it is deployed.

Hope that helps!

I did try and create a package that contains all the node_modules but it errors creating the zip due to windows file / folder deep issues. So this is not a possible solution.

is it possible to trigger a webjob via octopus?

Hi Jon,

Thanks for getting back to me. Are you using the later versions of npm which (attempt) to fix the deep/nested path issues? We’ve noticed a lot of cases where this has helped.

You can deploy a WebJob with Octopus, and Azure will execute it according to your configuration:

Hope that helps!

Hi Mike,

We are using NPM 3.10.6 as our base version.

I still don’t understand how it would be triggered though. It would need to be a triggered job vs a continuous job as you would not want npm to run twice (or more). I don’t get how you would create a trigger via powershell or the like on a newly created web app so that it triggers straight away. The link (as far as I can see) doesn’t see to explain this.

Hi Jon,

Thanks for getting back to me. Ah, that version should already be collapsing paths unless it’s configured not to do so.

Like I said earlier, my personal preference is to create packages with everything required to “sync and run” - I would personally continue to pursue this direction. You could try Yarn (an NPM compatible client from Facebook) and see if that helps?

Yarn: A new package manager for JavaScript - Facebook Engineering

Another idea is to try building your package on a Windows 10 (Redstone) machine with the 260 character path limit removed:

If you have no choice but to continue down the Web Job route, you could try configuring a scheduled job as Recurrence: One-time job and Starting: Now as described here: Run background tasks with WebJobs - Azure App Service | Microsoft Docs

Hope that helps!

Yarn does look interesting and will be looked into in the future but not at this point.

Had not heard of the Redstone machines, again unfortunately not possibly at this point, but nice idea.

I am currently trying to go down the triggered webjob route and manually trigger it to do what I need.

Is it possible to get msdeploy to put all the files in the “repository” folder (the same way that git push would)? That way I could try and manually run the kudu process and pretend it came in via git and would then do the whole npm process for me?


Hi Jon,

Thanks for getting back to me! The “Redstone” was a reference to a recent update to Windows 10 - nothing special really - but I would also love to see the 260 character limits be a thing of the deep dark past!

Unfortunately I can’t offer much more insight for the triggered web job - whilst I’ve built a few continuous web jobs, I haven’t attempted what you’re aiming for. Everything could “just work” or you may run into permissions problems etc.

Regarding the putting everything into a repository folder, by default WebDeploy will target the wwwroot folder, and you can deploy any files into any subfolder under wwwroot. Since you’re going to do the orchestration yourself using a scheduled web job, you should put the files in a location the web job can access, not worrying too much about the conventions used by Kudu.

Hope that helps!