VSTS Vue.js

Wolf Tracker: Create a CI/CD Pipeline with VSTS

Let me show you how I created a Continuous Integration (CI) and Continuous Deployment (CD) pipeline for Wolf Tracker – my Vue.js single page app (SPA).

Prerequisites

I’m assuming you already have your code in Visual Studio Team Services (VSTS) and that your Azure account is also hooked up to you.

If you’re new to VSTS checkout my blog post series: VSTS for the Lone Wolf.

Background

I want to build my application and deploy it to Azure blob storage automatically, whenever I commit code.

I’m using a GitFlow process so:

  • If I commit to the release branch I want it to go to production
  • If I commit to the develop branch I want it to go to dev/test
2017-12-18_22-44-41.png
You can see my devtest and production blob containers. Both hold a version of my Vue.js SPA

Build Definition

The build definition is available in VSTS under your project, in the Build and Release tab.

Tasks

  • Under Builds click + New. You can select an empty project or use the NodeJS as your starting point
  • Enter a name. I called mine Wolf Tracker-CI
  • If you click Get sources select your repo

2017-12-18_21-55-11.png

  • Add an npm task.
    • Display name: npm install
    • Command: install

2017-12-18_21-54-40.png

  • Add another npm task
    • Display name: npm run build
    • Command: custom
    • Command arguments: run build

2017-12-18_21-54-45.png

  • Add an Archive task
    • Display name: Archive files
    • Root folder (or file) to archive: dist
    • Archive file to create: $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip

2017-12-18_21-54-53.png

  • Add a Publish Artifact task
    • Display name: Publish Artifact
    • Path to publish: $(Build.ArtifactStagingDirectory)
    • Artifact name: $(Build.BuildId).zip

2017-12-18_21-54-58.png

Once you’re done click Save & Queue

Triggers

 

Checkout the first half of this article: Implementing CI/CD with GitFlow in VSTS.

Continuous Deployment

Dev/Test Environment

  • Create the + button to Create release definition
  • Select the Empty template, click Apply
  • Rename the first environment to Dev/Test
  • Click the + Add artifact icon and select your build you created earlier
    • If you don’t see it, could be because it didn’t build successfully
  • Click Add

2017-12-18_22-19-20.png

  • For Dev/Test, click where it says 1 phase, 0 task
  • Click the + icon to an Inline Powershell task
    • NOTE: if you don’t see this task, download it here. It’s an add-on for VSTS
  • Set the following properties.
    • I set the display name: Delete all existing content
    • Enter the following Script to run

  • Next up add an Extract Files task
    • Display name: Extract files
    • Archive file patterns: *.zip
    • Destination folder: $(agent.builddirectory)\$(Release.ReleaseName)

2017-12-18_22-30-32.png

  • Add an Azure File Copy task
    • Display name: File Copy
    • Source: $(agent.builddirectory)\$(Release.ReleaseName)
    • Azure Connection Type: Azure Resource Manager
    • Azure Subscription: (select your subscription; I’m assuming it’s already setup)
    • Destination Type: Azure Blob
    • RM Storage Account: (your blob storage account, for your SPA)
    • Container Name: name of your container. I’m using a variable, so it’s the same in both the scripts and here
    • Additional Arguments: /SetContentType

The last is an attempt to set the content type. It doesn’t work well, hence the next step which will set the content type for all the files /SetContentType missed

2017-12-18_22-32-53.png

  • Add another Inline Powershell task
    • Display name: Fix the Content Types in blob storage
    • Script to run is below

2017-12-18_22-38-07.png

Production Environment

  • In Environments, select Dev/Test and click Clone
  • Rename it Production
  • In your scripts change the container name to your production container
  • Go back to the Pipeline tab
  • Click the little thunder bolt icon to the left of your Production tab
  • In the window that opens tot he right click After release

You should now have something that looks like the following, at a high level

2017-12-18_22-49-24.png

Setup the Triggers

From here you need to follow the steps described in this blog post: Implementing CI/CD with GitFlow in VSTS

Done!

At this point you’re done.

If you deploy to develop it will go to your dev/test environment. Commits to release will ultimately end up in your production environment.

 

3 comments

  1. Hi! Thanks for the nice write up! I tried using your scripts inline first and then looked into what the Azure client could do to discover that both things could be achieved with one-liners. These can be inline scripts with one call in each step. It seems to skip other lines. Upload-batch even maintains the content-type from the source, so there is no need for the last step with these.

    az storage blob delete-batch -s $(containerName) –account-name $(serviceName)
    az storage blob upload-batch -s $(Release.ReleaseName) -d $(containerName) –account-name $(serviceName)

    I had real trouble with the service name during my process. I did finally manage to get it in running order and I’m happy, but finding the correct name I had given to a system some weeks ago took some finding.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s