|
I'm not sure what automated builds are, can anyone explain me?
|
|
|
|
|
In the context of this question, automated builds operate as follows:
A distinct machine (typically referred to as a build server) monitors the application source code.
When the machine determines that code modifications have been made, it runs some kind of build process (e.g. make), typically including some minimal testing. Some build machines - like ours - do more than just the minimum and go so far as to generate a full installation package or an ISO CD image that can be picked up for additional testing (usability, etc.) by the QA department at any time.
The important feature (at least in my mind) is that the build machine is not used for regular development. This reduces the risk of a "tainted" system where the build happens to work because a certain file, registry entry, or environment variable exists. It also quickly points out if someone has been a doofus and failed to update or place a vital code module under source code control. It also means that developers do not have to "waste time" generating a final build as the build server will do so automatically and they can continue with their next task.
As others have observed, a fully automated build is not essential, but (again IMHO) it is highly desirable in a multiple-developer scenario especially where multiple products share common components.
Does this help?
|
|
|
|
|
Crikey. 46% don't do automated builds? Can we please have a follow up survey on why 46% don't do automated builds.
Project too small?
Too hard to setup?
Other priorities?
WTF is an automated build?
|
|
|
|
|
Paul Watson wrote: Project too small?
Too hard to setup?
Other priorities?
WTF is an automated build?
We don't need no damn automated builds?
|
|
|
|
|
Nemanja Trifunovic wrote: We don't need no damn automated builds?
Yes, but why don't you need such a useful tool?
|
|
|
|
|
Paul Watson wrote: but why
From my experience in most cases it's not a decision at all. Many have never heard about it or consider it some sort of crazyness for programming softies (you know: these people that even comment their code or give their variables meaningful names ...).
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.
|
|
|
|
|
|
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;
|
|
|
|