Main novice user scenario

I'm assuming that novices will start from scratch.

1. Create a build file
2. Verify build file works
3. Add project to version control repository
4. Verify project is available from version control
5. Setup a continuous build
6. Verify continuous build works

Key points

• guidance
• minimise setup time
• convention (for guidance and speed of setup) is more important than configurability

Questions

• Should we provide more guidance on setting up preliminaries like build files and version control? Does Buildix cover this off for us?
• Should we set some default assumptions about target names? For example, assume a cruisecontrol Ant target unless specified? Are there other opportunities for convention over configuration?
• Can we make it easier to verify that the continuous build was setup correctly?

Main typical user scenario

I'm assuming that the typical user should already have a working build file with their project stored in a version control system.

1. Setup a continuous build
2. Verify continuous build works
3. Re-configure for different notifications, scheduling, etc.
4. Troubleshoot why changes don't work
5. Verify continuous build works

Key points

• guidance for configuration options
• clear error messages with guidance on how to correct OR better yet, mistake-proof reconfigurations
• minimise setup time
• typical reconfigurations should be easy to do

Questions

• Should we create a schema for the configuration so XML editors will provide code-completion and validation? Can we simplify the form of the configuration so it's more intuitive?
• Should we create a GUI configuration UI?
• Where are people making mistakes in setup and how can we change those steps to make them mistake-proof?
• Which message outputs are confusing?
• What are the most common reconfigurations?

Main experienced user scenarios

I'm assuming that experienced users have done it all before and there is no particular difference except when trying to do something more fancy like build staging or distribution. There's no reason why an experienced user would not also like a faster setup and customisation process though.

Key points

• guidance for greater understanding of how CruiseControl works
• make customisation easier
• usability of more advanced features

Questions

• Is it clear what code needs to be written or modified if someone wants to create a new feature or fix a bug?
• Should we look at a way to more easily customise CruiseControl without have to rebuild?
• How easy is it to setup build staging? distributed builds?