This project is read-only.

Question: How should I manage source code that is shared across multiple projects?

- J.D. Meier, Jason Taylor, Alex Mackman, Prashant Bansode


Managing shared source involves two decision points:
  1. Where do you want to store the source?
  2. How do you want your team to access the shared source?

The following options are available for storing the source:
  • If the shared source is clearly owned by a particular team, store it in their team project.
  • If the shared source has no clear ownership, create a team project specifically for the shared code.

If you want to use the source in another project, choose one of the following two options:
  • If you need to stay in sync with shared code at all times, map the source from the shared location into the local workspace on the client machines.
  • If you only need to stay in sync periodically, branch from the shared location into the consuming team project. Every time you perform a merge from the shared location to the consuming project, you will pick up latest source.

Whether you use workspace mapping or branching, use naming conventions that make it clear where the shared source location is located in your project; for example:
  • Main – Container for all assets you need in order to ship the product
    • Source – Container for everything you need in order to build
      • Code – Container for source code
      • Shared Code – Container for source code that is shared from other projects
      • Unit Tests – Container for unit tests
      • Lib – Container for binary dependencies
    • Docs – Container for documentation that will ship with the product
    • Installer – Container for installer source code and binaries
    • Builds – Container for team build scripts
    • Tests – Container for test team test cases

Additional Resources

Last edited Jul 19, 2007 at 12:07 AM by jtaylorsi, version 6


No comments yet.