Before releasing your prototype to users, you will want to make sure that it is fully tested. You can do this by moving to an iterative release pattern.

With iterative releases, you test your system, and when you have a stable version you make a "release branch" in your repo that contains the source code. This allows you to test, fix and distribute the stable release branch, while experimenting with and enhancing a separate development version.

You might find a bug in your release. In that case, you will need to commit the bug fix both to the release branch and to the development version for future releases. This is a small annoyance of the release branch system. It provides an incentive to "cut the release branch" fairly late in the process of developing a release candidate, after most bugs have been found. The later you "cut," the fewer fixes have to be applied in two places, and the closer you get to continuous delivery.

Testing release candidates

Almost all iterative release processes test a single release candidate that is built from a recent version of the "active" or "mainline" branch.

The release candidate allows you to spread out the work of testing the software. You can have a QA person test it, or you can show it to "beta test" users and get their feedback. If your project is large enough to have a QA team, you will be tempted to give the QA team final responsibility for deciding when a release candidate is ready to release.

Getting releases out

To be considered "Agile," you have to deliver releases on time. What do you do if you have promised a release every four weeks, but your release candidate is not stable? I am often asked this question by development teams that are stuck in a cycle of never releasing. They always have good reasons why they aren't ready to release. Don't get stuck this way. Your bosses or investors will get frustrated and put you under unpleasant amounts of pressure.

You can break the roadblock by telling the team that they WILL release, but they can decide the recipients. Instead of releasing to everyone, you can release just to your internal team, to close friends and partner companies, or to selected friendly customers.

Moving from informal to iterative

When you move from informal development to iterative, tested releases, you will need to make infrastructure decisions regarding:

1) Task management. How will you keep track of feature requests, bug reports and tasks?

2) Code management. Where will you put your code, and what type of code contribution workflow will programmers use?

3) Build, test, and deploy scripts and infrastructure. How will you build the release candidate and the distributed or deployed version, and make the process repeatable?