Непрерывная интеграция проста. Загрузите Jenkins, установите, создайте задание, нажмите кнопку и получите красивое электронное сообщение о том, что ваша сборка нарушена (я предполагаю, что ваша сборка автоматизирована). Затем почините неисправные тесты (я предполагаю, что у вас есть тесты), и получите гораздо более привлекательную электронную почту, говорящую о том, что ваша сборка чиста. Затем напишите об этом, заявив, что ваша команда использует непрерывную интеграцию.
Я видел его несколько раз в нескольких проектах. Начало всегда яркое и гладкое. Проблемы начнутся позже, когда сборка снова сломается, и мы просто не успеем ее исправить. Мы просто заняты чем-то другим, и несколько сломанных юнит-тестов не должны отвлекать нас. В конце концов, мы все знаем, что модульное тестирование не для команды, работающей со сроками, правильно?
Неправильно. Непрерывная интеграция может и должна работать. Последняя сборка всегда должна быть чистой. Всегда.
Что такое непрерывная интеграция?
В настоящее время разработка программного обеспечения осуществляется в командах. Мы развиваемся в филиалах и изолируем изменения, пока они находятся в разработке. Затем мы объединяем ветки в master (предполагается использование Git). После каждого слияния мы тестируем весь продукт, выполняя все доступные тесты единиц и интеграции. Это то, что называется непрерывной интеграцией, сокращенно CI.
Иногда, некоторые тесты терпят неудачу. Когда это происходит, мы говорим, что наш «сборка нарушена». Такой сбой является положительным побочным эффектом контроля качества, потому что он поднимает красный флаг сразу после того, как ошибка попадает в мастер. Это хорошо известная практика, когда исправление этой ошибки становится главным приоритетом для ее автора и всей команды. Ошибка должна быть исправлена сразу после поднятия красного флага сервером непрерывной интеграции.
# Почему не работает непрерывная интеграция?
CI замечательный, но чем больше команда (и кодовая база), тем чаще билды ломаются. И, тем больше времени требуется, чтобы исправить их. Я видел много примеров, когда трудолюбивая команда начинает игнорировать красные флаги, поднятые Дженкинсом, через несколько недель или пытаясь не отставать.
Команда просто становится неспособной фиксировать все ошибки во времени. Главным образом потому, что у бизнеса есть другие приоритеты. Владельцы продуктов не понимают важности «чистой сборки», а технические лидеры не могут выиграть время на установление модульных тестов. Более того, код, который их нарушил, уже находится в режиме ведущего и, в большинстве случаев, уже развернут для производства и доставлен конечным пользователям. В чем срочность исправления некоторых тестов, если бизнес-ценность уже доставлена?
В конце концов, большинство команд разработчиков серьезно не воспринимают непрерывные оповещения о интеграции. Дженкинс или Трэвис - просто причудливые инструменты для них, которые не играют никакой роли во всем процессе разработки и доставки. Независимо от того, что говорит сервер непрерывной интеграции, мы по-прежнему предоставляем новые функции нашим конечным пользователям. Мы исправим нашу сборку позже. И это логично.
# Какое возможно решение?
Решение, которое я предлагаю, простое - запретить кому-либо объединять что-либо в
master ветку и создавать сценарии, которые могут вызвать все. Сценарий будет объединяться, тестироваться и фиксироваться. Скрипт не будет делать никаких исключений. Если какая-либо ветвь нарушает хотя бы один юнит-тест, вся ветка будет отклонена.
Другими словами, мы должны поднять этот красный флаг до того, как код попадет в master. Мы должны возложить вину за сломанные тесты на плечи его автора.
Скажем, я разрабатываю функцию в своей ветке. Я закончил разработку и случайно пробил несколько тестов. Бывает, мы все совершаем ошибки. Я не могу объединить мои изменения в мастер. Git просто отвергает мой
push, потому что у меня нет соответствующих разрешений. Все, что я могу сделать, это вызвать магический скрипт, попросив его объединить мою ветку. Сценарий попытается слить, но перед тем, как выложить на мастер, он запустит все тесты. И если кто-нибудь из них сломается, моя ветвь будет отвергнута. Мои изменения не будут объединены. Теперь моя ответственность - исправить их и снова вызвать скрипт.
В начале, этот подход замедляет развитие, потому что каждый должен начинать писать более чистый код. В конце, однако, этот метод окупает большое время.
В моих проектах я автоматизирую эту операцию слияния, используя www.rultor.com, бесплатный сервис DevOps. Его использование объясняется в этой статье: Rultor.com, слияние ботов.
Комментариев нет:
Отправить комментарий