Как контролировать версию инструментов сборки и библиотек? - PullRequest
6 голосов
/ 23 сентября 2008

Каковы рекомендации по включению вашего компилятора, библиотек и других инструментов в саму систему управления версиями?

В прошлом я сталкивался с проблемами, когда, хотя у нас был весь исходный код, создание старой версии продукта было упражнением в поисках точной правильной конфигурации Visual Studio, InstallShield и других. инструменты (включая правильную версию патча), используемые для сборки продукта. В моем следующем проекте я бы хотел избежать этого, включив эти инструменты сборки в систему управления версиями, а затем собрав их с помощью. Это также упростило бы настройку нового компьютера для сборки: 1) установить наш инструмент управления исходным кодом, 2) указать на правую ветвь и 3) собрать - и все.

Опции, которые я рассмотрел, включают:

  • Копирование установочного компакт-диска ISO в систему управления исходным кодом - хотя это и обеспечивает нам необходимую резервную копию, если мы хотим вернуться к более старой версии, это не очень хороший вариант для «живого» использования (каждая сборка должна начинаться с шаг установки, который может легко превратить 1-часовую сборку в 3 часа).
  • Установка программного обеспечения для контроля версий. ClearCase сопоставляет вашу ветку с буквой диска; мы могли бы установить программное обеспечение под этот диск. Это не учитывает не-файловую часть установки ваших инструментов, такую ​​как настройки реестра.
  • Установка всего программного обеспечения и настройка процесса сборки внутри виртуальной машины, хранение виртуальной машины в системе контроля версий и выяснение того, как заставить виртуальную машину выполнить сборку при загрузке. Хотя мы с легкостью фиксируем состояние «машины сборки», мы получаем дополнительную нагрузку на ВМ, и это не помогает с «сделать те же инструменты доступными для разработчиков».

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

Ответы [ 9 ]

5 голосов
/ 23 сентября 2008

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

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

4 голосов
/ 23 сентября 2008

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

  • Положите все необходимое, чтобы построить приложение на новой рабочей станции под контролем источника.
  • Держите большой приложения из-под контроля исходного кода, такие вещи, как IDE, SDK и базы данных двигатели. Храните их в каталоге в виде файлов ISO.
  • Ведение текстового документа с исходным кодом, содержащего список файлов ISO, необходимых для создания приложения.
2 голосов
/ 23 сентября 2008

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

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

1 голос
/ 23 сентября 2008

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

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

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

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

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

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

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

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

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

0 голосов
/ 23 сентября 2008

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

0 голосов
/ 23 сентября 2008

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

0 голосов
/ 23 сентября 2008

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

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

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

0 голосов
/ 23 сентября 2008

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...