What are some things that you do to make sure a project is ready to be released?

Question

I was wondering what final steps developers take before they release their new project.

Answer 1

Have someone other than the developers who wrote the software test it.

Answer 2

Grep the source code for:

• TODO comments
• Profanity (especially in end-user messages!)

Answer 3

freeze development of new code in the release version and only fix bugs.

Answer 4

• Independent security testing
• User testing
• Accessibility testing

Answer 5

Make sure all the tests pass! You do have tests don't you? =)

If there exists this one final thing, then it makes more sense to do it often (and not just before release).

Answer 6

Something worth considering: do those things which needs to be done for the software to be released not and the very end of the development cycle, but do it early instead. By doing this "just before the release" you risk a lot, because those things will usualy take a lot more effort and energy than expected.

Those things are:

• build setup, or whatever deployment method your application uses
• let other test the application
• fix known critical bugs

For larger projects I would add:

• create automated testing pipeline and create at least functionality tests covering the basic functionality
• create automated build pipeline, which should build Retail configuration of your project and automatically create a setup from it

This taken into all consequences leads to key principles of agile development: deploy early, deploy frequently, deploy to someone representing the customer.

Answer 7

Here are some of my ideas.

• Take a 'naked' e.g. non dev-machine, with a fresh OS and run your software there. You can do this in a virtual machine.
• Let non-devs test your app.
• Watch other people how they use your software in order to find design/usability bugs.

Answer 8

Experience has taught me to test the software in the production environment, rather than just on my dev box.

Answer 9

Watch development rate and wait for it to drop. Wait a bit longer than the initial drop, to make sure that it's thoroughly bugfixed. This is often neglected step. And it's crucial for quality. Don't release the thing immediately. Even if you think it's ready. Wait a bit.

You can also use techniques like defects pooling and defect seeding to estimate number of bugs yet to be found.

And make sure developers on the team don't have any hidden private TODOs. They may think they will eventually get back to them (they're often cleanuo tasks), but in fact it rarely happens, and tends to delay the project or hamper quality.

Answer 10

Testing is key. Developers should do initial testing, but independant testing is vital. Developers are too close to the code to test properly.

The product to be tested should be built using automated build tools (such as FinalBuilder). The developer should check all his code into source configeration control and the automated build tool should retrieve the latest code from SCC and then do the build. This ensures that what is built is actually stored in the repository. We also include all third party components in the SCC as well.

We also issue a version history with each release to aid testing.

Answer 11

Not that I am an experienced developer, but.. :)

What works relatively well for me..

• Release early, release often. On my hobby project I keep a group of alpha testers that I subject to new versions as soon as it seems to work on my PC. The beta testers only get a go once the hate mail from the alpha testers dies down a bit.

• Unit testing is not just a help in design, but gives you a lot of confidence in the quality of your code. If you don't love it yet, you haven't written enough tests. ;)

• Test it in a plain, vanilla Virtual PC. One set up to clean up any changes you make as soon as you switch it off. That way, you're ALWAYS performing a clean install, and you'll find out about any assumptions you made which your development machine had no trouble with.

• Keep a log of bugs and "weak spots" in your code. Test stuff that has failed before. Do stupid things. Try to think like a baby and make a game out of it; See if you CAN break your application.

Of course, all of these are based on having ongoing releases at (semi-) regular intervals - I am not brave enough to release software based solely on my own testing. :)

Answer 12

In "line of business" applications (i.e. corporate applications) there are a number of processes post development completion:

Usually these are called: (names will vary, but the process is fairly standard)

• User Acceptance Testing. Does the software do what the users want it to do?
• Fitness for Purpose. (or Performance Review) Does the system/software work correctly and scale adequately on "normal" machines (or the production servers)
• Operational Handover. Can the application be upgraded / installed correctly. How do you back it up and recover the system if there is a failure? Where is the documentation for the Helpdesk?

Even for non-commercial software, these are steps that should be incorporated into any release process, which usually involves finishing off all the mind numbingly boring things that you've put off up to now (like documentation!)

Answer 13

Further to Greg Hewgill's post on greping for //TODO: comments.

I find it handy to mark code added for debugging with: "//debug:" (eclipse style) and then grep'ing for that as well.

If you use the todo / debug convention religiously, it can be a real safeguard to catch such problems.

Answer 14

The final steps of any of my projects is system testing. We have a system test platform here that is a complete copy of production. We then overlay any changed modules from our project into it, then completely test it, from web access, inputs, outputs, batch cycles, everything. It can be tedious and time-consuming, but it's been invaluable in what it can point out that normal unit testing does not. We try to encourage all of our developers to do string testing, but nothing beats a full production system test, where you really get to see what it's going to do when you move it to prod.

Answer 15

This varies greatly depending on the kind of project you have:

• Consultingware;
• SaaS;
• Packaged product for Desktop.
• Software to control critical systems (e.g. nuclear power plant).
• OpenSource software package.
• etc.

Answer 16

I'm not a true developer since I don't actually write the code. But I assist in writing the documentation, training the customers and supporting the product after deployment.

The biggest issues I, and our customers, experience is poor usability caused by lack of code testing. It doesn't need to be anything formal: just stop someone in the hallway - show them a screenshot and see if they can determine how things work, or what it's intended to do. If they can't a redesign is warranted.

Better yet: don't design the code without write function specs based on conversations with end users and support staff familiar with the industry and customer needs. And don't deploy the code until it meets all apsects of that function spec.

Our newest lead developer has implemented these steps and no code is released until it's undergone internal testing not just by Q&A but also by documentation and support staff. It's so much easier to fix the code before customer release and has lead to a much better/solid product.

Answer 17

Say it's beta.

Answer 18

The most important thing before a new release is NOT to break anything that works now. So the most important step is:

• feature-freeze: only fix bugs now, no new or enhanced features in the last phase before release (you can branch in your version-control, new features going now to the branch for the next version)

As you should only fix bugs now, it's time for more testing:

• give the software to external testers
• make some stress-tests, look if the software will break under load
• install and test it on a fresh box (not on the developer-box)
• Try to start with no configuration/empty database or whatever is a relevant start-configuration for your project.

I hope you already do unit-testing and continuous integration.

If you have time between fixing bugs, you can check the documentation: Includes it the changes since the last release, are the tutorials working?

And you can check, if your code includes the new version-number at all places (make a full-text-search for the old version-number). It's always fun for the users, if you release version 1.3 and the about-dialog talks about version 1.2.

Never do in the last phase before the release:

• refactoring
• working on TODO-comments (as mentioned by others)

These are jobs for the first time AFTER the release.

Answer 19

You are asking for final steps. In case your development team has been eating their own dog food the final steps should just be releasing what you have. Though there are some good pointers as to when this should be done:

• Have all the stake holders (developers doing the code) say the code is good
• Make sure that no major feature has been added recently (watch development rate as phjr wrote)
• Let the users pound it. The users should already have been using the code, now is the time for them to take responsibility
• Make sure that everyone is committed to doing the release
• Make sure that the final steps phase is short (it should be if you have been eating your own dog food)

Answer 20

A comprehensive guideline on how to release Python.