Angular 4, Node, and Azure: Part 3

In parts 1 and 2 we built an Angular + node.js app and deployed it to Azure using our local git repository. We noted at the end of part 2 that we can definitely improve on our solution. It works, but it doesn't really alleviate us from the works on my machine mantra. We essentially moved our machine, in a sense, but we're still building it on our local box and pushing it up.

Our focus, then, will be removing the build dependency from source control and having our app build on another machine and deploy to Azure.

There are a number of CI/CD tools out there, but we're going to take a look at a free one: GitLab.

Method 2: Deploying to Azure from GitLab

So, just like with Azure, we'll need to create an account on GitLab. We'll use the hosted solution and keep our repository private for the time being. As usual, give it an appropriate name:

When you create your project, GitLab will give you some handy instructions on how to import your project. However, in order to push our commits, we'll have to add an RSA key and associate it to our GitLab account. The setup is a little different depending on your environment, but GitLab lays out the instructions here: https://docs.gitlab.com/ce/ssh/README.html. It's pretty straightforward and should only take a couple of minutes.

While you're doing that, another gif:

Hopefully you got that squared away.

Now we'll add a remote and push the commit up to GitLab:

Not any different than using any other git-based source control repository, really. You can take a look at what got pushed here:

So, we've got source control 101 out of the way: if our machine blows up, our code can be recovered.

How does this help us with our Azure deployment? Well, we can tell Azure to look at GitLab as the external source code repository. Whenever we push to GitLab, we'll tell it to let Azure know that there was a change and the platform will prep and run the app just like it did when we pushed it directly from our local git.

First, let's tell Azure about GitLab. Go to the Azure portal and go to your app (it may be on the dashboard or you can go through the resource groups like we did in part 2):

You'll notice that it has a log, but it's configured to use our local source control option. Click "disconnect" and then "setup" (you may have to toggle off of "Deployment Options" and back on once it disconnects).

After it's disconnected, it'll ask you to configure a new source control connection. Choose "External Repository" (notice that "Local Git Repository" is an option, that's what we did before) and enter your GitLab URL. This is simply your project URL with "git" appended to it. For me, it's: https://gitlab.com/mikebarksdale-blog/my-angular-app.git.

Save it and check out the deployment options again. You'll notice that the history is gone and, more than likely, you'll see a failure when it tried to connect to GitLab.

So, there message is a little misleading, but we'll get it sorted out here real quick.

Azure uses Kudu to manage the deployment of our app. If you go back to the previous part, you'll notice in the setup process that you were given two URLs to your site: http://my-angular-app.azurewebsites.net and https://my-angular-app.scm.azurewebsites.net. That scm part will allow us to configure GitLab to fire a request out to Kudu to deploy the app whenever we commit code.

For this part, you will need your publish information as we'll use the app specific username & password combination. You can download it from the overview portion of your app and clicking "Get publish profile" along the top.

In your GitLab project, go to "Settings" and then "Integrations". You'll want to add the following to the URL portion for the integration: https://$username:password@app-name.scm.azurewebsites.net/deploy.

The $username is the username with the $ in front of it and the password is that long, glorious password. You can get them here:

And plug them in here:

We only care about push events, so click "Add Webhook". It'll appear down below and you can test it to make sure it's ok:

And when you test it, the page will refresh and you'll get a message:

We have one more step: adding a deployment key to GitLab so that Azure knows to trust it. You can get the deployment key curling or browsing to the URL you setup as a webhook, but instead of /deploy you'll go to /api/sshkey?ensurePublicKey=1. So it'll look something like this: https://$username:password@app-name.scm.azurewebsites.net/api/sshkey?ensurePublicKey=1.

Curl or browse to it and copy the key (without the quotes) for use in GitLab:

With the key in tow, go to the "Repository" section under "Settings" in GitLab. Enter a descriptive title for your key and paste the contents in the box below (make sure to remove any extra line breaks if you have any in the key portion). It's ok for pull only access (default):

Let's push a small change to our app. For this, I'll add another super hero and commit the changes. If you make a UI change, don't forget to run your Azure build and commit your changes. Once you do that, go to the Azure portal and check your deployment options, you'll see it spinning (if you're fast enough):

You can watch the pinwheel if you like. It'll provide updates until it's process is finished. If it's taking a few minutes, you can amuse yourself with this:

When it's done, you'll get a fairly unceremonious checkmark:

Now check out your app, deployed from source control hosted at GitLab to Azure:

Neat, huh?

So, we took a step in the right direction. Our first method looked at deploying to Azure from our local git repository and this method pushed that responsibility to GitLab. The code isn't deploying from our machine, but we still have some clean up to do.

In the next part, we'll use GitLab's CI/CD capabilities to remove our dependency of having to build our app locally in order to have it deploy. We're almost "cloud native".

Til next time.