build-definition

Situation: I'm currently working on automating CI/CD configurations through bitbucket -> vsts -> azure. My ideal result is to be able to copy paste (or manually enter) my configuration values into their respective console programs and have the applications configure the whole CI/CD ordeal without having to click through all the web interfaces. It's now possible in Bitbucket and Azure, but creating the VSTS CI/CD configurations through REST API is proving to be difficult. Azure resources and Bitbucket configurations are currently created through a simple .NET console application that talks to

I have some TFS 2010 build definitions that were created under ProjectX. Now the source code has moved to a folder subordinate to ProjectY. How can I move the build definitions to ProjectY so they display under the Builds node of the Team Explorer for ProjectY? I don't think there is something out of the box to copy the build definitions from one project to another. However you should be able to do it using the TFS API. You will want to move the build process templates, which is what Pete is referring to, into the Build Process Template folder for the new project. After that you would do

I'm trying to set up a TFS 2012 build definition that will build a solution and deploy several web apps within the solution. I came across this article that seems to address exactly what I'm trying to do and also seems to agree with the solution mentioned here . So I tried implementing the build definition/project configuration as described in that article, but no matter what I do, it seems to be ignoring the parameters I put in the specific configuration property group of the csproj files which look like this: <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'MyConfig|AnyCPU' "> .

I've been working on a project for some time now and now I want to use Visual Studio Team Services for it. Locally, the building in Visual Studio doesn't give an error and the application works as intended. I've checked in this working code to VSTS so it's in the repo and good to go. Now I want to build it. I created a new Build definition with nothing changed . When I run the build it fails. I tried editing the build definition but with my 0 experience with this I only screw up more and create more errors. My problem: Apparently, it wants to find C:\a\1\s But I have no idea why and how it

For a build process template , we can add/remove/edit the argument list of it and use it as variables within the build/work-flow steps. I reading the nice guide here I'm cloning the template DefaultTemplate.11.1.xaml to sayHello-DefaultTemplate.11.1.xaml and edit it via Visual Studio 2012. I first added one argument, called TestMessage . I check in my changeset to the Source Control. Then I create a build definition sayHelloBuild based on this template. And when I go to the Process tab, I can see TestMessage in the Misc section. I save the build definition. Trying to queue it and it gets

I'm writing the Custom Activities of build process template. I got the below issue when build the activity. >XamlBuildTask : error XC1043: Extension 'Microsoft.Activities.Build.BeforeInitializeComponentExtension' threw an exception of type 'System.IO.PathTooLongException' : 'The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.'. Do you have any ideas? Please help! I find one tip here . Hope it might be helpful to you. Currently there are a two workarounds: Reduce the

I've been looking into TFS2010 new build and deployment features with MSDeploy. So far everything is going well (although its been hard to find information about specific scenarios). Can I modify my Build Definition to specify 2 or more servers to deploy to? What I need to do is deploy to multiple servers (as I have two in my testing environment which uses a NLB). What I have now is a Build definition which Builds, runs my tests, and then Deploys to ONE of my testing servers (which has the MsDeployAgentService running on it). It works fine, and each web project is deployed as configured in its