Build your Node.js app with Gulp
VSTS | TFS 2018 | TFS 2017.3
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 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 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:
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.
Web or config as code
Do you want to define your build process in your web browser or configure it as code in YAML?
Create the CI process definition
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.
Begin by creating your build definition.
Navigate to the Files tab of the Code hub, and then choose Set up build.
You are taken to the Build and Release hub and asked to Select a template for the new build definition.
In the right panel, search for
node, select NodeJS with Gulp, and then click Apply.
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.
All the tasks you need were automatically added to the build definition by the template. These are the tasks that will automatically run every time you push code changes.
Select Tasks. 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, make sure the option to Publish to TFS/VSTS is selected.
Proceed to finish the CI process definition.
Finish the CI process definition
You're nearly ready to go. Just a few more steps to complete your CI build process.
For the Agent queue:
VSTS: Select Hosted Linux. 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.
Select Get sources and then:
Observe that the new build definition is automatically linked to your repository.
Select 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.
Choose Save & queue to kick off your first build. On the Save build definition and queue dialog box, choose Save & queue.
A new build is started. You'll see a link to the new build on the top of the page. Choose 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. 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: