Что нужно учитывать при написании собственного сервера непрерывной интеграции?

Question

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

Мы рассмотрели несколько коммерческих серверов CI, и, похоже, объем работы, связанной с настройкой любого из них по нашим индивидуальным потребностям, относительно высок; настолько высока, что, возможно, стоит потратить время, чтобы просто написать собственный CI-сервер. Тем не менее, я чувствую, что мы можем упустить некоторые потенциальные проблемы этого процесса. Был поднят и рассмотрен вопрос об ошибках в нашей реализации; есть ли какие-либо другие важные соображения (кроме, конечно, объема усилий, связанных с написанием системы CI), которые мы должны учитывать при оценке наших вариантов? От тех, кто реализовал пользовательский CI-сервер, каковы были особые проблемы? И от любого, кто использовал коммерческую систему CI, были ли какие-то вещи, которые вы хотели бы сделать сами, или вещи, которые вы особенно были счастливы, вам не нужно было делать сами?

Answer 1

Я бы настоятельно советовал против этого мышления NIH.

• Рассмотрим модификацию открытого сервера CI источника как CruiseControl.NET
• Рассмотрим написание пользовательских NANT задач
• рассмотреть вопрос об изменении проекта, чтобы быть более восприимчивыми к существующим вариантов
• Вы не хотите быть в бизнес непрерывной интеграции, вы хотите просто использовать его и увидеть преимущества

Answer 2

Вместо полномасштабного сервера CI, почему бы вам не просто создать индивидуальные элементы, которые вам нужны? Повторно используйте столько, сколько вы можете, а не иметь ВСЕГО обычая, вы можете по крайней мере сделать некоторые части с полки.

(Кстати, я бы не стал характеризовать это как «НИЗ»)

Обратите внимание, что даже если вы проводите так много времени, настройка сборок для работы с существующим сервером CI, как вы бы создать свой собственный (вероятно, щедрый здесь), вам тогда нужно только поддерживать каждый пользовательский бит, а не всю структуру.

Посмотрите, что вы можете использовать, и работать с ним. Также посмотрите, какой инструмент, похоже, обещает двигаться в том направлении, в котором вы собираетесь двигаться. Ни один сервер CI не будет работать отлично в вашей среде прямо из коробки. Все они должны быть переделаны и «встречены на полпути».

Answer 3

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

Сборка продукта была выполнена на сборке env и для запуска тестов, а сам продукт должен быть перенесен в целевую среду. Таким образом, он включал кросс-компиляцию. Мы не использовали коммерческое или постоянное интеграционное решение с открытым исходным кодом, но мы использовали набор сценариев bash (не было времени для создания разумного решения :() Выполнение тестов (не имеет значения, если единица, интеграция, здравомыслие , компоненты и т. д.).

Итак, вопрос, который вы можете задать, - это среда разработки? Где бы вы хотели запустить тесты? (Мы тестировали цель и небольшую часть теста на сборке env) Является ли целевая среда такой же, как среда разработки? Вам нужно построить для разных конфигураций (платформа, sw и т. Д.)?

Вы не указали, какие языки вы используете. Я знаю, что это может быть неуместно, но это не так :) (Даже java ведет себя по-разному на разных платформах (x86 vs x86-64)

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

Answer 4

вещи, которые я хотел бы рассмотреть:

• Какой опыт у нас в команде в этом домен
• Является ли график, чтобы люди в команде могли вставить e время, чтобы узнать о дизайне серверов CI?
• Есть ли бюджет, чтобы нанимать людей с помощью этого знания домена в дополнение к команде?
• Почему, по вашему мнению, вы можете сделать это лучше, чем существующие решения?

Answer 5

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

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

Прежде чем перейти к решению с открытым исходным кодом, я реализовал внутреннюю систему CI «бедный человек» и обнаружил, что системы с открытым исходным кодом были намного лучше, полными и надежными, что мое усилие было бессмысленным.

В частности, если вы ищете расширяемость, Hudson будет отличным выбором - у него отличная плагиновая архитектура, и автор доступен для платных консультационных работ - возможно, БОЛЬШЕ лучше использовать ваши ресурсы, своя.

В качестве стороны, до моего участия в процессе сборки, сборка продукта была 14,5-часовым делом без автоматического тестирования, упаковки или CM. Благодаря некоторым усилиям и следуя передовым практикам, изложенным существующим сообществом CI, такая же сборка проекта доходит до 7,5 минут, с автоматическим тестированием, упаковкой и CM. По моему опыту, определенно стоит потратить несколько усилий на то, чтобы работать над вашей сборкой, чтобы соответствовать существующим передовым опытам опытного сообщества CI, а не пытаться сделать CI изгибом существующей сборки.

Answer 6

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

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

Все это уходило далеко от нашего основного внимания - нашей собственной разработки программного обеспечения.

Наконец, мы имеем (в моем убеждении) угробили руки выстроенной системы скриптов на языке Perl, который я написал, и мы приобрели коммерческую систему: Zed Builds and Bugs

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

И самое главное, я взять отпуск снова :-)

Я все еще одна обработка большинства задач, с системой сборки, но это не вопрос о написании его больше. Речь идет о адаптации наших существующих make-файлов, проектов Visual Studio, скриптов сборки Ant и т. Д. К новой системе.

Поверьте мне, в этом случае гораздо проще покупать и строить. Ваш основной бизнес не создает систему сборки (или вы не задали бы вопрос). Сосредоточьтесь на своем основном бизнесе и купите инструменты, необходимые для всего остального.