Best Practices for Workspaces
One Team System concept that a number of VSS users struggle with is workspaces because there doesn’t appear to be a comparable concept under VSS.
This isn’t entirely true because by setting working folders in VSS you are effectively establishing a “default” workspace and you can create multiple workspaces by performing gets into alternate directories. However, unlike Team System these workspaces aren’t named or managed.
So how can you get the most value out of Team System workspaces?
Read the Workspaces section of High-level Best Practices in Software Configuration Management by Laura Wingerd & Christopher Seiwald from Perforce Software. In this SCM tool agnostic article Laura and Christopher outline five course-grained best practices for workspaces:
- Don’t share workspaces. A workspace should have a single purpose, … for a single developer. Each developer owns their own workspaces and they should not be stored in a shared location where other developers can access (or worse modify it).
- Don’t work outside of managed workspaces. Your SCM system can only track work in progress when it takes place within managed workspaces. Under Team System this really means that all changes should be performed using Team System (either through Source Control Explorer, the tf command-line, or custom applications that use the TFS API) rather than using Windows Explorer or other file system commands.
- Don’t use jello views. A file in your workspace should not change unless you explicitly cause the change. Although Windows supports symbolic links (of a sort) they aren’t often used so this is less of an issue, but conceptually it is still important that developers are in control of and understand the current state of their workspace.
- Stay in sync with the codeline. As a developer, the quality of your work depends on how well it meshes with other peoples’ work. Staying in sync with the codeline can be a trade-off between productivity and “correctness”. What’s important is that the developer is aware of how often the codeline that their workspace maps to is changing and the risk of including those changes in their workspace and schedules their synchronisations accordingly. The ideal time to synchronise is when the codeline is in a known good state and so is the developer’s workspace and it would be advisable not to go more than a week without synchronising except in exceptional circumstances. Developers should always synchronise their workspace with the codeline before checking their changes in, this allows them to resolve any conflicts in their workspace without compromising the codeline.
- Check in often. Integrating your development with other peoples’ work also requires you to check in your changes as soon as they are ready. As a rule as soon as a developer has completed a task and it has passed any quality gates defined by the codeline’s policies their changes should be checked-in to the codeline so that other developers have access to the change and integrate their changes with it.
The next question is should you have one workspace or multiple and what should the granularity of each workspace be? I take the following factors into account whenever I create a workspace:
- Each workspace should have the simplest set of working folders possible. Overly complicated working folder mappings (such as large numbers of working folders or mixtures of active and cloaked working folders) can be confusing and cumbersome to manage.
- Each workspace has an overhead (e.g. staying in sync with the codeline). You need to evaluate the cost-benefit balance for each workspace you create. For example, creating a separate workspace for each task would probably not be worth the overhead it adds.
- Each workspace should have a single defined purpose (e.g. development, QA, release management, or testing). For example, don’t do development and QA using the same workspace or don’t do QA and release management using the same workspace. These purposes have different codeline synchronisation, backup, and integration requirements, keeping them separate allows you to manage these activities more easily.
- Each workspace should contain a single product or a related set of products. This will reduce the scope of any activities you perform which will both improve performance as well as avoid you having to deal with synchronisation or integration conflicts that aren’t relevant to your current context.
- Each task you perform should start with an empty list of pending changes. Your contents of your pending changes tool window should always reflect your current task because managing pending changes that are related to a multitude of different tasks is cumbersome and prone to error.
Here are some examples on how these can be applied:
Joe is a developer for the WidgetManager product and performs QA when required. To do this Joe would create two workspaces, one called “WidgetManager Development” and one called “WidgetManager QA”.
Joe would use the “WidgetManager Development” workspace to fix bugs and implement enhancements to the product. Because of the development nature of this workspace he would ensure that it is synchronised with the codeline when both the codeline and the workspace are in known good states. Once he has completed his work and met all of the quality gates the changes in the workspace would be checked-in. If Joe had to switch development tasks he would shelve the pending changes (without preserving the local copy) and work on the other development task.
Halfway through the development cycle Joe is asked to perform some QA on work integrated into the codeline by one of his colleagues. He switches to the “WidgetManager QA” workspace and synchronises it with the codeline and then performs QA on the necessary files.
The advantage of having a separate workspace is that Joe doesn’t need to worry about shelving his pending development changes (or even worse losing them) when switching contexts. He also doesn’t need to worry about his in progress development contaminating the files being QA’d.
Let’s look at another example:
Niles is a build engineer on two separate products and is responsible for building and packaging the products for distribution. The products don’t have any dependencies and ship on entirely separate schedules. To do this Niles would create two workspaces, one called “WidgetManager Release” and one called “FooPlus Release”.
Each workspace would map the folders for the development and maintenance branches as well as any tools or scripts needed to build and release the software. Niles can synchronise each workspace separately which improves performance and reduces the scope of any conflicts.
Hopefully this has given you some ideas on how you can better use workspaces in your development process.
