A few weeks ago at ng-conf, I announced the launch of vscodecandothat.com — a project I worked on with Sarah Drasner to centralize all of my favorite VS Code tips into a collection of short, silent video clips. It’s like a site full of GIFs, except without the 600 megabyte payload and crashed browser tab.
Sarah designed and built the site using Vue. I put together the video clips with excessive pug references.
Sarah and I both work on the Azure team, so it was a good chance for us to use our own tools here at Microsoft to work with a real application. In this article, I’m going to break down how we do continuous delivery with vscodecandothat.com, and how you can do it yourself using the same tools we use.
Before we talk about the setup, I want to define exactly what I mean by “continuous delivery.”
The term Continuous Delivery refers to making releases easy, fast, and streamlined. We can argue about the exact definition of the term, but just remember that I am a front-end developer so my eyes may glaze over. I may snore. But go on. I swear I’m listening.
For our purposes, “Continuous Delivery” means that the process of building and deploying the site is completely automated. Here’s how that looks in real life:
- Developer checks code into Github master branch
- Build server pulls code from Github
- Build server runs a build (npm script)
- Build server creates a Docker container
- Build server pushes Docker container to registry
- Burke finds the source of broccoli smell in his office
- Website pulls in updated container
Got all that? Basically, we’re going to automate everything that you would normally do as a developer so that checking code into Github is all you have to worry about. And lord knows that’s hard enough as it is.
OK, let’s begin at the beginning. The first thing we need to do is look at the application to see how it runs. And how it runs is “In a Docker, y’all.”
Running Vue on Docker
index.html page from the dist folder. We use an nginx web server.
When you are just serving up static assets, the Dockerfile is very simple…
FROM nginx WORKDIR /app # Copy in the static build assets COPY dist/ /app/ # Copy in the nginx config file COPY misc/nginx.conf /etc/nginx/nginx.conf # All files are in, start the web server CMD ["nginx"]
Sarah created an nginx configuration file that we just copy in when the container gets built. Because you do not want to be in the business of configuring nginx (OMG you don’t), Sarah has posted her config file to a gist.
I use the Docker extension for VS Code so that I can see and manage all of my images and containers. I’m not afraid of the terminal, but my brain can only remember so many flags.
Now we need a registry to push the container to. We’re going to configure Azure Container Services (ACR) for that.
You can create an ACR repository from the web portal, but to prove I’m not afraid of the terminal, we’ll do it with the Azure CLI.
First, we need a group for resources. I called mine “vsCodeCanDoThat”.
az group create — name vsCodeCanDoThat — location eastus
Now create the ACR repository. I called mine “hollandcr”.
az acr create --resource-group vsCodeCanDoThat --name hollandcr --sku Basic
Now we can push our image to that by tagging it with the path to the Azure Container Registry.
In the video you can watch me login to the Azure Container Registry from the terminal. This is important because your push will fail if you are not logged in.
OK — now we need a site to host our container. For that we use Azure App Service.
Creating The App Service
First create a Linux service plan. For that, you need your app name and your resource group.
az appservice plan create -n appName -g resourceGroupName --is-linux -l "South Central US" --sku S1 --number-of-workers 1
az appservice plan create -n vsCodeCanDoThatSP -g vsCodeCanDoThat --is-linux -l "South Central US" --sku S1 --number-of-workers 1
Now create the web app and point it at the container that was pushed to the AKS registry. This takes 4 parameters.
- Service Plan
- Resource Group
- App Name (you haven’t defined this yet)
- Docker image that you pushed earlier
az webapp create -n vsCodeCanDoThatSP -g vsCodeCanDoThatRG -p vscodecandothat -i hollandcr.azurecr.io/vscodecandothat:latest
And that’s it. You’ll get back a URL, and you should be able to open it and see your site running.
Now what we want to do is automate everything that we just did. We never ever want to have to go through any of these steps again.
The first thing we will do is to set up our site for “Continuous Deployment” from our container registry.
If you are using the App Service extension for VS Code, all of your Azure sites will show up right in the editor. You can just right-click and say “Open in Portal.”
Select the “Docker Container” menu option…
On this page you will see the container you configured from the terminal. There is an option at the bottom to turn on “Continuous Deployment.”
When you toggle this on and click “save,” a webhook will get created in your Azure Container Registry for this specific container. Now, anytime the image with tag “latest” is updated, the webhook will fire and notify App Service which automatically pulls in your image.
So we’ve automated some of this already. Once we push the image, it will be deployed. There is nothing we have to do besides push it. But we don’t want to push it. We want someone else to that.
And who will do it? The robots, that’s who. Or whom? OR WHOMST. Fortunately I’m not in high school English anymore. I failed it once and that was enough.
Setting up a build server
This is the point at which I tell you that we are going to use Visual Studio Team Services (VSTS). Then you say, “Visual Studio? I’m not using .NET”. And I say, “I know, it’s confusing.”
We need a system specifically designed to automate builds and deployment. This is exactly what VSTS is/does. Also, it’s free for 5 users or less (in a project space) and “free” is the only word in my love language. The only word besides “beer.”
Create a VSTS account if you don’t have one. Once you do, you land on the dashboard screen.
From here, you want to create a new team project.
Give your project a name and a description that nobody will find helpful. Leave the version control at Git.
The next screen gives you a Git URL to check your code into. But we already have Github, so just ignore that and select the “or build code from an external repository” option.
Authorize VSTS to Github and select the repo…
The next screen is offering to help you start with a template. In this case we are going to roll from an empty process. Because we are hard core like that.
Now we are going to start adding steps for VSTS to perform to do the build and deployment. The pull from source control is already happening, so the first thing we need to do is to run
npm install on our code. To do that, add a task to “phase 1”. There is only 1 phase in our build / deployment.
Search for “npm” and add the npm task.
By default, you get the
npm install task, which is exactly what we want. You don’t need to add any options to this task.
Next, we’ll be running the
npm run build command, which will build a production instance of our Vue app with all of its Webpacking magic. For that, add another npm task. This time, change the name to “npm run build.” Set the “command” to “custom” and the “command and arguments” to “run build.”
Great! We’ve got the build, now we’re ready to Dockerize it. Add a new task and find the “Docker” one.
This is a big screen, so here’s the image and then we’ll walkthrough the highlights.
- You are selecting the “Azure Container Registry”
- Specify your Azure subscription
- Specify your registry name (which we created earlier)
- Set the “Image Name” to $(Build.Repository.Name)
- Make sure you check the “Include Latest Tag”
Lastly, we want to push the image. Add another Docker task. This time, set the “Action” to “Push an image”. Set the “Image Name” to $(Build.Repository.Name) — just like before.
DO NOT SELECT THE “PUSH IMAGES” ACTION. If you do, your build will fail and you will blame god and all humanity before you figure out that you selected the wrong action. Don’t ask me how I know that.
And that’s it for defining the Build definition. You can now click “save and queue” at the top. Make sure that you select a “Hosted Linux Preview” agent. The Docker tasks needs the Linux agent.
Now sit back and wait for a build to kick off. If you’ve done everything right, you have now setup a completely automated build and deployment system for a Vue app that utilizes Docker and Azure. That’s the most buzzwords I’ve ever squeezed into one sentence.
Deploy and be happy
This seems like a lot to setup, but once you have it just like you want it, all you have to do is check in code to your Github repo and all of this manual deployment ? happens automatically. Your customers will love you. Your developers will love you. Heck — even YOU might love you.
I hope you find this helpful. I’m off to update my résumé with all of these buzzwords.