问题
for some time my company is now using Maven and TeamCity to build Java stuff. Currently we are investing quite heavily in continuous integration and ultimately continuous delivery.
Among many smaller applications (apps) we are operating one big monolith app with approx. 1 million LOC. This app on quite a big build agent takes 5 minutes to compile (incl. 2 minutes svn up). Its 12k unit tests are running for another 5 minutes. Deploying the build results to Nexus takes at least 10 minutes.
To provide fast feedback to developers we try to split the the amount of work to be done in different build tasks. Currently we are using the following setup:
- Step 1: Compile everything (5 mins) and if it fails, abort the chain. Trigger the build on SVN changes.
- Step 2: Compile, Verify and Deploy. (20 to 40 mins, mostly depending on Nexus and/or network performance) Define a snapshot dependency to Step. Trigger the build on SVN changes, but only if snapshot dependencies have changed.
The good part about this: Step 2 is only built if there is a successful build with changes of Step 1.
There is a major drawback to this approach: Step 2 does everything Step 1 did already. And if I am to introduce deploying to a test system as Step 3 and browser-level Selenium tests as Step 4 a lot of things are going to be executed twice or thrice.
Alternatives we tried:
- Configure Step 2 to run on the same build agent as Step 1 but the svn up would be done anyway so no advantage here. Only thing that would be a little bit better: Maven caching.
- TeamCity Build Steps. As far as I have learned they provide hardly any advantage to separate build tasks with the downside of lacking intermediate build-results.
Does anybody know a better approach how to set this up better?
Thanks a lot, Stefan
回答1:
We did now go for a week with snapshot dependencies and I have grown to like them, besides their inefficiencies.
TeamCity does display dependency problems on builds and there is a documentation page dedicated to Build Chains telling that this is exactly the way how such problems are solved.
So thanks to those who had interest in this question. I will close it now.
回答2:
A possibility that I wanted to share myself, though I am not sure if one should do this. The goal ist still to shorten feedback cycles:
The deploy to Nexus is a bottleneck because it takes 10 to 20 minutes (depending on network and Nexus) whereas the remainder of the steps is 10 minutes overall as well. I noticed that we are deploying to Nexus more than necessary for continuous integration: not only Maven artifacts but deliverables as well, like rpms or wars. It might be that half of the deploy time is just because of this.
We could setup a third step "Step 3: Build Deliverables". That could be based on an own POM for that problem in order to avoid that everything is compiled and tested. This POM would have a snapshot dependency on the Maven artifacts created in the 2nd step.
But I am not sure if this is best way to do such things in Maven or TeamCity. Still I am hoping for other solutions or thoughts.
来源：https://stackoverflow.com/questions/6942764/what-is-the-preferred-way-to-setup-a-continuous-integration-build-chain-for-a-bi