|
|
They're pointless. If you think you need them, you likely have a problem in your process.
|
|
|
|
|
Do you run unit tests yourself?
What if you have 50+ developers working on 90+ different assemblies/products. The code works on my machine (TM), but that is because I don't have Sallie's latest changes. A build server always has the most recent code.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb]
Jonathan C Dickinson (C# Software Engineer)
|
|
|
|
|
"build server always has the most recent code. "
for this purpose a source control system (SVN) is enough so why use a build system ?
|
|
|
|
|
I am not sure if you caught my drift. Lemme put this in a sequence of events:
1. You are fixing a bug, but find one thing that isn't your responsibility.
1.1 Certainly, in my work environment, people have areas of responsibility and no one else must mess with their code.
2. As such you ask the person responsible, Sally, to fix their code and make the change yourself locally.
3. You check in and assume everything works.
4. You tell the build master to make a new build, but Sally didn't have time to fix the bug herself.
5. You now have a very valid It Works On My Machine case.
6. John gets the latest code, builds it, and sends it off.
SVN (actually all version control systems, I think) is great at maintaining one code-base, but you forget: there are different sets of code for each developer that they have on their machine. The interaction of this code can result in code that only works on that developer's machine. Some even try to help prevent this (e.g. TFS won't let you even edit code if someone has locked it), but most of the time you can just go into 'offline' mode and do as you wish.
Some projects/assemblies/libraries don't get built by each developer (especially on very large solutions/products). A bug fix and cause a new bug. Put these two together.
Futhermore, there are often cases when small nuances on developer machines result in code working when it shouldn't. A build server is pretty much isolated.
All-in-all it's up to you to decide if you want a build server or not: but for us it really decreases risks.
However, one point that is important is: if your build server doesn't do unit tests then scrap it.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb]
Jonathan C Dickinson (C# Software Engineer)
|
|
|
|
|
well i still don't fully understand : if Sally didn't correct her bug, you should see it in your Mantis or any bugcollector software
We're working on a 5 millions line project and never felt the need of something to handle our builds... but no problem if someone does
|
|
|
|
|
It wasn't a perfect example (I am not entirely bothered to come up with one ). In summing, one bug fix can cascade bugs into other components, something that would be picked up by the build server (running unit tests) almost instantly.
Admittedly, you could check these all with one final unit test run before you ship, but if they are picked up on-the-fly you can fix them without the stress of the release being on the next day.
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb]
Jonathan C Dickinson (C# Software Engineer)
|
|
|
|
|
Jonathan C Dickinson wrote: What if
It's a big what if, especially if you're the only one working on projects.
|
|
|
|
|
I agree entirely with that! If you are a lone ranger having a build server is overkill (unless you are bored and want to waste a week setting it up ).
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb]
Jonathan C Dickinson (C# Software Engineer)
|
|
|
|
|
PIEBALDconsult wrote: They're pointless. If you think you need them, you likely have a problem in your process.
What kind of problems?
|
|
|
|
|
Inferior operating system.
Inferior code management system.
Inferior build process.
Inmates running the asylum.
|
|
|
|
|
PIEBALDconsult wrote: you likely have a problem in your process.
Every software development process is a problem in itself, since it's inherently complex and error-prone. (If software development would't be a problem, so what does a developer then get paid for?)
There are some ways to control and dispatch these problems (e.g. unit tests) - they all require an automated build process to be really helpful. Automated builds are intended to keep problems small and manageable and not letting them escape to the wild.
There may well be numerous software projects that have good reasons for not using an automated process. But if a developer categorically refuses to consider having one, he likely is the problem.
Regards
Thomas
www.thomas-weller.de
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. Programmer - an organism that turns coffee into software.
|
|
|
|
|
We're in development mode - one or two beta sites. Builds get done, from he trunk of the development source in Subversion (Branching? Why would you?) manually, then shipped out to the clients.
Of course, some checking is done before sending it out... the 'build guy' (he's a director) pops his head round the door and asks if anyone checked n anything 'that might break it'.
Automated builds? Shmautomated builds !
Life is like a pubic hair on the toilet seat...
...sometimes, you just get pissed off.
.\\axxx
(That's an 'M')
|
|
|
|
|
Same here. If you check it in it means it works.
|
|
|
|
|
If I performed them they wouldn't be automated, now would they?
|
|
|
|
|
We have a build farm that automatically builds all current code lines of all our products every night; when it works [1].
When we are doing releases we use the same farm to produce labelled release builds.
[1] I made a small /improvement/ yesterday. The builds on three lines, about 50 product builds, didn't run. So as I write about our lovely automatic process, I'm running manual builds of all the code lines.
Panic, Chaos, Destruction.
My work here is done.
|
|
|
|
|
williamnw wrote: So as I write about our lovely automatic process, I'm running manual builds of all the code lines.
Welcome, brother.
I'm the keeper/inventor/curser-atter for our build process as well. Ours is a combination of a Windows application, VBscript, and a couple batch files that run the various processes to build our products. Debugging it's a PITA, since our builds take an hour. Given that we may do several builds in a day, if I need to make a change to the build process, I often have to get it right the very first time. If I don't, I end up with whiny, pissed-off people in my cube, and that's just annoying .
Software Zen: delete this;
|
|
|
|
|
Gary Wheeler wrote: I end up with whiny, pissed-off people in my cube, and that's just annoying
My solution to this is that I have I mug and on it is written 'Grumpy Old Man'. I have nurtured my reputation as a bad-tempered SOB. The code monkeys fear my wrath should they become 'wingeing-whiny-snot-noses'. I'm also the one who goes over to them and informs them, diplomatically of course, that they've broken the build with their kack-handed attempts at writing code.
'Part from that, I'm a sweetie.
Panic, Chaos, Destruction.
My work here is done.
|
|
|
|
|
Hmm. My mug, presented to me by my daughter three years ago, reads "Professional Smartass".
Software Zen: delete this;
|
|
|
|
|
Mine came from darling Mrs Wife.
Panic, Chaos, Destruction.
My work here is done.
|
|
|
|
|
|
I should have added that builds that leave the developers for alpha/beta test are automated to assure consistency and all components are versioned accordingly.
|
|
|
|
|
Yes it does. We have HTML/CSS/JavaScript projects that get "built." The point of the build is to run tests and produce a deployable package. And builds lead to build numbers which make issue tracking much easier than "oh, that release with the button that looks a bit squiff in IE6."
(Possibly not a technically correct usage of the term "build" but in practice it is what we need.)
|
|
|
|
|
Just curious - does anyone have experience with multi-computer (clustered) builds?
|
|
|
|
|
We use incredibuild for our own personal builds; don't know if it's used for the daily builds (I'm not in charge of that), since it's not really
important that it takes more or less time.
(edit)
It works very well, and will save lot of time on a full rebuild. in our cases, we can go from 45 minutes (on my slow machine) to 6 minutes with all
CPU used. When the build is dispatched, it looks at the load of the machines and will use or not a machine according to it.
Having multicores also really helps.
|
|
|
|