CODEWITHSUNDEEP
tfscontinuous-integrationazure-devopstfsbuild
codingpirate
codingpirate

Reputation: 1414

Configure CI Builds and Releases when VS-team-services workitem status changes

I am trying to find out if I can configure CI Builds and Releases when a TFS workitem status changes.

As an example - When a workitem is moved from the Dev status to QA in the Kanban Board (using TFS online), a CI build/release is kicked off and changes are deployed to the QA Instance.

Upvotes: 2

Views: 198

Answers (2)

starian chen-MSFT
starian chen-MSFT

Reputation: 33738

First, refer to Daniel’s answer.

Secondly, regarding your requirement, you can create a web hook to track work item state and send a request to your web app (e.g. web API, need to be accessible from internet), then queue build by calling TFS/VSTS Build REST API.

  1. Click Settings
  2. Select Service Hooks
  3. Click + to create a new subscription
  4. Select Web hooks > Next
  5. Select Work Item update event (Trigger on this type of event)
  6. Specify area, work item type and field (state) >Next
  7. Specify URL (your web app URL)
  8. Specify Http headers if needed (e.g. build definition id)

Simple C# code to queue build. (Install Microsoft Team Foundation Server Extended Client package)

 var u = new Uri("https://[accout].visualstudio.com");
            //VssCredentials c = new VssCredentials(new Microsoft.VisualStudio.Services.Common.WindowsCredential(new NetworkCredential("[alternative username]", "[password]")));
            VssCredentials c = new VssCredentials(new Microsoft.VisualStudio.Services.Common.VssBasicCredential(string.Empty, "[personal access token]"));
            var connection = new VssConnection(u, c);
var buildServer = connection.GetClient<BuildHttpClient>();
var build= buildServer.QueueBuildAsync(new Build() { Definition =new DefinitionReference() { Id=[definition id]}, Project= "[team project]" }).Result;

Upvotes: 1

Daniel Mann
Daniel Mann

Reputation: 59055

No, and I'd say that trying to track the environment a user story is currently deployed to via kanban columns is a bad approach.

A user story isn't a discrete item that you can move individually from one environment to the next. A user story is a collection of changes that make up the implementation of that user story. A build isn't a build of one user story, it's a build of the entire codebase at a point in time.

You wouldn't trigger a CI build as part of work management, you'd trigger CI in response to changes to your code, because that's what CI is: a practice that marries small, frequent commits and integrations between your development branches with automated builds and tests.

Instead, tie your commits to user stories/tasks and define a deployment pipeline using the Release hub. As your user story is promoted between environments, you'll be able to see within the user story which environment it's currently deployed to.

Upvotes: 2

Related Questions