Clarifying things about CI Factory
For the first time I annoyed someone in my blog. And for starters, such an high profile person as Jay Flowers.
He was a little annoyed about my last post.
Just to clarify things, because I don't want to annoy anyone, here is a little more explanation into the problems I found:
If you already have lots of projects to maintain, CI Factory is not for you.
And that is my opinion.
I think now it is clearly explained.
PS: this reminded me that I forgot to add info about me. Now you can know my face.
He was a little annoyed about my last post.
Just to clarify things, because I don't want to annoy anyone, here is a little more explanation into the problems I found:
- before the installation:
- We don't use Subversion. We are a Microsoft shop, so we are still using Visual Source Safe. I hate it, but that's how it is. CI Factory supports VSS, but it assumes you have a database per project. That is not our case, we have a central database with all the projects. I resolved this problem with a simple hacking into a couple of files. Problem resolved.
- CI Factory relies on Winrar to create packages to deploy to the project folder. We don't have a license of Winrar. I didn't want to use it, so I wanted to replace it with a free alternative. Enter 7Zip. This took a lot more work, because 7Zip has less options than Winrar and has a curious way of creating SFX, but eventually i managed to do it. Problem resolved.
- after the installation:
- Trash on the source control - before I even put my source files under source control, I already had 32.498.777 bytes in 507 files under 282 folders. This looks like a lot. In my humble opinion, most of this should not be under source control. Only build scripts, config files and similar things should be there.
- Project Structure messy - this is tied to the previous item. CI Factory creates the following structure:
- /<Project name>
- /Current
- /Build
- /lots of folders
- /Product
- /Install
- /Production
- /Unit Test
- /Third Party
- Your code should go under /<project name>/Current/Product/Production. It's just my opinion, but it looks a little hidden. With time you get used to it, but for starters looks like you are digging for your source. And under /<project name>/Current/Build is where I think things get messy. Under this folder are the executables to several programs (CCNet, nAnt, Simian, etc), temporary folders, log files, reports, etc. I know everything is related to build, but it is not organized. If it is not organized, it is messy. And I think support tools should be in Third Party, or something similar.
- One CCNet server for every project - if you have 30 projects under Cruise Control (as we have), having a CCNet for every project makes it a little hard to maintain everything, if you want to upgrade your server the task is going to take longer and is more prone to error. I know there is upgrade.bat, but I have to run it for every project I have...
- Replication - taking the example of our 30+ projects, you get several hundred megabytes of replicated stuff across projects. I know hard disk is cheap, but I personally don't like to have things replicated in that manner (and it is a burden to maintain).
If you already have lots of projects to maintain, CI Factory is not for you.
And that is my opinion.
I think now it is clearly explained.
PS: this reminded me that I forgot to add info about me. Now you can know my face.
Powered by ScribeFire.
4 comments:
Thanks for the response. :-)
So you might wonder WHY CI Factory uses one VSS db per project. Well that is because VSS has tremendous issues with large dbs. CI Factory is not shy about using memory in a source control repo, it is a best practice to have your entire product in the source control repo after all. So CI Factory would be leading you to certain doom, just kidding, if it enabled you to share a VSS db.
WinRar, well you can use a trial version for now. I was too frustrated with 7Zip to use it. I would like to look at what you put together.
TRASH! I have been very intensional about what CI Factory does. It does NOT put TRASH in the source control repo. This is a best practice that I agree with, to have every fricking thing that you need to build the product in the repo or at least codified in a workspace install script in the repo. What do you care how much is already in the repo? Does it affect you is a negative way? 6 months to a year from now if someone needs to go back to the a build that your team built today how difficult will that be without everything in source control. I think this is a sign that there is a big difference between what you think of as the product and what I think of as the product.
The messy part is your opinion or perception, I don't feel the need to assuage you of it. :-)
So you have 30 projects. This is one of the reasons WHY there is a CCNet server per project, WHY all that stuff like NAnt is in the project tree and shared on the build server. Let's keep it simple for the moment and say we have project A and project B. Project A has just released and is ready to do some infrastructure upgrades to things like CCNet. Project B is nearing a release and is very sensitive it infrastructure changes. Too bad for Project A, it can't make those upgrades because project B can't afford the risk. There are other reasons, but this is a comment on a blog post.
I have to go to work now. More later...
Okay, back for more...
I really only have one more comment to respond to and that is about maintenance. You have never had to maintain a bunch of CI Factory instances have you? You are guessing how difficult and or time consuming it will be. I on the other hand do have experience with this. It was never an issue for me and have never had anyone who was managing tens of instances comment to me about it being an issue. In fact I have found separate instances easier to maintain than shared. There are fewer potential issues when upgrading one project than many.
I was also a little leary about running may instances of CCNet also. I didn't think upgrading the full server would be a problem. But, Jay has a point that the isolation of each projects build server does allow you better control espesially if you only need to work on a single build.
I too don't like the use of WinRar. I think Jay should stick to Zip. He uses zip to create the release archive...(the stuff built into nany.) I think he to should use it for the workspace. Of course, you don't have to use the workspace package!
As far as having all the .exe's, dll's etc in source control... I've gotta say it really makes moving the CI server to another server much easier. Everything is encapsulated very well. And, it allows devs to run the same build scritps without worrying about what build tools are on their machines.
I'd also like to see him move away from using forks of NAnt and CCNet if he could. I think Nant is extensible enough for this to happen. Possibly CCNet isn't. I think CCNet should roll it JAy's extensions... same with Nant.
Being able to use the release versions of NAnt and CCNet would make support/help issues easier also.
But, all in all CI Factory is an excellent tool that has a good structure. It is easy to modify the factories behavior.
BOb
Could you post your changes to make 7-zip replace wrar?
Ricardo
Post a Comment