Рекомендовать Build Artifact Repository Manager
В настоящее время мы используем FTP для поддержки сборки сборки артефактов и сторонних продуктов (только для внутреннего использования).
Артефакты - это документы (HTML/pdf/chm/...), libs (.dll/.so/.a/.jar/...), программы (.exe/.jar/...) и что-нибудь еще. Они не ограничены Java/.NET и могут поступать из разных культур (прошивка, драйвер, мобильная/рабочая станция, графический интерфейс, Win/Linux/Mac/Solaris/AIX,... и т.д.).
Для orginize hierarhy мы используем такие пути:
ftp://3pp/VENDOR/PRODUCT/VERSION/...
ftp://3pp/opensource/PACKAGE-x.x.x.tar.bz2
ftp://dist/PRODUCT/VERSION/...
Чтобы поддерживать описание артефактов, мы используем README и CHANGES простые тестовые файлы (reStructuredText).
Что отсутствует в этой схеме?
- Отсутствующие разрешения (любой может повредить хранилище).
- Отсутствует отслеживание зависимостей (поэтому каждый файл сборки должен быть обновлен, если изменилась зависимость версии).
- Отсутствует загрузочная активность (некоторые файлы больше не нужны, но мы не знаем, что).
Я не очень ищу существующие решения. Некоторые менеджер пакетов, такие как rpm/dpkg, слышали о Maven repo и т.д.
Пожалуйста, порекомендуйте администраторам сборки сборщиков артефактов. Также хорошо слышать недостатки и ограничения.
UPDATE
Ответы
Ответ 1
Вы создаете специализированный репозиторий артефактов программного обеспечения. Есть три проекта с открытым исходным кодом, которые уже делают это:
У Artifactory и Nexus также есть платные версии.
Вы можете хранить любые файлы в этих хранилищах, и вам не нужно использовать Maven. Вы можете вручную использовать артефакты для них. Вы можете настроить мелкий контроль доступа. Они хорошо интегрируются с автоматизированными инструментами построения.
Я думаю, что использование одного из этих инструментов сэкономит вам массу усилий!
Здесь довольно несмещенная (ориентированная на сообщества) матрица сравнения между тремя.
Ответ 2
С SVN + Apache (mod_dav_svn.so, mod_authz_svn.so) кажется, что я получаю:
