|
I have been a supporter of routinely, automatically building all of our apps, but it never rises to the top of the pile of flaming, gotta-be-done-now emergencies.
My main concern is that we don't detect software rot until there is a critical need to change the application. At which point it is too late. (Software rot shows up when the unchanged code stops working due to environmental changes like a new compiler, OS, changed DLLs, etc.)
|
|
|
|
|
Sorry, I don't fully get it.
Are you using an automated build server or not?
All things you describe can be perfectly solved with an automated build server, an appropriate suite of unit tests, and perhaps some software metrics measurement. This together acts like an automated quality assurance station.
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.
|
|
|
|
|
No, we are not. I would like to but there is never enough time to set it up.
|
|
|
|
|
Harold Bamford wrote: there is never enough time to set it up.
As always...
There must be a commitment within the team and also with the management to do it. Otherwise it will never happen...
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.
|
|
|
|
|
Harold Bamford wrote: My main concern is that we don't detect software rot until there is a critical need to change the application.
What?! Looking incredulous at the MANY errors and warning. It built without a single error or warning yesterday.
Yep, I know the filling. 
Regards.
|
|
|
|
|
Because the solution is so small it's not required.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
We used to do that but so many "small" projects turned into hairballs that we made it dead-easy to send any project to the auto-builder. Now it is more hassle not to auto-build. Plus the testing manager won't come sit on my lap if I ensure every bit of code is auto-built.
|
|
|
|
|
Several reasons:
1: don't have the knowledge how to do it (yet)
2: at the moment don't have the time to learn it (I'm in the middle of creating the company standerd, so that pretty much takes up all the time I have for research)
3: our projects really aren't big enough (yet)
4: untill recently I was the only .NET developer (there is a second one now but he is still fresh out of school and will mainly be working on ASP.NET)
5: no budget for a dedicated server to do this (at the moment)
So while I'm shure I'll look into it in the future at the moment we don't use it.
|
|
|
|
|
Tom deketelaere wrote: 'm in the middle of creating the company standerd, so that pretty much takes up all the time I have for research
It seams to me that now is a great time to think about automated builds, since your are working on the company standards.
Tom deketelaere wrote: no budget for a dedicated server to do this (at the moment)
You probably don't need a dedicated hardware for your automated build system. Do you do lots of changes a day that need to be built and tested? (With two developers, probably not.) Do you have test cases that last hours (e.g. numerical simulation) or need to stress the hardware (e.g. measure 3D performance)? If not then you most likely will be well served with one of your server systems that has spare resources.
Regards.
|
|
|
|
|
PedroMC wrote: It seams to me that now is a great time to think about automated builds, since your are working on the company standards.
true but I'm still at the start off the whole thing so it will most likly have a place but not right now.
PedroMC wrote: Do you do lots of changes a day that need to be built and tested?
Pretty much (clients call with changes and so on...)
PedroMC wrote: Do you have test cases that last hours (e.g. numerical simulation) or need to stress the hardware (e.g. measure 3D performance)
Nope (at least not yet)
PedroMC wrote: If not then you most likely will be well served with one of your server systems that has spare resources.
Good luck at finding one off these around here most off our servers are already very overused
|
|
|
|
|
My main app (currently being rewritten in visual studio) uses 3 different products before shipping (vb6, fasthelp for 2 .chm help files & wise installer) so i dont have much of a choice really, its a bit of a pia but not something i have to do every day so its np really.
|
|
|
|
|
The team I work in automates everything we can; updates, check-ins, builds and testing.
When a developer checks in a new version, the build PC's update to that version and build it. If the build succeeds, the version is flagged as building OK, the build PC then runs tests on the build version. If the tests succeed, the version is labelled good. Developers can then see all the versions they can update to and what state they're in.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
