For example, I have a framework Component and I have an application which has a binary reference to this framework component.
If the framework component is changed, I would like this to be built. I would also like the application which has a binary reference (and any others which do) to be built. Is there a way which I can do this?
You didn't specify how your CI build was being kicked off, whether through some custom web service notified by the TFS app tier or through some other mechanism like CruiseControl.Net.
In my case, each dev team has a CI process running. The team that currently owns the "Common" TP has a CI build that has CCNet watching my TFS repository for changes to the specific team projects they are responsible for. Their configuration has CCNet watching the full series of TPs that make up their app and if any one of them changes, the entire string of Team Builds are kicked off and run in order from low-level to high-level.
I have other teams that also use the "Common" TP's binaries. Those team's CIs pull the Common binaries from the nightly build each morning and use them for the entire day. They find integration problems the next morning and are no more than 1 day behind the dev team that owns "Common". If they need to have quicker feedback to breaking changes to "Common", they grab the binaries from the other team's CI build instead of the nightly build. In that case, they are only 1 or 2 builds behind any breaking change.
We are still hashing out this pattern, but it seems to be working well so far. I'd be interested to hear what others are doing in this area.
- Steve
We are still in the stage of picking a CI application to use. Are there any suggestions as to which is the best one to use? I believe there are 3 options to choose from, CC.net, Automation and another one .... any suggestions?
My company is using CCNet with the TFS extensions and firing TFSBuild.exe. This is the simplest to maintain and, for now, gets us up and running quickly. We also like the benefit of CCTray to notify the team when builds pass/fail. We are still working on incorporating the build logs into CCNet's portal, but I don't think it will be a daunting task.
As to the other products, I can't speak to them as I haven't used them. The most pressing questions are 1) is it easy to setup, 2) is it easy to maintain. This is not something that should take inordinate amounts of care & feeding.
- Steve
I agree that the CI product which we use should be easy to set up. I am leaning more towards either Automation or TeamCI. I am not quite sold on CC.Net yet, as I believe this uses polling to wait for check-ins where as Automation uses an event-driven model (which seems more desirable to me). Also, Automation is built using the web service model that TFS supports, so it seems like a logical choice for use.
Any other suggestions?
The dependency feature of TFS Integrator is interesting and something similar might end up in Automaton. TFS Integrator is a Windows Service only that triggers builds in the background, and it uses an XML based configuration that you have to setup manually.
Automaton (not Automation as you mentioned earlier: http://dictionary.reference.com/browse/Automaton) has a primary goal of having as little (manual) configuration as possible. If a dependency build feature is added in the future, it will most likely be configureable from the web dashboard.
Sorry for the obvious 'advertisement' here, I just wanted to let you know :)
