Простое объяснение непрерывной интеграции

32

Как бы вы определили Непрерывную интеграцию и какие конкретные компоненты содержит сервер CI?

Я хочу объяснить кому-то из отдела маркетинга, что такое непрерывная интеграция. Они понимают контроль источников - то есть они используют Subversion. Но я бы хотел им правильно объяснить, что такое КИ. Википедия Статья никогда правильно определяет это, статья Мартина Фаулера дает лишь следующее, которая в основном тавтология с последующей смутным объяснением «интеграции»:

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

Обновление : я послал им это изображение, я не мог найти более простое.

введите описание изображения здесь

Обновление 2 : обратная связь из маркетинговой главы (для времени, когда было 3 вопроса):

Мне на самом деле нравятся все 3 ответа - по разным причинам. Мне хочется войти, чтобы поблагодарить их всех!

Очевидно, что он не может - так что спасибо от его имени :)

Обновление 3 : я понял из статьи в Википедии, что в ней содержатся принципы, которые, если взять только заголовки, представляют собой неплохой список:

  1. Поддерживать хранилище кода
  2. Автоматизировать сборку
  3. Сделай самотестирование сборки
  4. Каждый человек придерживается базового уровня каждый день
  5. Каждый коммит (до базовой линии) должен быть построен
  6. Продолжайте строить быстро
  7. Испытание в клоне производственной среды
  8. Сделать это легко, чтобы получить последние результаты
  9. Каждый может увидеть результаты последней сборки
  10. Автоматизировать развертывание
icc97
источник
3
oO Ваш отдел маркетинга использует Subversion? Соблазн голосовать, чтобы закрыться как "Слишком Локализованный" ... ;-)
Jeroen
@Jeroen Да, действительно, для файлов на сайте. Я сделал им красивую большую красную кнопку на веб-странице с надписью «Сделай это» для обновления Subversion на сервере. :)
icc97

Ответы:

27

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

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

Сервер CI также должен иметь возможность широковещательной передачи, если сборка не удалась или прошла успешно, поэтому такие системы, как Jenkins (один из наиболее используемых сегодня серверов CI), будут иметь способы отправки электронных писем / текстов, а также веб-интерфейс в виде панели инструментов с куча информации о текущих и прошлых сборках, кто зарегистрировал код, когда что-то сломалось и т. д. (На вашем изображении выше это будет механизм обратной связи .)

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

c_maker
источник
1
Непрерывная интеграция заботится как о состоянии сборки, так и о тестах.
Квентин Праде
1
и развертывание, его недостаточно для компиляции и запуска тестов, но вы также должны отправить двоичные файлы в среду, чтобы их тоже могли тестировать люди (или автоматизированные инструменты).
gbjbaanb
1
Поскольку вопрос требовал простого объяснения, я упустил многие (в большинстве случаев относящиеся к конкретному проекту / команде) детали, которые могли бы войти в систему CI.
c_maker
Зависит ли это от разработки, основанной на тестировании? Код, который компилируется, не всегда работает правильно? Если тесты не пройдут, когда код не готов, как система CI узнает, действительно ли код успешно интегрирован?
Mowwwalker
1
@ user828584: В своем ответе я подразумеваю, что 'test' является частью сборки. И как примечание стороны, TDD отличается от наличия тестов для проверки качества. Как побочный эффект TDD, у вас будут хорошо написанные тесты, но вы можете иметь тесты, вообще не делая TDD.
c_maker
33

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

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

Например, если у вас есть новый набор функций, запланированный к официальному выпуску для вашей версии программного обеспечения «2015», и у вас есть части этого набора функций, уже закодированные и интегрированные сегодня, маркетологи могут взять текущую версию вашего программного обеспечения и покажите его - более или менее безопасно - на следующей конференции, которая состоится сейчас в 2013 году. Без КИ им пришлось просить вашу команду о незапланированном замораживании кода, каждому члену команды приходилось интегрировать в него свою половинку, над которой он работает. продукта, у них может не хватить готовых автоматических тестов, и угадайте, что произойдет на конференции - «альфа-версия» вашего выпуска 2015er будет иметь гораздо более высокий риск сбоя, особенно когда демонстрируются новые функции.

Док Браун
источник
4
+1 за подход к нему с точки зрения пользы, которую он дает.
тыкать
17

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

Давно это было бы написано следующим образом:

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

