|
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.
|
|
|
|
|
is the reduction in compilation times directly proportional to the number of cores running the build?
|
|
|
|
|
no, because you never know (using non dedicated computers) if the people are working or not on their PC.
Like everything parallel, it's never directly proportional.
|
|
|
|
|
Yep - some 5 years ago I was involved in making a build system (with Perl ) that was using multiple machines to build our machine translation system.
As for my current job, I am not even sure how it works - there are full-time build engineers that take care of it, but I bet they do use clustered builds.
|
|
|
|
|
On linux all the time since this is very easy to do and the required software for this is opensource and free. On windows (using microsoft compilers) the answer is no because the required software is too expensive.
John
|
|
|
|
|
I was actually amazed that the XCode IDE, used to build Mac and iPhone applications, has an option for clustered builds built-in. I mean, why don't we just have this 'by default' in Visual Studio?
|
|
|
|
|
Visual Studio 2008 does, in a way. If you have a multi-proc/multi-core system, it will compile multiple projects at once when building a solution.
Software Zen: delete this;
|
|
|
|