Что вы используете для серверов Artage / Staging / Deployment?

Question

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

Так что вы используете для хранения ваших сборок для внутреннего доступа?

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

Я определяю организацию как размещение встроенных артефактов на сервере для сообществ пользователей, имеющих доступ к . Артефакты обычно представляют собой zip-файлы, содержащие приложения или библиотеки + документацию. Сообщества пользователей - это разработчики, QA и службы доставки / операций. В основном, создатели, контролеры и внешние пользователи.

Мы выпускаем артефакты индивидуально и в виде групп в транспортном средстве выпуска (например, выпуск 1.1 содержит foo 1.0.1 и столбец 1.0.7). В зависимости от артефакта мы можем захотеть ограничить доступ. Операции не должны иметь доступа к предварительно выпущенным сборкам, и мы можем захотеть отследить, кто загружает релиз с ограниченной доступностью.

Итак, я надеюсь найти инструмент, который сделает большую часть того, что я хочу, с хорошим расширяемым дизайном, чтобы я мог добавить то, чего у меня нет.

Кто-нибудь знает хороший инструмент для управления сборками после сборки?

Примеры могут быть:

• quickbuild / lunt build
• Командная кузница
• сборка кузницы
• Джира и слияние как набор
• Сонатип Нексус
• доморощенный
• Репозиторий SVN с использованием ветвления для продвижения сборок из dev-> Qa-> GA

Answer 1

Мои варианты

системы автоматизации сборки, такие как AntHill, QuickBuild, TeamForge, BuildForge

• файловый сервер
• сервер управления исходным кодом
• менеджер хранилища maven (nexus, archiva)

Мои цели

• построение группы по нескольким критериям (тип артефакта, транспортное средство, этап / фаза)
• продвигать сборку с dev -> qa -> выпустили
• обеспечивает контроль доступа для сборок разработчика, готовых сборок, сборок, готовых к производству

Я собираюсь сосредоточиться либо на управлении исходным кодом в качестве файлового сервера (используя svn), либо на менеджере репозиториев maven в качестве файлового сервера с использованием nexus. Рациональное следующее:

• минимизировать усилие
• минимизировать стоимость
• используйте что-то, что я могу легко расширить при необходимости (потому что я уверен, что мои требования изменятся).
• использование maven растет и в конечном итоге станет доминирующей технологией сборки.

Спасибо за информацию.

Answer 2

Питер,

Поскольку вы не получаете много ответов, я сообщу вам о AnthillPro , разработчиком которого я работаю, Urbancode.

Ладно, исключая отказ от ответственности, AnthillPro разработан для обслуживания именно той широкой аудитории, которую вы обсуждаете - разработчиков, контролеров и операций. По сравнению с перечисленными вами инструментами AnthillPro - это что-то вроде BuildForge (нашего ключевого конкурента) или быстрая сборка с тесно интегрированным репозиторием артефактов (например, Nexus). Таким образом, сборки запускаются, и вы можете просматривать результаты своих сборок - и артефакты сборки - в хорошем веб-интерфейсе. Пользователи с правильными разрешениями могут запускать вторичный процесс, например, развертывание или тестирование на основе предыдущих сборок, а также артефакты из выбранной сборки.

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

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

В тех случаях, когда AnthillPro может показаться вам неэффективным, мы обычно разрешаем операциям просматривать предварительные сборки. Тем не менее, вы можете добавить правила, которые сразу же будут давать сбой / блокировать попытки восстановления при выполнении операций любой сборки, не помеченной как «предварительная версия». Система статусов AnthillPro позволяет команде пометить сборку с помощью пользовательских маркеров, таких как «In QA» или «Approved for Release». В сочетании с правилами запуска рабочих процессов это должно дать вам необходимый контроль. Если некоторые проекты особенно чувствительны, вам нужно просто использовать безопасность на основе ролей, чтобы их заблокировать.

Надеюсь, это даст вам возможность взглянуть.

- Эрик