The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Software Release Checklist

Hi folks,

What do you think are good steps to have on a software release checklist -- that is, one to fill out after all testing is done and the software is ready to be released to the outside world?

So far, I've got...

Check buglist to ensure all bugs for product are fixed/marked as dontfix
Update version strings with final version information
Remove debugging and testing code from the software
Remove seeded defects from the software
Make sure all source files are checked into source control
Build in clean directory to ensure that all necessary files are present
Verify any release notes and any accompaning documentation is included and valid
Create final release media (zipfile/cd/disk/etc)
Verify final release media
Ship it
Profit!

Any other good steps?
AP
Monday, April 18, 2005
 
 
You seem to have forgotten all marketing steps.  Without them, that last step of yours won't happen.
Aaron F Stanton Send private email
Monday, April 18, 2005
 
 
After you've removed debugging code, and seeded defects, you will have modified the source, yes?

After I've modified the source, I always want to have one last clean build, and then one last clean test-run, to give me warm fuzzies that removing the debugging code and defect code hasn't broken anything.

If you haven't broken anything, running the test shouldn't take that long (there's that 'should' word again!).  If you have broken something, you'd really-really like to know that before your customers do -- when you can do something about it.
AllanL5
Monday, April 18, 2005
 
 
Also -- once you've completed the checklist, the final step shoud be:

-- Automate the checklist. (as much of it as possible)
Sgt.Sausage
Monday, April 18, 2005
 
 
>Remove debugging and testing code from the software
>Remove seeded defects from the software

These are broken to me. Once you change the code you have to redo all your tests again. The code should stay the same throughout the testing process. I haven't found a case where i couldn't generate the test without changing the code.
son of parnas
Monday, April 18, 2005
 
 
http://www.construx.com/survivalguide/releasechecklist.htm

Lots of test activities there that you've glossed over.
Brent Send private email
Monday, April 18, 2005
 
 
I agree with above. You need to do one more pass of validation if you change the sources. There are some other engineering type things you should also do.

I've been through physical media sw release at least 3 times a year for the last 5 years. Miss any one of these steps and you are risking a world of pain (been there done that)


1. Update version strings with final version information

(why isn't this happening all the time? - you should be using a automated build process that does this for you - it helps make every build consistent)

2. Remove debugging and testing code from the software
3. Remove seeded defects from the software
4. Make sure all source files are checked into source control
5. Build in clean directory to ensure that all necessary files are present

(You should be doing the above step _every_ time you do a build!!)

6. Verify any release notes and any accompaning documentation is included and valid

7.If shipping physical media, create 2 copies of final release media (zipfile/cd/disk/etc)

8. Virus scan. Install one on a "know clean PC" and do a virus scan with an AV scanner that is up to date. This is really important.

9.Verify final release media. Make sure the 2 copies are identical (windiff against each other)

10.Last validation sweep. MAKE SURE YOU DO IT USING ALL USER FACING DOCUMENTATION (i.e. install guides and user guides). You should _always_ use one of the media created in step 7.

11.Ship 1 of the media created in step 7.
12.Archive the other one. (some replicators I knew lost a copy of our master CD fortunately we always have at least 1 other copy archived. One replicator even broke a CD with a chair leg!!! - WTF were they doing I ask?!)

13. If you are shipping to a media replicator, then they should return at least one proof (ideally 10-20) which you should then windiff against the media archived in 11. When you are happy that it is a clone and you are also happy with the defect rate then give them permission to replicate the order.

Step 13 is a _must_. You don't want to find that 30% of your CDs are duds. Some dubious replicators cut their costs by using master plates for more than the normal impression limit (I think it's around 500)...I once received 20 proof CDs and found that around 30% were duds.
The replicator only checked the first 5 in the batch. I changed replicator because of this.

14 If/when you receive the batch from the replicator. You might also check a sample of the CDs for quality. (20 from the front, 20 from the end and 20 from the middle).
pmuhC Send private email
Monday, April 18, 2005
 
 
Thanks for all the comments!

My acutal situation is a little different, as I'm mainly dealing with embedded code, but yeah, the physical media stuff bit me a couple times in a past life.

I agree on all the comments re:testing.  Removing test code (and adding it back?) is a recipe for trouble.  Away goes that step, any test code should just not be compiled into a final release build.

Version stuff -- yup.  As for automating that -- is there any good way to automate the collection of RCS-style $Header$ in C/C++ source files so that a command line option can print out all the source files used for the creating of the file? (I'm thinking header files would be hard to include in this, so perhaps this isn't the right way to do it...)
AP
Monday, April 18, 2005
 
 
"Update version strings with final version information"
Should be made consistent, and change change with every build. To achieve this, have one file with the version info in it (#define build 123, #define VER_MAJOR 4, etc). Have each binary include it in its .rc file and generate a version info based on it. Have your build script change the build num every build.

"Remove debugging and testing code from the software"
That's waht debug/retail builds are for. And consider leaving some debugging stuff even in the retail build - you might need them at a customer's site...

"Make sure all source files are checked into source control"
*puzzled look*  Where else would they be?

"Build in clean directory to ensure that all necessary files are present"
This should be instated on the build machine,and fairly early in the development process.
Jonathan
Tuesday, April 19, 2005
 
 

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

Other recent topics Other recent topics
 
Powered by FogBugz