регистрация или нет регистрация, которая будет предпочтительнее в прозрачном UCM? - PullRequest
1 голос
/ 04 января 2012

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

когда мы регистрировались, мы просто делали символические ссылки, и это давало нам большое преимущество.Более того, когда регистрация будет завершена, она будет удалять записи из папки bin и release вместо копии.Это нам очень помогло.Каждый день люди могли работать с последней версией сборок при ночной сборке.Теперь они не могут этого сделать.Они хотят, чтобы я скопировал dll Nightly build в какое-то обычное место.

С другой стороны, из-за каждодневной регистрации наш репозиторий становится огромным.

Я не знаю, какой был лучший вариант.

Не могли бы вы поделиться своими мыслями о том, какой метод лучше?Лучше ли проверять сборки в UCM / Clearcase или нет?

Ответы [ 2 ]

2 голосов
/ 04 января 2012

На практике все выходные данные сборки не должны находиться под контролем исходного кода.Но вы должны держать их в обычном месте, пока они не истекают.Философия этой практики такова:

  1. Размер хранилища увеличивается по мере добавления в него двоичных файлов.
  2. Старые версии сборки, произведенной в ночной сборке (принадлежит 2 года назад), бесполезны.С другой стороны, старая версия исходных кодов и ее история полезны все время.
  3. В дополнение к результатам сборки программные продукты обычно зависят от сторонних компонентов.Эти сторонние компоненты обычно развиваются, и их новые версии обычно выпускаются.Сохраняя результаты сборки в системе контроля версий, вы должны хранить правильную версию сторонних компонентов в другом месте.
1 голос
/ 05 января 2012

Другая причина, препятствующая возврату сборок в ClearCase, заключается в отсутствии возможности очистки: вы не можете легко rmver некоторые версии, которые вам могут не понадобиться, без потенциальной угрозы для репозитория Vob.

Это особенно верно в UCM, где метаданные и гиперссылки добавляются в версии, что делает удаление одного весьма опасным для целостности других объектов (например, базовой линии UCM) в зависимости от него.

Другие, более общие причины для , а не двоичных файлов версий см. В разделе " Эффективная практика - хранить среды выполнения фреймворка под контролем исходного кода? * И hsalimi ответ .

...