I have a solution file with multiple projects that I am trying to configure for continuous integration on a development server using Team Foundation Server. I would like to customize this to only deploy the changes that were checked in.
Scenario example
Projects
My Project (MVC app)
Logic Layer
A user checks in a new Home.cshtml file and updates a code file in the Logic Layer. I would like to configure the automated build to just build the following package:
My Project
bin/MyLogic.dll
Views/Home.cshtml
What steps are done to achieve this scenario?
You want an incremental build, though I don't recall if it was supported back in TFS 2010.
Try configuring the build to not clean the workspace. Set the "Clean Workspace" property in the "Basic" section to "None".
Then, it will keep the binaries from the previous build, and, just like Visual Studio, will only build targets for which the inputs have changed.
Related
I maintain our build process on our TFS 2012 system.
Up till now I've been making changes locally to a solution that generates our custom activity DLLs. These DLLs are checked into TFS and are used by the build controllers and agents for the custom activities in our custom build template.
For all of my code and workflow activities I have a unit test library that I can locally run to put in some base test values. While this gives me a good idea at how my custom tasks will run it is not optimal.
What I would like to be able to do is run the entire build definition. Is there a way to test the whole build process locally so that I can be sure that my changes to the workflow are acceptable before checking in and kicking off a build? Right now my builds take between 30 and 40 minutes to complete and I would like to be able to start, monitor, debug, and stop the build locally without occupying one of our agents.
Edit
Another method for me to solve this problem is to come up with some manner to execute the workflow that is the build template locally. Has anyone been able to do this?
Take a look at the Ranger Build Customization Guidance. There is a HOL for doing a lot of this. It doesn't look like it is in v2 so take a look at v1.2.
http://vsarbuildguide.codeplex.com/releases/view/87995
If I am understanding the issue correctly, one way to do this may be:
Install a build agent locally and register it with the TFS Build Controller.
Give the new agent a custom tag so it doesn't get assigned other builds from the queue
Shelve your changeset
In VS, right click the build definition you want, and select queue new build. A "Queue Build" window will open
Under the general tab, "What do you want to build", select your shelveset.
Under Parameters tab ->Advanced -> agent settings, enter your agent's tag.
Click queue.
I accomplish this using a modified version of #malexander recommendation.
Create a code branch in TFS, commit your changes there, especially the changes to your custom activity DLL's (compiled binaries, not just source).
Install a TFS Build Controller and Build Agent locally, registering the controller with your TFS server.
Configure your new local controller to use your modified custom activity DLL's, stored in your new TFS code branch. Team Explorer > Builds > Actions > Manage Build Controllers >
(select your new local controller) > Properties > Version control
path to custom assemblies
4.
Queue a new build, from an existing TFS build definition: change its controller to use your new local controller.
The new build will execute on your local controller/agent, using your modified custom activity DLL's, without interfering/restarting your production agents.
Also: since you're in your own code branch, you can commit debug versions of your custom activity DLL's, without impacting your production agents.
I have created 3 continuous integration builds under same source control folder i.e under one TFS folder, there are 22 projects and 3 solutions under this folder, each solution contains some shared projects. I have created a continuous integration build for each of the 3 solution files. The problem is whenever anyone checks in under any solution all 3 builds are triggering. Is there any way to trigger the related build only if there is any check-in under the any solution ? Please let me know how to configure 'Items to build' and source setting tabs in TFS 2012 ?
TFS 2015u1 and older
The Source Control Folders in the mapping govern when a CI build triggers, nothing else. A custom Activity might be able to check that no changes were made in specific folders and prematurely stop the build, but that requires you to create a custom activity and customize the workflow.
Normally you'd place each solution and its projects in their own folder in Source Control, that way you can create a source control mapping for each specific CI build.
TFS 2015 update 2 and onwards:
The new build engine supports separate definitions for workspaces and triggers.
Ok so I have to admit, I'm very new to all of this build automation stuff. But basically what I'm wondering is if there is a way to wire up my build definitions in such a way that if I have a case like so
ProjectA produces ComponentA.dll
ProjectB references ComponentA.dll and produces ComponentB.dll
ProjectC references ComponentB.dll
then when I make changes to ProjectA and check them in, the build process would automatically also build ProjectB, and finally ProjectC, and report any errors.
So is there a way to accomplish this, or should this type of thing be handled somehow completely differently in the first place?
The process you are referring to is the crux of the practice known as Continuous Integration.
TFS does it very well: simply set your build definition Trigger to Continuous Integration and set the Workspace working folder to the parent folder of the three projects. This way, any change in one of the projects will trigger a build.
MSDN: Build and Deploy Continuously
You can use a visual studio solution and use project references between the projects. Then build the solution on your build server.
Is there a way to create a build definition, in TFS 2010, that uses continuous integration trigger, and only builds the project who's code changed.
To clarify, what I'm searching for is the following scenario:
1 Solution
x Projects in Solution
1 Build Definition per Project
All Builds are CI triggered
When a check-in occours in a project only that project gets built and tested.
Place in your build definition's "Items to build" section of the "Process" tab any *.*proj instead of a *.sln.
In the "Workspace" section, select only the source control paths that relate with this project.
In the process tab, set "Clean Workspace" to "None", use "/t:Build" on the "MSBuild Arguments" and properly configure your projects and their dependencies in the solution. This way on each build, you will be getting the latest code, and then building whatever was modified, and anything that depends on it. This is much more dynamic and requires only one build definition. Let the build system operate as it was designed and leverage the optimized build process.
I am trying to set up continuous integration using Visual studio 2010 and TFS 2010 and when i try to Create a new build definition, and go to Process Tab, i dont see any templates under the Build Process file(Windows workflow XAML) drop-down.
I have setup a build controller that points to our Team project collection and a build agent, in our TFS server.I am trying to setup a new build definition from my local machine Visual studio and i cant see any default templates under the Build Process file(Windows workflow XAML) drop-down.
Is there any settings i am missing ?Please let me know. Do i also need to install Visual studio in the TFS Server ?
All i need is whenever someone checks in a file, it should kick off a build and see the status if the build is broken or not !
Make sure you have a folder inside your Team Project Source Control called:
BuildProcessTemplates
Inside of there should be the following files:
DefaultTemplate.xaml
UpgradeTemplate.xaml
There are additional ones in this example, but you should have those two from the install.
If you have this folder and still cannot see anything in that dropdown let me know and we can take it from there. What most likely happened is you or someone on your team saw the folder and deleted it or moved it thinking it its placement wasn't important in the project. Or perhaps deleted the xaml files inside there.
The process section uses that folder and all files within it to display on that prompt.