Как бы вы определили Непрерывную интеграцию и какие конкретные компоненты содержит сервер CI?
Я хочу объяснить кому-то из отдела маркетинга, что такое непрерывная интеграция. Они понимают контроль источников - то есть они используют Subversion. Но я бы хотел им правильно объяснить, что такое КИ. Википедия Статья никогда правильно определяет это, статья Мартина Фаулера дает лишь следующее, которая в основном тавтология с последующей смутным объяснением «интеграции»:
Непрерывная интеграция - это практика разработки программного обеспечения, при которой члены команды часто интегрируют свою работу, обычно каждый человек интегрируется по крайней мере ежедневно, что приводит к множественным интеграциям в день. Каждая интеграция проверяется автоматизированной сборкой (включая тестирование) для максимально быстрого выявления ошибок интеграции.
Обновление : я послал им это изображение, я не мог найти более простое.
Обновление 2 : обратная связь из маркетинговой главы (для времени, когда было 3 вопроса):
Мне на самом деле нравятся все 3 ответа - по разным причинам. Мне хочется войти, чтобы поблагодарить их всех!
Очевидно, что он не может - так что спасибо от его имени :)
Обновление 3 : я понял из статьи в Википедии, что в ней содержатся принципы, которые, если взять только заголовки, представляют собой неплохой список:
- Поддерживать хранилище кода
- Автоматизировать сборку
- Сделай самотестирование сборки
- Каждый человек придерживается базового уровня каждый день
- Каждый коммит (до базовой линии) должен быть построен
- Продолжайте строить быстро
- Испытание в клоне производственной среды
- Сделать это легко, чтобы получить последние результаты
- Каждый может увидеть результаты последней сборки
- Автоматизировать развертывание
Ответы:
Когда кто-то изменяет файлы, составляющие программный продукт, а затем пытается их зарегистрировать (другими словами, пытается интегрировать изменения в основной код продукта), вы хотите убедиться, что программный продукт все еще может быть успешно собран.
Обычно существует внешняя система, называемая CI-сервером , которая периодически или при каждом изменении извлекает исходные файлы из системы управления версиями и пытается собрать продукт (compile / test / package). Если CI-сервер может успешно выполнить сборку, изменения были успешно интегрированы.
Сервер CI также должен иметь возможность широковещательной передачи, если сборка не удалась или прошла успешно, поэтому такие системы, как Jenkins (один из наиболее используемых сегодня серверов CI), будут иметь способы отправки электронных писем / текстов, а также веб-интерфейс в виде панели инструментов с куча информации о текущих и прошлых сборках, кто зарегистрировал код, когда что-то сломалось и т. д. (На вашем изображении выше это будет механизм обратной связи .)
КИ важен, потому что он гарантирует, что на постоянной основе у вас есть рабочий продукт. Это важно для всех разработчиков, которые работают над программным продуктом, а также для всех людей, которые хотят иметь доступ к ежедневным версиям программного продукта, таким как QA.
источник
Я полагаю, для вашего отдела маркетинга важно не то, как работает CI , а то , что CI означает для новых версий вашего программного обеспечения .
В идеале CI означает, что вы можете каждый день выпускать новую потенциально выпускаемую версию программного обеспечения, готовую для представления или продажи вашему клиенту, с добавлением некоторых новых функций, функций или исправлений. Это не означает, что вы должны доставлять новую версию каждый день, но вы можете, если хотите.
Например, если у вас есть новый набор функций, запланированный к официальному выпуску для вашей версии программного обеспечения «2015», и у вас есть части этого набора функций, уже закодированные и интегрированные сегодня, маркетологи могут взять текущую версию вашего программного обеспечения и покажите его - более или менее безопасно - на следующей конференции, которая состоится сейчас в 2013 году. Без КИ им пришлось просить вашу команду о незапланированном замораживании кода, каждому члену команды приходилось интегрировать в него свою половинку, над которой он работает. продукта, у них может не хватить готовых автоматических тестов, и угадайте, что произойдет на конференции - «альфа-версия» вашего выпуска 2015er будет иметь гораздо более высокий риск сбоя, особенно когда демонстрируются новые функции.
источник
Вы не можете знать, что такое КИ, если не знаете, что мы делали раньше. Представьте себе систему из 3 частей. Есть пользовательский интерфейс, который собирает данные и помещает их в базу данных. Есть система отчетности, которая делает отчеты из базы данных. И есть какой-то сервер, который контролирует базу данных и отправляет оповещения по электронной почте, если соблюдены определенные критерии.
Давно это было бы написано следующим образом:
В течение этого времени разработчики не запускали код друг друга и не пытались использовать версию базы данных, созданную чужим кодом. Автор отчетов просто добавит несколько примеров данных. Автор оповещения вручную добавит записи, имитирующие события отчета. И писатель GUI будет смотреть на базу данных, чтобы увидеть, что GUI добавил. Со временем разработчики поймут, что спецификация в некотором роде неверна, например, не указание индекса или слишком короткая длина поля, и «исправление» в своей версии. Они могут рассказать остальным, кто может действовать, но обычно эти вещи попадают в список на потом.
Когда все три части были полностью закодированы и протестированы их разработчиками, а иногда даже протестированы пользователями (показывая им отчет, экран или оповещение по электронной почте), наступает фаза «интеграции». Это часто планировалось на несколько месяцев, но все равно продолжалось. Это изменение длины поля на dev 1 будет обнаружено здесь, и потребуются dev 2 и 3, чтобы сделать огромные изменения кода и, возможно, изменения пользовательского интерфейса. Этот дополнительный индекс нанесет свой собственный ущерб. И так далее. Если бы один из разработчиков сказал пользователю добавить поле, и он сделал это, сейчас настало время, когда два других должны были добавить его также.
Этот этап был чрезвычайно болезненным и почти невозможно предсказать. Люди стали говорить: «Мы должны чаще интегрироваться». «Мы должны работать вместе с самого начала». «Когда один из нас поднимает запрос на изменение [так мы тогда говорили], другие должны знать об этом». Некоторые команды начали проводить интеграционные тесты ранее, продолжая работать отдельно. И некоторые команды начали использовать код друг друга и выводить все время, с самого начала. И это стало непрерывной интеграцией.
Вы можете подумать, что я преувеличиваю эту первую историю. Однажды я выполнил какую-то работу для компании, где мой собеседник разжевал меня за проверку некоторого кода, который страдает от следующих недостатков:
Это было его мнение, что вы не помещаете вещи в систему контроля версий, пока они не СДЕЛАНЫ. Обычно он делал один или два чеканы в ГОД. У нас была небольшая разница в философии :-)
Кроме того, если вам трудно поверить, что команды будут разъединены вокруг общего ресурса, такого как база данных, вы действительно не поверите (но это правда), что тот же подход был применен к коду. Вы собираетесь написать функцию, которую я могу вызвать? Это здорово, продолжайте и сделайте это, я просто напишу то, что мне нужно в это время. Месяцы спустя я «интегрирую» свой код, чтобы он вызывал ваш API, и мы обнаружим, что он взрывается, если я передаю ноль, я взрываюсь, если он возвращает ноль (и это часто), он возвращает слишком большие объекты для меня это не может справиться с високосными годами и тысячами других вещей. Работать независимо, а затем иметь фазу интеграции было нормально. Теперь это звучит как безумие.
источник