Build your Node.js app with Gulp

VSTS | TFS 2018 | TFS 2017.3


Build and release pipelines are called definitions in TFS 2018 and in older versions. Service connections are called service endpoints in TFS 2018 and in older versions.

Follow these steps to set up a continuous integration (CI) process for a Node.js app using Visual Studio Team Services (VSTS) or Team Foundation Server (TFS).

As you walk through this quickstart, we'll ask you to choose:

  • Which kind of Git service you're using: VSTS or TFS, or GitHub.

  • How you want to define your build: in a web interface, or configured as code in YAML

  • For continuous deployment, what is your target: Azure web app or IIS server in a Windows VM, a Linux VM, or a Docker container.

As you choose from these options in the sections below, this topic will adapt to your choices.


  • A VSTS organization. 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 project you want to use.
  • While the simplest way to try this quickstart is to use a VSTS organization, you can also use a TFS server instead of a VSTS organization. Make sure that you have configured a build agent for your project, and that you have Node and Gulp installed on the agent machine.

Get the sample code

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.

You can copy this sample app code directly into your version control system so that it can be accessed by your CI build process. To get started, copy this URL to your clipboard:

Where do you want to keep your code? Whichever service you choose, our system can automatically clone and pull code from it every time you push a change.

To import the sample app into a Git repo in VSTS or TFS:

  1. On the Code hub for your project in VSTS/TFS, select the option to Import repository.

  2. In the Import a Git repository dialog box, paste the above URL into the Clone URL text box.

  3. 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.

Web or config as code

Do you want to define your build process in your web browser or configure it as code in YAML?

Choose this option if you want the advantages of configuration as code. This means your pipeline is versioned with your code and follows the same branching structure as your code.

- script: echo hello world 

Get started with YAML builds.

YAML builds are not yet available on TFS.

Create the CI process pipeline

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 pipeline that helps your team keep the master branch clean.

Begin by creating your build pipeline.

To create a pipeline that is configured as code, you'll modify a YAML file in the repo root that has a well-known name: .vsts-ci.yml. The first time you change this file, VSTS automatically uses it to create your build pipeline.

  1. Navigate to the Code hub, choose the Files tab, and then choose the repository you created in the above steps.

  2. Choose the .vsts-ci.yml file, and then choose Edit.

  3. Replace the contents of the file with code from the next section.

Choose your deployment target

While a CI build process is a powerful way to do day-to-day development, continuous deployment is how many teams accelerate how they deliver value to customers. After each successful CI build, you can automatically deploy your app.

To get ready for continuous deployment, choose which kind of deployment target you want, and then adjust your CI process as needed.


- task: Npm@1
  displayName: npm install

- task: Gulp@0
    publishJUnitResults: "true"
  displayName: Gulp

- task: ArchiveFiles@1
    rootFolder: "$(System.DefaultWorkingDirectory)"
    includeRootFolder: "false"
  displayName: Zip up the files

- task: PublishBuildArtifacts@1
    PathtoPublish: $(Build.ArtifactStagingDirectory)
    ArtifactName: "drop"
    ArtifactType: "Container"
  displayName: Publish the artifacts

Commit the above change to the master branch.

Finish the CI process pipeline

You're nearly ready to go. Just a few more steps to complete your CI build process.

  1. Navigate to the Build and Release hub.

  2. Observe that there's a new build pipeline named {name-of-your-repo} YAML CI. A build is queued; its status could be either not started or running. Choose the number of the build: {year}{month}{day}.1.

  3. In the left column of the running build, select Job. After an agent is assigned to your job and the agent is initialized, then you'll see information about the build in the console.

View the build summary

  1. Once the build completes, select the build number to view a summary of the build.

    Navigate to build summary

  2. 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.

Next steps

You've just put your own CI build process in place to automatically build and validate whatever code is checked in by your team. What do you want to do next?

Deploy your app


Make sure you followed the deployment instructions above with the Azure web app or IIS server tab selected.

See one of the following:

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: