Check out our end-to-end Java DevOps demo video on YouTube!

ON THIS PAGE we will show you how to start work by assigning the task to yourself and setting up a Continuous Integration (CI) build for validation.

Plan the Work

Throughout all of the webpages in this walkthrough, we will consistently use sample code written in Java and AngularJS. The project is called DeepSpace. All of our instructions in the walkthough webpages and the images (screenshots) provided will assume you are using this same sample code, but would also apply if you had your own code (with names changed appropriately).

Following the instructions on below, you will set up the infrastructure to start and validate the work you are about to commit. The exact steps are to 1) Navigate to the sprint board view; 2) Assign tasks to yourself and mark your progress; 3) Set up a build definition that builds code changes but does not deploy; and 4) Configure a branch policy to block pull requests that would not build if merged into the master branch for this build definition (Gated build).

Open the agile board

Now that you have defined a sprint and created a task and bug in this sprint, let's assign the work to ourselves so we can start working on them. First, let's go to the agile board view of the current sprint by clicking on the Work menu item (near left top of the Team Services page) and click on "Backlogs" just underneath this menu bar. Then, select "Sprint 1" under the "Current" heading in the left panel. Finally, click on "Board" on the right panel just under the sprint header.

Assign tasks to yourself and move it to "Active"

On the sprint board you should see cards that represent tasks and bugs that need to be completed. Hover your mouse over to the center of the story cards (the card with a blue vertical line on the left) to reveal the "Assigned to" field. Click on the field and select yourself from the drop down of team members. Repeat this for the task card (yellow vertical line) and bug card (red vertical line).

After you have claimed the work, drag-and-drop both the task card and bug card to the "Active" column.

Create a new build-only definition

Now let's create a build definition so we can set up a Gated build in the next step. From within your Team Services project, click on the Build menu item (near left top of the Team Services page), then right click on the First Build Definition we created in earlier steps. Select "Clone...".

At this point, we should be editing "First Build Definition copy". In the right pane, delete the "cURL Upload Files" task if it exists. Save the new build definition as "DeepSpace.PR".

Trigger this build-only definition on pull requests

Now that we have a build-only definition, let's configure a gated build so we are confident that all pull requests will merge and build cleanly against the master branch. From within your Team Services project, click on the gear icon next to your name (near top right of the Team Services page).

This will open the administration page in a separate browser tab. From the administration page, select the "Version Control" tab, expand the "DeepSpace" git repository in the left repository panel and choose the master branch. In the center panel click on "Branch Policies".

Check "When team members create or update a pull request into the master branch, queue this build:" and select the "DeepSpace.PR" build definition we created in the last step.

Save the changes by clicking the "Save changes" button at the bottom of the page.

Congratulations! You have assigned some tasks to yourself and created a gated build for verification to confidently commit changes into the master branch. Continue this walkthrough by following the next steps to make code changes and create a pull request.

Next Steps

Now you know how to assign work to yourself (or any other team members) and have set up a gated build for verification.

What's next?

Frequently Asked Questions (FAQ)

Q: What is a gated build?

A: A gated build is a build definition that automatically runs when a pull request is created against the target branch. It builds the merge result of the target branch and changes in the pull request to determine if it's safe to complete the pull request. The target branch is not updated when a gated build is running or when the gated build completes successfully. The target branch is updated only after the pull request is completed.