> > > I'm thinking of a clunky approach of including tests with names starting > with [A-Ma-m] in one build configuration, and those with names starting > with [^A-Ma-m] in another build configuration. These build configuration > could have most of their actual configuration in a build template, and only > specify the differences separately, which would be the regex. > > Yeah.. I've thought about that too.
The big thing you have to worry about is if all your tests end with or start with "Test" which is why I was thinking of the hashing approach. But I guess this will work as long as you're careful. > My organization is also using TeamCity and Maven, and is about to embark > on using (again) build chains in TeamCity, which would allow to define > these two (or whichever many you desire) build configurations, and pull > them together somehow. > > I think this is the hard part. One would needs to merge all the test reports in Teamcity. Not sure if it supports this already. How do you use chains to get them to work in parallel? I thought that this would only work if you do them sequentially - which won't yield much of a speedup. But I do think the 'dependent build configuration' thing might work. Right now we first run an incremental build, and that then fires up a full build. Maybe one solution is to first compile all the code, and then have that trigger N chained builds at the same time. This way you quickly confirm that the code compiles, and then that can trigger all the secondary builds. Of course that might be redundant and just waste 1-2 minutes. Might be better to just have a quick 'return true' script that always works and then have that kick off your two parallel builds. Maybe aggregating the tests output isn't strictly necessary since Teamcity shows them in the UI... We would be using this approach to split up, and parallelize unit tests vs. > (module) integration tests vs. some end to end tests (cross-module > integration tests). Some of these tests live in a separate Maven module > already, which I'd call a best practice for cross-module integration tests. Yeah.. we do the same thing. > I'm curious to hear what you come up with and/or settle on. Please report > back! > Will do.. actually I think talking this through made it seem a lot easier. -- We’re hiring if you know of any awesome Java Devops or Linux Operations Engineers! Founder/CEO Spinn3r.com Location: *San Francisco, CA* blog: http://burtonator.wordpress.com … or check out my Google+ profile <https://plus.google.com/102718274791889610666/posts>
