Previous arcticle: TypeScript 4 Ever(ywhere)
In our previous article, we create a TS backend app along with an NPM module called mrutils. The article was based on the idea to keep our ALM as simple as possible: We develop our backend app and our NPM module(s) in parallel but don't want to hassle with constantly packaging and uploading our module to an NPM registry, neither private/local nor public. Therefore we used
npm link to create a symbolic link from our app to the package (or the other way round, however you might look at it). In other words: Our backend app contains a linked folder called mrutils underneath
node_modules. That's great for development. As soon as we change code in the module, it is reflected in our app. But: How do we deploy all assets to azure?
The simple plan is:
npm install) and launch the app
Straight forward: Create a web-app in the azure portal.
Next we define our preferred deployment mechanism, which is, in our case, "local git". What does "local" mean? It means that the git repo is local to the virtual machine on azure. As we will see later, azure "really" creates a VM for every web app. We can connect to this VM through Kudu, open a kind of CMD etc. And the "local" git repo will be located on this VM.
Then we choose Kudu as our build system. As you can see in the picture, the other option is "azure pipelines", but we just want to deploy the app without any pipelines at the moment.
On finshsing this wizard, we get to the git clone url.
Then clone the git repo to your local dev environment:
git clone https://testnodejsazure.scm.azurewebsites.net:443/testnodejsazure.git
The clone operation will create a directory testnodejsazure.
Our previous blog covered TypeScript-nodejs-modules: How to define them and how to use them efficiently without any need for a n NPM registry (during dev-time). That's fine from a development perspective, but now we need to transfer our app to azure along with the modules it depends on.
That's what we are gonna do:
npm pack) all of our "homegrown" dependencies, eg. mrutils. In case we change any code of these modules, remember to increase the version number in the module's package.json. This ensures that azure's
npm install recognizes a new version of the module. If you didn't increase the version number,
npm install would - apart from the first installation - do nothing with the package.
Copy the packaged modules to the git-repo/directory we have cloned before: testnodejsazure
Copy the transpiled JS-files and (optionally) the map-files to the same directory.
Change into this directory and call the three commands
git add *,
git commit -m "my commit message",
The git push operation will trigger a deployment to our new web-app. The remote log output will be reflected in our local console, so we can follow what happens.
The deploy.cmd will be run and installs our node app:
So far everything was straight forward: We deployed our "homegrown" app and modules and let azure Kudu and npm install do the rest. We did not deploy any of the many other modules our app depends on (i.e. those under
node_modules). Well, that makes sense: Our
pacakge.json describes our app and packages and we don't want to transfer megabytes of node_modules from our local environment to azure.
But: What happens if azure's
npm install installs a slightly different version or a very bad man in the middle interferes with the download somehow and injects trojan code into the downloaded modules?
package-lock.jsonis for: It pins down the exact version along with a digital signature for the package. So we can be 100% sure to get exactly the same packages/code/versions as we had in our environment.
In part three we will see how to operate/manage a nodejs app on azure and how to handle nodejs native modules through the infamous
Mext arcticle: TypeScript 4 Ever(ywhere) - Operate on azure