Build your Node.js app with Gulp
VSTS | TFS 2018 | TFS 2017 Update 3
Follow these steps to quickly set up a CI process for your Node.js app using Visual Studio Team Services (VSTS) or Team Foundation Server (TFS). The sample app we use here is a Node server that echoes "Hello world". Tests for the app are written using mocha framework. A gulp file is used to run the tests and to convert the results into junit format so that they can be published to VSTS or TFS.
- A VSTS account. If you don't have one, you can create one for free. If your team already has one, then make sure you are an administrator of the team project you want to use.
- While the simplest way to try this quickstart is to use a VSTS account, you can also use a TFS server instead of a VSTS account. Make sure that you have configured a build agent for your team project, and that you have Node and Gulp installed on the agent machine.
Get sample app code
Before configuring a CI build process for your app, the source code needs to be in a version control system. Copy the sample app code from the following repository to your version control system:
Choose your version control system to get specific instructions for copying the sample app code:
To import the sample app into a Git repo in VSTS or TFS:
On the Code hub for your team project in VSTS/TFS, select the option to Import repository.
In the Import a Git repository dialog box, paste the above URL into the Clone URL text box.
Click Import to copy the sample code into your Git repo.
You can use also use Team Foundation Version Control (TFVC), Subversion, Bitbucket, or any other Git repository for managing your source code, and still use VSTS for CI.
Set up continuous integration
A continuous integration (CI) process automatically builds and tests code every time a team member commits changes to version control. Here you'll create a CI build definition that helps your team keep the master branch clean.
Create a new build definition.
In the right panel, search for
node, select NodeJS with Gulp, and then click Apply.
You now see all the tasks that were automatically added to the build definition by the template. These are the steps that will automatically run every time you check in code.
For the Default agent queue:
VSTS: Select Hosted VS2017. This is how you can use our pool of agents that have the software you need to build your app.
TFS: Select a queue that includes a Windows build agent.
Click Get sources and then:
Select the Run gulp task from the tasks. On the right side, you see the parameters for the task. Under the section JUnit Test Results, select the option to Publish to TFS/VSTS.
Select the Archive Files task and either remove it or, in the Control Options section of the task arguments panel, uncheck the Enable checkbox.
Select the Copy Publish Artifact task, change the Copy Root argument to
$(Build.SourcesDirectory)and the Contents argument to just
By default, the build template creates a ZIP file for deploying to Azure Web Apps or a Windows VM. These changes cause the build to generate a set of uncompressed files and folders suitable for deployment to a Linux VM running the nginx web server.
Click the Triggers tab in the build definition. Enable the Continuous Integration trigger. This will ensure that the build process is automatically triggered every time you commit a change to your repository.
Click Save and queue to kick off your first build. On the Queue build dialog box, click Queue.
A new build is started. You'll see a link to the new build on the top of the page. Click the link to watch the new build as it happens.
View the build summary
Once the build completes, select the build number to view a summary of the build.
Notice the various sections in the build summary - the source version of the commit in build details section, list of all associated changes, links to work items associated with commits, and test results. When the build is automatically triggered by a push to your Git repository, these sections are populated with all the relevant information.
You've just put your own CI build process in place to automatically build and validate whatever code is checked in by your team.
Extend to other Git workflows
Now that you have a CI build process for your master branch, you can extend the process to work with other branches in your repository, or to validate all pull requests. See:
Deploy your app
|If you want to deploy to a...||Then publish your artifact as a...|
|Azure web app or to an IIS server||.ZIP file. In this case you're already good to go after following the above steps. Next step is one of the following:|
|Linux VM||Simple folder. To do this, follow the additional instructions here. Next step is: Deploy to a Linux Virtual Machine.|
|Container service (such as Azure web apps for containers, or a Kubernetes cluster)||Container. Next step: Build and push a container for your app.|