none
[Node.js][Web Apps] Deploy Web-API and node.js app-service to Azure PAAS, git vs. FTP RRS feed

  • Question

  • We are just starting to develop Azure app-services and I think it's amazing. Though one thing boggles our minds: There are various way to deploy an app-service to Azure (git, FTP, Dropbbox, Visual Studio, ...) and I have read the documentation and forums thoroughly but I have not found a step-by-step description what exactly happens during and after deployment.

    So my question ist: When and how does azure resp. the Kudu-Tools resolve ASP.NET 5 and node-packages, what files do I have to deploy exactly? Especially when using git as deployment-repo. The docu and the samples assume that one would check in the whole project, the Kudu-Tools pull everything from there and build it. (I know I can use gitignore to not check in source-code e.g.)

    But the usual ALM workflow is like this

    • Develop, build and test locally
    • Continuously Deploy to build system, build and test it there. The build will typically do many things like mini/uglyfing, compile etc.
    • Deploy the built soltution to staging. I just want to deploy exactly the artifacts which I have prepared and tested, like in a "WAR-file" or Webdeploy-package.
    • Deploy to production: Again, exactly my predefined and packaged components should go there

    I would never want any tooling on a production system to resolve dependencies, download stuff, compile etc. So what's the "real-world" way to do it? Why would I use git instead of just setting up a gulp-ftp-task along my ALM-chain to deploy to Azure?

    Thanks a lot in advance,

    Sheer



    Tuesday, January 12, 2016 5:35 PM

Answers

  • Hi Sheer,

    let me try to answer some of your question.

    RE: When and how does azure resp. the Kudu-Tools resolve ASP.NET 5 and node-packages, what files do I have to deploy exactly? Especially when using git as deployment-repo. 

    [xiaomin] Assume you setup continues deployment with one of the branch with your git repository.

    Kudu will fetch the delta changes every time there is a push to that branch (Kudu keep a clone of the git repository next to your site)

    - Kudu then build your application (you can specify your own deployment script to control how you build and run test before the actual deployment happen). During this build process, dependencies will be resolved if necessary. Once build is done successfully, file will be copy over to wwwroot

    RE: Deploy the built soltution to staging. I just want to deploy exactly the artifacts which I have prepared and tested, like in a "WAR-file" or Webdeploy-package.

    [xiaomin] Azure App Service has deployment slot feature, where you can test your new change and once you feel good about it, you can swap to production slot. (you can also enable AutoSwap thru settings). Depends on what type of application you are deploying, for asp.net app, the output from build process is binary artifacts, but for nodejs app, you will see your source code + dependencies in wwwroot.


    RE: 
    Why would I use git instead of just setting up a gulp-ftp-task along my ALM-chain to deploy to Azure?

    [xiaomin] In my opinion, the benefit of using git or more accurately use kudu to build and deploy your project is that, the build and deployment infrastructure is already there for your to leverage. Which hopefully save you some effort to do all those by yourself, at the same time is also customizable for your own needs.

    • Marked as answer by Sheer Point Wednesday, January 13, 2016 8:29 AM
    Tuesday, January 12, 2016 10:15 PM

All replies

  • Hi Sheer,

    let me try to answer some of your question.

    RE: When and how does azure resp. the Kudu-Tools resolve ASP.NET 5 and node-packages, what files do I have to deploy exactly? Especially when using git as deployment-repo. 

    [xiaomin] Assume you setup continues deployment with one of the branch with your git repository.

    Kudu will fetch the delta changes every time there is a push to that branch (Kudu keep a clone of the git repository next to your site)

    - Kudu then build your application (you can specify your own deployment script to control how you build and run test before the actual deployment happen). During this build process, dependencies will be resolved if necessary. Once build is done successfully, file will be copy over to wwwroot

    RE: Deploy the built soltution to staging. I just want to deploy exactly the artifacts which I have prepared and tested, like in a "WAR-file" or Webdeploy-package.

    [xiaomin] Azure App Service has deployment slot feature, where you can test your new change and once you feel good about it, you can swap to production slot. (you can also enable AutoSwap thru settings). Depends on what type of application you are deploying, for asp.net app, the output from build process is binary artifacts, but for nodejs app, you will see your source code + dependencies in wwwroot.


    RE: 
    Why would I use git instead of just setting up a gulp-ftp-task along my ALM-chain to deploy to Azure?

    [xiaomin] In my opinion, the benefit of using git or more accurately use kudu to build and deploy your project is that, the build and deployment infrastructure is already there for your to leverage. Which hopefully save you some effort to do all those by yourself, at the same time is also customizable for your own needs.

    • Marked as answer by Sheer Point Wednesday, January 13, 2016 8:29 AM
    Tuesday, January 12, 2016 10:15 PM
  • Hi xiaomin,

    thanks a lot. That really opens a new perspective: Use Kudu as build/integration platform and not just as a deployment tool. I'll give it a try.

    Best

    Sheer

    Wednesday, January 13, 2016 8:16 AM
  • Hey,

    I think below link can help you.

    https://www.cuelogic.com/blog/application-deployment-with-microsoft-azure

    Please check.

    Monday, April 22, 2019 7:40 AM