Evaluation Question - Personal Builds/Delayed Commit

Greetings:
I am currently evaluating TC and would like to hear other users real world experiences regarding this very enticing feature. I am actually still trying to get this feature to work as indicated by a previous post. So until I get that resolved I have some questions.

1 - How many Build Agents are really needed? We have close to 20 developers on one code base. Our builds take around 20 min each. With 3 agents, would the delay be too much to make an off-line build worth while? How many should I plan for?

2 - Will the delayed commit feature work with a laptop user that fires a delayed commit and shuts down?

3 - Is there protection against possible code concurrency errors (stale code) where many users are committing code with delayed commit and some have been stuck in the queue. Not sure if this question is relevant but they are questions asked of me as I am promoting the use of this tool in our shop.

Any info would be appreciated.

Thanks

2 comments

Jeff,

I will briefly answer from TeamCity team member point of view, but everyone is welcome to add their thoughts!

1. Depends to much on the team (commit rate, number of build configurations, peak hours, agents compatibility, etc., etc.). I'd say it's OK to start with only 3 agents in your case and see how it works. TeamCity allows to analyze how much a build waited in a queue and in 3.1 there will be agent load statistics - with it you can determine when more agents are needed.

2. Currently, actual commit is performed from the same computer that initiated the remote run. So, the code will get chance to be committed only after the project is opened in the IDE on the laptop again.

BTW, note that you can continue working on the same files after the delayed commit has been sent: if it succeeds, the files committed will be the same as they were initially sent, without later changes.

3. The issue seems to be inherent and actual without TeamCity either: if your local changes conflict with some other changes already in the VCS while you do all the checking/testing before the commit, you usually update/merge/recheck. The same in TeamCity. If your tool has local history support (like IDEA does) this may ease dealing with the cases.

It would be really interesting to hear other thoughts on the questions asked by Jeff.

--
Best regards,

Yegor Yarko
Project Manager
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

0

Jeff Mychasiw wrote:


1 - How many Build Agents are really needed? We have close to 20 developers on one code base. Our builds take around 20 min each. With 3 agents, would the delay be too much to make an off-line build worth while? How many should I plan for?



I think only you can answer this question: it really, really depends on
your team's working style. If you are used to checking your work in
often (several times a day) then 3 agents would probably just about be
enough for you but won't leave much room for experimentation. If you're
used to checking in once a day or less then it seems fine. (20 commits
in day for 20 minute build = 400 build minutes needed. 3 agents and an
8-hour day give 1440 build minutes available.)

Of course it also depends if people tend to check in all at the same
time, etc. Have a look at your team's commit history, you can probably
work out from that if you'll need more agents or not. Easiest way is
just to try it and see how it works for you.

Of course, as you discover more and more useful functionality in
TeamCity (e.g. adding more tests, pre-tested commit, ...) you will need
more and more build minutes, but at that point you will probably see the
value in buying them ;)

R

0

Please sign in to leave a comment.