|
hopingToCode wrote: The build in VS takes less then a minute.
Automation's purpose is not to improve build speed but to automate the build process  . If you have several people working on it, a testing framework or a code repository then automation is very useful.
Regards.
|
|
|
|
|
PedroMC wrote: If you have several people working on it, a testing framework or a code repository then automation is very useful.
How I would wish... out of interest do you automate build for websites as well or just other type of apps?
|
|
|
|
|
hopingToCode wrote: How I would wish... out of interest do you automate build for websites as well or just other type of apps?
Yes, most of the time. It can automate (some) testing, documentation creation, compilation and deployment to a test server. There is not much difference in automation between web apps projects and other apps projects. One thing that I don't know how to automate is testing the UI part of web apps (not much easier for GUI apps). Someone must always go through every page on several browsers, boring repetitive work. Automation can help in collecting a list of pages that need testing but that is about it.
Regards.
|
|
|
|
|
For testing web UIs, have a look at Selenium.
http://selenium.seleniumhq.org/
|
|
|
|
|
We're not doing automated builds, but I'm trying to lead us that way. The first step is to introduce patterns that make the UI as "dumb" as possible. This way we can do automated testing on 99% of the code. We're doing our first WPF project and I'm using it to try and change our development habits and mentality. The next step is either moving to ASP.NET MVC or using the same patterns in web forms we're using for WPF to make the UI dumb. It will be an interesting challenge.
|
|
|
|
|
If you are testing a website it comes down to bringing in discipline around architecture. Your logic should be in different components (assemblies in .Net) that can be invoked from unit tests. A lot has been said for and against MVC, but you don't even need to go that far - just a three-tiered approach.
If you get that right, if a developer checks in code that introduces a bug you will get instant notification (if using CI) that something broke.
If you UI is FUBAR, you can go as far as sending customers an aspx page/whatever instead of a dll/whatever that needs to be installed in the GAC, registered with COM, or registry settings: preceded and followed by an IISReset. You get the idea.
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)
|
|
|
|
|
Im ignorant of how to do it in VS with TFS
|
|
|
|
|
Normally, you do it using a Build Server like CruiseControl.NET in combination with a build tool like NAnt or MSBuild on a dedicated machine (the build server). There's no need for VS - you only need the compiler (e.g. csc.exe for C#) which can be used free of charge.
All the tools I mentioned are open source and under free licenses, yet very mature and reliable. So there's no additional cost in using them despite the learning effort, which, for a simple solution, is not so high. Since widely in use, many examples exist on the web.
Regards
Thomas
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.
|
|
|
|
|
Most of our projects (C++ we do not use .net) are written by only 1 developer with external code being called from libraries so there has not been a great need for automated builds. The build process is for the most part done on their machines and only when changes are made. With that said we are now moving to more cross platform development with Qt and using CMake to generate projects. With this I can see automated testing being part of the build process (since this is built into CMake).
John
|
|
|
|
|
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
