Как управлять версиями инструментов и библиотек сборки?

Я думаю, что виртуальная машина - ваше лучшее решение. Мы всегда использовали специальные машины для сборки, чтобы добиться единообразия. В старые адские дни COM DLL существовали зависимости (COMCAT.DLL, кто угодно) от установленного программного обеспечения, не связанного с разработкой (Office). Первые два варианта не решают ничего, что имеет общие компоненты COM. Если у вас нет проблем с общими компонентами, возможно, они будут работать.

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

Это то, что очень характерно для вашей среды. Вот почему вы не увидите руководства, которое поможет справиться со всеми ситуациями. Все магазины, в которых я работал, справлялись с этим по-разному. Я могу высказать только свое мнение о том, что, по моему мнению, лучше всего сработало для меня.

• Поместите все необходимое для сборки приложения на новую рабочую станцию ​​под контролем версий.
• Не допускайте попадания в систему контроля версий больших приложений, таких как IDE, SDK и движки баз данных. Храните их в каталоге как файлы ISO.
• Поддерживайте текстовый документ с исходным кодом, в котором есть список файлов ISO, которые потребуются для создания приложения.

Я обязательно рассмотрю юридические / лицензионные вопросы, связанные с этой идеей. Будет ли это допустимо в соответствии с различными лицензиями вашей инструментальной цепочки?

Думали ли вы о создании новой машины для разработки, способной собрать релиз, если вам не нравится идея образа виртуальной машины? Конечно, поддерживать работу этого призрачного образа при смене оборудования может быть больше проблем, чем оно того стоит ...

Просто примечание о версиях библиотек в вашей системе контроля версий:

• это хорошее решение , но оно подразумевает упаковку (т.е. сокращение количества файлов этой библиотеки до минимума)
• он не решает «аспект конфигурации» (то есть «какой конкретный набор библиотек нужен моим проектам '3.2'?»).
  Не забывайте, что набор будет развиваться с каждой новой версией вашего проекта. UCM и его «составная базовая линия» могут дать начало ответа на этот вопрос.

Аспект упаковки (минимальное количество файлов) важен, потому что:

• вы не хотите получать доступ к своим библиотекам через сеть (например, через динамическое представление), потому что время компиляции намного больше, чем при использовании локальных файлов библиотеки, к которым осуществляется доступ.
• вы действительно хотите, чтобы эта библиотека была на вашем диске, что означает просмотр снимков, то есть загрузку этих файлов ... и именно здесь вы можете оценить упаковку своих библиотек: чем меньше файлов вы должны загрузить, тем лучше;)

В моей организации есть файловая система «только для чтения», в которой все размещено в выпусках и версиях. Ссылки на выпуск (по сути, символические ссылки) указывают на версию, используемую вашим проектом. Когда появляется новая версия, она просто добавляется в файловую систему, и вы можете переместить на нее свою символическую ссылку. Существует полная история аудита символических ссылок, и вы можете создавать новые символические ссылки для разных версий.

Этот подход отлично работает в Linux, но он не работает так хорошо для приложений Windows, которые, как правило, предпочитают использовать локальные для машины вещи, такие как реестр, для хранения таких вещей, как конфигурация.

Используете ли вы инструмент непрерывной интеграции (CI), такой как NAnt, для создания своих сборок?

В качестве примера .Net вы можете указать определенные фреймворки для каждой сборки.

Возможно, популярный инструмент CI для всего, что вы разрабатываете, имеет параметры, которые позволят вам избежать хранения нескольких IDE в вашей системе контроля версий.

Во многих случаях вы можете заставить свою сборку использовать компиляторы и библиотеки, проверенные в системе управления версиями, вместо того, чтобы полагаться на глобальные настройки компьютера, которые не будут повторяться в будущем. Например, с компилятором C # вы можете использовать переключатель / nostdlib и вручную / ссылаться на все библиотеки, чтобы указать на версии, зарегистрированные в системе управления версиями. И, конечно же, проверьте сами компиляторы в системе контроля версий.

В ответ на свой вопрос я наткнулся на эту публикацию Упомянул в ответе на другой вопрос. Хотя это больше обсуждение проблемы, чем ответ, идея VM упоминается.

Что касается «выяснения того, как строить при загрузке»: я разработал с использованием системы фермы сборки, очень быстро созданной по индивидуальному заказу одним системным администратором и одним разработчиком. Подчиненные устройства сборки запрашивают у диспетчера подходящие запросы на построение в очереди. Это очень мило.

Запрос является «подходящим» для подчиненного устройства, если его требования к инструментальной цепочке соответствуют версиям инструментальной цепочки на подчиненном устройстве, включая какую ОС, поскольку продукт является многоплатформенным, и сборка может включать автоматизированные тесты. Обычно это «современное состояние техники», но не обязательно.

Когда ведомое устройство готово к сборке, оно просто начинает опрашивать диспетчера задач, сообщая ему, что у него установлено. Ему не нужно заранее знать, что он собирается построить. Он получает запрос на сборку, в котором говорится, что нужно проверить определенные теги из SVN, а затем запустить сценарий из одного из этих тегов, чтобы взять его оттуда. Разработчикам не нужно знать, сколько доступно ведомых устройств сборки, как они называются и заняты ли они, только как добавить запрос в очередь сборки. Сама очередь сборки представляет собой довольно простое веб-приложение. Все очень модульное.

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

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