Андрей:
Во-первых, мы нарушаем несколько «лучших практик», чтобы добиться этого, но прагматизм - это то место, где лучшие практики встречаются с реальным миром.
Что мы делаем:
- Все двоичные файлы регистрируются в TFS в папке LocalBin, которая объединяет все наши двоичные файлы.
- Все общие сборки находятся в папке LocalBin / SharedBin.
- Папка SharedBin ответвляется на папку SharedBin верхнего уровня в потребляющих командных проектах.
- При успешной основной сборке LocalBin / Sharedbin объединяется с папками SharedBin проекта.
В итоге получается что-то вроде этого:
$/ProjectA/Main/Localbin/SharedBin разветвляется на $/ProjectB/Main/SharedBin и $/ProjectB/Dev/Sharedbin (а также на эквивалентные папки в $/ProjectC, $/ProjectD и так далее).
Мы делаем это совместное использование только тогда, когда у нас есть успешная сборка MAIN, и сборка отвечает за слияние не только с другими проектами ветви MAIN, но и с проектами ветви DEV, поэтому они актуальны.
Мы играли с идеей скопировать двоичные файлы в общую сетевую папку после успешной сборки и иметь соглашение, чтобы ссылаться на эти двоичные файлы в этом сетевом ресурсе, но этот процесс хорошо работает для нас сегодня, и мы ненавидим внесите в него изменения на этом этапе (сейчас происходят более важные вещи).
Это одна из тех вещей, которые сложно полностью описать в публикации, поэтому, если у вас есть дополнительные вопросы, я буду рад попытаться на них ответить.
Кстати, наше решение было создано и работает под TFS2008 с тысячами файлов проекта и, вероятно, миллионами строк кода. Это увеличивает время сборки из-за слияния и увеличивает объем пространства, используемого в вашем репозитории, но до сих пор и то и другое было управляемым.
person
Robaticus
schedule
02.08.2010
