The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Development code delivery to QA

How do you people, if you do such a thing, get a software release in the hands of a Business Analyst type person for them to play with it?  Test out the required functionality, etc.  (For the record we are not an XP or other Agile methodology user.)

The software in question (don't shoot the questioner) is MS Windows, fat client, and requires an install process.

The developers can build, but most of them don't have the packaging software to create an .msi that someone else can then run/install.  Should they?

What do you people do?
sdg Send private email
Wednesday, November 03, 2004
 
 
It's always preferrable to have an actual installation to run because it helps troubleshoot the installation as much as the program itself but...

if you can't do that, then just put together the steps for the Analyst to hobble together an installation.  (Reg keys, copying files, registering dll, etc.)  I'm guessing they should be technical enough to do that. 

Around here we run an installation, and then update manually as newer versions become available.
N Send private email
Wednesday, November 03, 2004
 
 
The best thing to do is implement a proper build process using software such as FinalBuilder. It should be on its own machine and can be scheduled to do a complete build every day including such things create the installation package.

Then all they need to do is go over to the build machine, take out the CD it automatically burnt for them and install it. Life is good.
Craig
Wednesday, November 03, 2004
 
 
I would create a simple build process to create a deliverable for QA or the analysts. This will allow you to automate some of the otherwise dreadful tasks of DLL registration, etc. that are highly prone to error.

Besides, sooner or later you're going to have to write an installer anyway. Now is a good time to start.
Erik
Wednesday, November 03, 2004
 
 
I'd say start with the installer as soon as possible and have  a "button" avaialble in the buildprocess so you can build an installer whenever you want. Doing this early also solves the problem of having to do lots of installer fixes afteryou've frozen the code (installer scripts are code, right?)
Andreas Sikkema Send private email
Thursday, November 04, 2004
 
 
It probably shouldn't be the responsibility of "just any developer" to create the install package.  Thus you already should have a 'special' developer who builds install packages.

There should also be an interface person with the business group, who gets them their beta copy. 

The best result *is* to build an installation version of the application (done by the 'special' installation guy), and have the business people install from that.

This way, you validate the install procedure as well as operating the application.

Having said all that, I do believe that *any* developer should *know* and have access to the tools necessary to create an installation package.  "Specialization is for insects" (Heinlein).
AllanL5
Thursday, November 04, 2004
 
 
"The best thing to do is implement a proper build process using software such as FinalBuilder. It should be on its own machine and can be scheduled to do a complete build every day including such things create the installation package."

Craig is 100% right, and I recomment the same (and the same tool). You won't believe how much trouble can be avoided using daily builds until you try it out.
Gerd Riesselmann
Friday, November 05, 2004
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz