This flexibility will allow you to build better software by reducing the likelihood of not having a certain dependency on the target machines.įigure: Setting the name filter based on server location For example, your Agents might be “SYDVMAPTFSBP01” and “SYDVMAPTFSBP02” so a name filter of “SYD*” would target all of the Sydney build agents.įigure: Agent names can be used for filtering as well You can also use name filtering, so if you have a good Agent naming convention you can filter by that for regions. You just select from the list of available tags and the controller will make sure you get to a build agent that uses them.įigure: I want Silverlight, VS2010 and WIX, but do not care about Location.Īnd there you go, you can now have build agents for different purposes and regions within the same environment.
The next thing to do is look for specific tags. The quick way to fix this is to change the “Tag Comparison Operator” from “ExactMatch” to “MatchAtLease” to get your build immediately working.įigure: Tag Comparison Operator changes to MatchAtLeast to get builds to run. This is because the default setting for a build is to look for an Agent that exactly matches the tags for the build, and we have not added any yet. Once you have your Build Agents all tagged up ALL your builds will start to fail We may change to using a more generic tagging structure (Like “Web Application” or “WinForms Application”) if this gets too unwieldy, but for now the list of tags is limited.įigure: Tags associated with one of our build agents that way developers can find the things they need. One thing you can do to make things easier is to create a tag for each of the things that you install. For a website that means something different to a client than to a server, but I am sure you get the idea.
#TFS ADD BUILD TAG INSTALL#
You should not install things that will not end up on the target users computer. So, some of the things you may install are: For me that means anything that does not add a *.target file is suspect, and should really be under version control and called via the command line from there. My ethos for build servers is to keep them as clean as possible and not to install anything that is not absolutely necessary. This software is required for only one of the many builds we have set up.
For example only one of these agents has FTP software installed. Select “ Build | Manage Build Controllers…” to get a list of all of your controllers and he build agents that are associated with them.įigure: the list of build agents and their controllersĮach of these Agents might be subtly different. You can add a set of Tags to your agents and then set which tags to look for in the build definition.įigure: Open up your Build Controller Manager What about a geographically diverse team? If you have a centrally controlled infrastructure you might have build servers in multiple regions and you don’t want teams in Sydney copying files from Beijing and vice a versa on a regular basis. Inevitably you will need to install components that you would expect to be installed on target computers, but how do you keep track of which build servers have which bits? The way to combat this is to have more build servers, but with that comes complexity. That could mean that you have a broken build every day! Gated check-ins help, but they have a down side that manifests as queued builds and moaning developers. Lets say you have 30 developers and each developer breaks the build once per month. The benefits are based on the number of developers you have working on your project. At SSW we use gated check-in for all of our projects.
0 kommentar(er)
