TFS: Как кэшировать сборки фреймворка для облегчения процесса сборки? - PullRequest
0 голосов
/ 27 января 2011

Недавно я был назначен в команду разработчиков релизов, чтобы сделать процесс сборки более управляемым. В истории нашего продукта мы просто строили все в нашем репозитории контроля версий с каждой сборкой, так как это было не так уж много времени. Это включает сторонние продукты, для которых у нас есть исходный код (включая, например, Enterprise Library), наш собственный внутренний код инфраструктуры и, наконец, сам продукт. Однако после нескольких лет постоянного роста производства этот процесс стал очень громоздким.

Тем не менее, мы хотели бы создать своего рода многоуровневую систему сборки, в которой ежедневно создаются только продукты (которые меняются каждый день), в то время как наш базовый код (который меняется гораздо реже) и наш сторонний код (почти никогда) строятся только тогда, когда они меняются. У нас есть сервер символов и исходного кода, настроенный для облегчения отладки кода, такого как наши библиотеки фреймворков, которые не создаются заново для каждой версии, но мы все еще выясняем, как это сделать. Для записи мы используем TFVC для контроля источника.

У меня такие вопросы: какие виды практики используются для такого рода вещей? Создаем ли мы отдельные командные проекты для каждого «уровня» этой сборки (т. Е. Командный проект для третьей стороны, для фреймворка, для продуктов) и разделяем их друг на друга? Проверяем ли мы когда-нибудь продукты сборки одного уровня на другой, чтобы гарантировать разрешение зависимостей? Если нет, где живут двоичные файлы? Могут ли эти требования потребовать от нас использования GAC?

Наконец, если есть какие-либо указания по поводу такого рода вещей, я люблю читать. но, поскольку я новичок в разработке / выпуске, я еще не знаю, где искать.

Спасибо!

1 Ответ

1 голос
/ 10 августа 2011

Чтобы ответить на ваш последний вопрос первым, есть отличная книга от Microsoft о конфигурации сборки и управлении.

Что касается вашего первого вопроса: мы обрабатываем наши зависимости отдельно. У нас есть сборка, которая компилирует нашу структуру. У нас есть другая сборка, которая компилирует наши собственные проекты.

Однако, как часть процесса нашей второй сборки, мы устанавливаем установку из нашей сборки фреймворка на buildmachine перед компиляцией нашего собственного проекта.

Таким образом, мы можем выпускать нашу инфраструктуру отдельно от наших проектов. Наши проекты могут определить (путем изменения конфигурации сборки), когда начинать использовать новую версию.

Проект и структура имеют свои собственные проекты TFS.

...