В течение этого времени разработчики не запускали код друг друга и не пытались использовать версию базы данных, созданную чужим кодом. Автор отчетов просто добавит несколько примеров данных. Автор оповещения вручную добавит записи, имитирующие события отчета. И писатель GUI будет смотреть на базу данных, чтобы увидеть, что GUI добавил. Со временем разработчики поймут, что спецификация в некотором роде неверна, например, не указание индекса или слишком короткая длина поля, и «исправление» в своей версии. Они могут рассказать остальным, кто может действовать, но обычно эти вещи попадают в список на потом.

Когда все три части были полностью закодированы и протестированы их разработчиками, а иногда даже протестированы пользователями (показывая им отчет, экран или оповещение по электронной почте), наступает фаза «интеграции». Это часто планировалось на несколько месяцев, но все равно продолжалось. Это изменение длины поля на dev 1 будет обнаружено здесь, и потребуются dev 2 и 3, чтобы сделать огромные изменения кода и, возможно, изменения пользовательского интерфейса. Этот дополнительный индекс нанесет свой собственный ущерб. И так далее. Если бы один из разработчиков сказал пользователю добавить поле, и он сделал это, сейчас настало время, когда два других должны были добавить его также.

Этот этап был чрезвычайно болезненным и почти невозможно предсказать. Люди стали говорить: «Мы должны чаще интегрироваться». «Мы должны работать вместе с самого начала». «Когда один из нас поднимает запрос на изменение [так мы тогда говорили], другие должны знать об этом». Некоторые команды начали проводить интеграционные тесты ранее, продолжая работать отдельно. И некоторые команды начали использовать код друг друга и выводить все время, с самого начала. И это стало непрерывной интеграцией.

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

  • экран, над которым он не работал, имел кнопку, которая еще ничего не делала
  • никто не подписывался на дизайн экрана (точные цвета и шрифты; наличие экрана, его возможности и какие кнопки были в спецификации на 300 страниц).

Это было его мнение, что вы не помещаете вещи в систему контроля версий, пока они не СДЕЛАНЫ. Обычно он делал один или два чеканы в ГОД. У нас была небольшая разница в философии :-)

Кроме того, если вам трудно поверить, что команды будут разъединены вокруг общего ресурса, такого как база данных, вы действительно не поверите (но это правда), что тот же подход был применен к коду. Вы собираетесь написать функцию, которую я могу вызвать? Это здорово, продолжайте и сделайте это, я просто напишу то, что мне нужно в это время. Месяцы спустя я «интегрирую» свой код, чтобы он вызывал ваш API, и мы обнаружим, что он взрывается, если я передаю ноль, я взрываюсь, если он возвращает ноль (и это часто), он возвращает слишком большие объекты для меня это не может справиться с високосными годами и тысячами других вещей. Работать независимо, а затем иметь фазу интеграции было нормально. Теперь это звучит как безумие.

Кейт Грегори
источник
2
У нас была похожая история, в которой мы обновили пользовательское приложение, построенное на SP 2003, до SP 2007. Используя VSS (да, VSS :), каждый разработчик извлекал часть своего файла, закодированную в течение недели и двух, затем, когда мы интегрировали наш код, бум, это когда проблема началась, так как наш код значительно отклонился. Мы исправили проблему интеграции на месяц, и проект арендовал отель для размещения тех, кто живет очень далеко в будние дни. В тот день я научился ежедневно интегрировать код :-)
OnesimusUnbound
@OnesimusUnbound Я помню, как меня врезали из VSS в Clearcase ... из кастрюли в огонь. Спустя годы после возвращения в ту же компанию за напитками, я помню, как кто-то смеялся над коллегой-разработчиком, который упомянул об этом новом контроле исходного кода под названием «Git», «Зачем нам нужна еще одна система контроля за исходным кодом?».
icc97
1
Спасибо - я пытался понять CI раньше просто потому, что я не знал, какова была альтернатива
Рис
Интересный. Для меня это больше похоже на сравнение CI с водопадом. Но вы можете использовать методологию без водопада, которая позволяет избежать этих проблем (например, итеративная разработка) и не использовать CI.
Дэн Молдинг
@DanMoulding, если я проворный и итеративный и так далее в моей части большей вещи, которая не интегрирована с тем, что делает кто-то еще, я не делаю CI. Черт возьми, вы можете водопад и CI. Проектируйте все это, кодируйте все это, проверяйте все это, если хотите - если все постоянно используют макеты кода / схемы / файла всех остальных, это CI, даже если вы используете водопад. Связь заключается в том, что без CI вы живете и умираете от BDUF, потому что это ваша единственная надежда (и оказывается, слабая надежда) на фазу интеграции разумной продолжительности. Принятие CI позволило нам отпустить BDUF.
Кейт Грегори