|
I have recently joined a company that is using Jenkins (i used to manage TeamCity in an enterprise environment for 250 engineers) and am having problems seeing how Jenkins scales using Perforce.
My problem is as follows:
Setup:
1 Slave with 1 executor
10 different builds all using the same stream
Current Jenkins behavior (to allow the Workspace browser to work) is to sync 10 different workspaces (all with the same code) and create 10 different client specs in perforce.
Now take a slave with 16 executors.
We now have 16*10 copies of exactly the same stream source code on the slave and 16*10 client specs in perforce.
Now scale it up to 50 different builds using 3 different streams with many slaves and the whole system just doesn't scale well from an IT storage and perforce access point of view....
What i was hoping to achieve (and this is how TeamCity and ElectricCommander does it) it to be able to share workspaces between builds.
If we created workspaces/clientspecs PER EXECUTOR then 2 builds can't use the source code at the same time.
So if a slave had 16 executors then there would only be 16 clientspecs and 16 workspaces for each stream and the builds won't clash since each executor can only do one thing at a time.
I am happy to loose the Workspace browser (that we never use) since this won't be valid anymore.
For this to work i would expect the change history tracking can't be stored on the perforce server side since the workspace/client spec is now shared so am not sure if this can actually be solved.
Any suggestions on how this can be achieved ?
This would be a big opportunity for Perforce to get themselves into Jenkins use for enterprise use. (that TeamCity and ElectricCommander has already done)
|
