Preface: This is the second/last of a two-part series on Deploying Your NodeJS App on Azure. In this part, you will clone a code repository on Github - which is where the code for this guide is hosted, I have done the hard job of writing the code - you'd just need to follow through and pretend like you understand the code I've written 😁 (it's a very simple code to understand though).
In the first part of this guide (or series), you learnt about the painless way to setup and deploy the Azure App Service (formerly, Microsoft Azure Web Sites).
Going forward, it is worthy to note that this guide is covered in four key steps;
- Create a Web App Service
- Code a NodeJS app
- Deploy the NodeJS app on the created App Service
- Testing!
The first of these four steps has been covered in the first part of this guide, here, while the other three steps are covered in this part.
Now, before we do a deploy on top of our Web App Service, we'd need to write/get the NodeJS code we would be deploying on top of our Azure resource.
Diving in...
The code for this guide can be found in this repository, you can go ahead and clone the code repository here, such so you could follow right along. The Github repo for this guide contains a very simple NodeJS app - which has no APIs nor contains database for storing data (I'd come up with a more robust tutorial which covers database integration, in the future). The NodeJS app which has two views; an home view (which includes a form where data is being captured)
...and a welcome view - which would populate our layout with the data gathered from the home view. This could be modeled for an authentication page.😄
Also included in the repository is an app.js file, which is the index of our project, the Node runtime stack we setup in the first part of this guide (using Azure App Service) would compile and run this file - i.e, this is the file the Node runtime engine would use in serving up our entire project, this is an express code. You can get a closer look into how express apps work here
The last item in this repo is the package.json file, which is where the information for the app we have built is added, the package.json file works as a key-value pair type of object notation.
As stated earlier, the app is a very simple and primitive one. There would be a tutorial on deploying NodeJS apps with database on Azure later on. But before that time...
Let's Deploy our NodeJS App
In order to deploy our NodeJS app, we'd need to visit the App Service resource we created in the first part of this guide. I named the one used for this guide node101, and the first step here would be to select a deployment option.
Selecting a Deployment Option
Head over to the web app resource that you have created, the one created for this guide is node101. Click on Deployment Center as indicated below.
This should take you to the blade shown below
The very next step here would be to choose a deployment option, we would be using the Local Git option as our deployment option. Before we go forward, we'd need to get the NodeJS code we would be deploying on top of our Azure resource - if you don't have a NodeJS project, you could clone the one talked about at the beginning of this guide. For more insight on cloning Git repos, head over here
Publishing our Code to the Azure App Service
After selecting the Local Git from the list of options. The next step would be to select a service provider for the deployment pipeline, select the Kudu App Service for this, 
...hit Continue, and on the next blade, click Finish.
Still on the Deployment Center section, you should notice a Git Clone Uri - this is the URL we would be pushing our Node project to. But before doing that push, click on Deployment Credentials to reveal the essential credentials needed to authorize the deployment of your code on the Git Clone Uri provided. 
The very next step here would be to navigate to the cloned project folder on your local machine - be sure to remove the old origin inside the cloned repo and create a new one. You can change the existing origin url by using the git command below:
git remote set-url origin NEW_URL
Note: The NEW_URL identity would be the 'Git Clone Uri' on the 'Deployment Center', copy this Uri and replace the NEW_URL with the copied Uri. Mine would look like;
git remote set-url origin https://node101.scm.azurewebsites.net:443/node101.git
Verify if the newly set URL has been effected by doing,
git remote -v
For a more detailed guide on changing origin URLs, you should check this guide out.
Finally, to deploy the NodeJS code on the created Azure App Service, use the command
git push
Quick note, you might be required to provide application credentials (username and password) before the git push command is effected to the URL. If this is the case for you, supply the credentials provided by Azure on the Deployment Center
Finally, Test the App!
The URL for the NodeJS app can be found on the right corner of the App Service Overview section, click on the URL to visit your deployed NodeJS app, cool ain't it? 😁
If you ever run into issues, be sure to make comments on this post. I'd respond to any issues as soon as possible.
You can as well reach out to me on Twitter, @_bashirk
Bonus Point
Be sure to Stop/Delete any resource once you're done with using them. To delete/stop the App Service you've created for this guide, head over Overview section of your App Service resource and click the Stop button for stopping the billing on this resource or the Delete button to delete the entire resource. Cheers :)
Top comments (2)
Thanks for the post! Could you please show us how you do the following:
1- Set env variables, e.g db credentials/port number/etc, for the deployed app (local .env files are not supposed to be pushed to the azure web app remote git repo)
2- i guess by doing "git push" the Kudu service behind the scenes issues the command "npm start" on the package.json. if this was MERN stack with frontend, the client needs to be build first "npm run build". Can u show an example of package.json scripts that handles such situation (build client and start node app)
Thanks
Thanks for the kind feedback, Raedbenz.
To begin with;
1- There's no db credentials included in the deployed app, as this Node.js app doesn't store data. Only uses Express (from the app.js code) for rendering the files. It gets data inputs from the home.ejs file, and directly sends the data to its respective prop (overrides the prop value) in the welcome.ejs file. Hence, no data is stored in the actual sense.
Moreso, Azure App Service renders web pages using the :3000 port number, by default. And as can be seen in the package.json file, there's a process.env.PORT||5000 argument - which is an environment configuration, where PORT is the env variable for the port number (was never hardcoded). The || operator in JavaScript means OR in Layman's terms; which makes the package.json file suitable for both local and remote deployments. The 5000 port number value would only always get accessed by the 127.0.0.1 address (your localhost), UNLESS you go ahead and change the value for PORT in your App Service settings. Which brings me to the next point.
It is important to note, that, environment variables can always be set from the Configuration section (Application Settings option) of your app service Settings. You would only need to replace the values that you wish to have hidden in your code with the variable names (that hold these specific values) in your configuration settings on App Service. I destroyed the created resource group already, I could have showed a walkthrough via screenshots.
Finally,
2- Kudu doesn't issue the npm start command from the package.json* file to run the app (and there's obviously no npm start command in the **package.json file). The Kudu service uses the line below to run the Node.js app. It basically runs your issued command (value) passed to the "scripts" key in your package.json file.
The Kudu service has also been built to automatically look for an app.js or server.js file in your project, set it as the entry file, and use this file to run your Node.js project - if it doesn't find the script
"scripts": {"start": "<command>"}in your project. You can read more about this process here: blog.lifeishao.com/2017/03/24/cust...
A MERN/MEAN project would be built using the npm run build command, and it basically does nothing unles
`
"scripts": { ... "build": "<command>" ... }is specified in your package.json file. See here: docs.npmjs.com/misc/scripts
So, npm run build is useful whenever packages require a build process. You can rebuild packages before deploying by simply running the command, locally - before pushing to production (yeah, the Kudu service, by default, deploys your app to production)
You can also find a MEAN stack sample here, which includes a deploy.sh bash file for deployments. github.com/Azure-Samples/meanjs
I'd also be happy to write a more comprehensive tutorial on this in the future, if need be. Cheers :)