A Private Workspace is not useful on its own, and it is important to understand the patterns that define its environment. Figure 2 shows how the Private Workspace pattern fits in the context of the other SCM Patterns. The key patterns in establishing a workspace are
- Private Workspace, which defines what a workspace is
- Private Build, which allows you to verify that the system works
- Repository, which provides the tools that allow you to create the workspace
- Smoke Test, which gives you a way to check that your changes have not broken the build
- Unit Test, which allows you to test your specific changes in detail
- Integration Build, which provides a way to verify that all of the changes that were coded and tested in the private workspace really do integrate together
- Codeline Policy, which is how you communicate how the development process works
Private Workspace enables Active Development Line and relies on Repository, Integration Build and Private System build to work.
Arguments Against Private Workspaces
One item that seems to raise issues from time to time is the requirement for copies of the database schema. You can apply these rationales to any other resource issue. The common issues that arise are computing resources (machines to run the databases on), complexity of setup, and that databases are the province of a different team (the "Database Team"). While there may well be exceptions, in most cases these rationales are often not valid reasons to deny this important productivity improvement tool. Let's address these in turn.
The Cost of Resources
Cost of resources is often overstated. The first thing to consider is the cost of not having these resources in place. Consider the amount of effort you expend working around not having these resources. One major one is the coordination cost of having to time private changes to a shared schema with the work of others. You may have to spend time waiting for the resources, your test cases may disrupt the work of others (by design if you are working on an issue that could break the whole application, or by accident if you make a mistake). Developer and tester time is relatively expensive compared to hardware, and delays also can mean slipped schedules and missed market opportunities. Also, the hardware you need for developer testing need not be at the same price point as Production hardware. A desktop machine could host a number of developer databases, or developers could host the database on their machine.