This project is read-only.

Question: How should I manage binaries that are shared across multiple projects?

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


Managing shared binaries is similar to managing shared source―you must decide where you want to store the binaries and how you want your team to access the binaries.

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

The following options are available for using the binaries in another project
  • Shared binaries are usually updated only periodically. If this is the case for your project, branch from the shared location into the consuming team project. When the binaries change, you can execute a merge to get the latest version.
  • If you need to stay in sync with the shared binaries at all times, map the source from the shared location into a local workspace on the client machines.

Whether you use workspace mapping or branching, use naming conventions that make it clear where the shared binary location is 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:11 AM by jtaylorsi, version 6


No comments yet.