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

Question

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

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

Answer 1

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

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

Answer 2

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

(Кстати, я бы не охарактеризовал это как "NIH")

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

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

Answer 3

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

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

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

В частности, если вы ищете расширяемость, Hudson будет отличным выбором - у него отличная архитектура плагинов, и автор доступен для платной консультационной работы - вероятно, НАМНОГО лучше ваши ресурсы, чем накатить свои собственные.

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

Answer 4

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

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

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

Наконец, мы (по моему настоянию) отказались от написанной вручную системы сценариев Perl, которую я написал, и мы приобрели коммерческую систему: Сборки и ошибки Zed

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

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

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

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

Answer 5

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

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

Answer 6

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

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

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

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

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