Наличие dist в системе управления версиями может считаться хорошей практикой, если вы хотите, чтобы ваша система управления версиями была уникальной ссылочной для всех:
- Разработчики
- ассемблеры (юнит-тестирование)
- омологационные тестеры (вы запрашиваете кучу dist на своей платформе интеграции и выполняете там свои нерегрессионные тесты, тесты производительности, стресс-тесты и т. д.)
- менеджеры по выпуску продукции ...
НО вам нужен надлежащий процесс выпуска, чтобы справиться с этим.
В вашем случае сборка должна находиться в отдельном и частном каталоге, то есть в каталоге, не подвергающемся подрывной деятельности. Когда сборка прошла успешно, вы импортируете ее в Subversion, если это официальный выпуск, или импортируете в общий каталог, если это временная сборка, которая просто необходима следующей команде (что позволяет избежать фиксации сотен сборок в SCM, используя пространство для ничего).
Примечание. Основным преимуществом наличия доставки (dist) в SCM является то, что зависимый проект может работать не с вашими источниками, а напрямую с вашей доставкой (которая связана чтобы перейти в тот или иной момент в производство): если им удастся заставить свой код работать, компилируя с вашей доставкой, скорее всего, их собственный dist, когда развернут с вашим, будет работать.
Таким образом, другие команды получат доступ ваша доставка (ваш myProject.jar), когда они обращаются к любому из своих источников: они могут прочитать через SCM версию вашего jar-файла, его дату, его историю, его метаданные, его метку и т. д.
Однако для одного небольшого монолитного проекта (например, «от него не зависят другие проекты») можно утверждать, что dist (окончательная пакетная поставка) может быть перекомпонован по запросу и сохранен во внешней ссылочной системе < / strong>, например, в качестве внешнего репозитория Maven.
НО: Maven не является репозиторием SCM, что означает, что вам нужно подписать свой jar ('MyProject-1.0.jar'), у вас нет истории, и вам нужно сообщить все ваши метаданные в отдельном текстовом файле вместе с доставкой. Любой другой проект, имеющий доступ к этой доставке в этом репозитории Maven, должен скорректировать свои скрипты и пути к классам в соответствии с вашим соглашением об именах версий.
Кроме того, Maven - это еще один репозиторий в вашей архитектуре разработки. Когда вы можете свести количество репозиториев к минимуму («1»;)), это лучше.
person
VonC
schedule
21.10.2008
