问题
I am wondering what your best practice is regarding managing (and versioning) different kind of project documents (like versioning targeted docs like: use cases, master test plan, qa plan and non-versioning related docs like MinutesOfMeetings for example) in TFS 2010.
Are you using
- Team Wiki or
- Shared Documents or
- Source control
?
回答1:
We use source control for all documentation tokens that are shipped to the customer. This includes manuals/installation guides and the similar. That way they get regular build labels & we know which manual corresponds to which version of the software.
For internal docs (MoM, design docs, project management etc) we use Sharepoint & for UserStories we obviously use the build-in TFS work item types.
回答2:
I add my thoughts on this:
The best way to answer this question is: there's no best way to do that. It depends on many factors and that's why every team do it differently.
However, there are some guidance about that:
If possible put the artifacts at places that can deal with the same kind of development cycle. For instance if you store on a wiki the documentation that is intended to be specific for each release of your software, you'll get troubles very fast. Versionning is crucial so you have to choose the services that can support the versionning you need.
Take into account the audience : you don't want to store a spec word document on the Source Control for instance.
Don't be afraid to store things on the Source Control if it makes sense: you will never get better performances, data are delta packed in storage and packed for transportation to the client side: VERY EFFICIENT.
You can use the Work Item to store your document, using Attachments, it's a nice way to go but certainly not the easiest to setup and for the whole team to buy it.
What I recommend (but it's only personal):
- Use a Wiki or a Share OneNote book (OneNote is great) for documentation internal to the dev team. OneNote has a great flexibility to build collaborative data with just the amount of formalism you need to be productive.
- SharePoint for documents that are produced or read by non developers.
- Source Control to store a complete release of all your document/artifact. When my release is done I like to copy all the documents and assets in a given folder of the Source Control, this way I know I always be able to restore them when needed. (and I'm not so much sure about SharePoint or OneNote).
- I once did drive anything formal with Work Items, it was great but needed time and custom tools to achieve what I wanted.
回答3:
TFS to SharePoint integration - If your organization has SharePoint, this is by far the best option for storing documents.
Otherwise, choose an option that better meets the following requirements:
- Access to shared documents for all project contributors
- Accessible from the web for users without Visual Studio
- Provides versioning
- Allows permissions management
The source control option is less recommended for being inaccessible for non-developers and the potential of letting them abuse the source control (ever tried downloading a 1GB source tree, most of it being pure junk - documentation archive, logs, database dumps, etc...?).
来源：https://stackoverflow.com/questions/10845460/share-project-documents-in-tfs-different-ways-what-are-your-best-practices