Непрерывная интеграция (continuous integration, CI) — это методология организации процесса разработки программных систем, при которой каждое изменение исходного кода, как и поведение самой системы с внесенным изменением, подвергается набору различных проверок.
Непрерывная интеграция позволяет на постоянной основе следить за различными метриками качества кода, обнаруживать ошибки сборки, замечать наличие дефектов в программном продукте на более ранних этапах разработки, экономя драгоценное время и уменьшая стоимость как разработки, так и исправления дефектов. Благодаря тому, что каждое изменение подвергается набору автоматических проверок, для клиента открывается возможность постоянного наблюдения за ходом разработки, качеством и статусом готовности той или иной функции системы.
Почему тест Джоэла до сих пор актуален?
Обычно для определения профессионального уровня команды разработки требуются недели, если не месяцы. Широко известный тест Джоэла позволяет легко оценить этот уровень за короткое время. Три первых вопроса теста самые важные:
- Используете ли вы систему контроля ревизий?
- Можете ли вы сделать сборку за один шаг?
- Делаете ли вы ежедневные сборки?
Положительные ответы на них не дают никаких гарантий, что перед вами команда грамотных и опытных разработчиков. Обратное же позволяет утверждать: если хотя бы один из ответов отрицателен, будьте уверены — такая команда требует перемен. Сами формулировки этих фундаментальных вопросов помогают командам понять выгоды и ценность от использования непрерывной интеграции — проекты могут развиваться и расти наиболее органичным образом в постоянно изменяющихся условиях (изменение требований, состава команды и т. д.). Не всегда наличие непрерывной интеграции в ИТ-проектах говорит о том, что команда следит за количеством и частотой возникновения и устранения проблем, покрытием кода тестами или сбором статистики и метриками качества кода. Однако использование CI значительно упрощает внедрение такого рода контроля в будущем.
Инверсия структуры затрат в ИТ
В большинстве отраслей, связанных с инженерными работами, стоимость проектирования низка, а воплощения или строительства напротив — очень высока. В ИТ же структура затрат инвертирована — именно проектирование является самой дорогостоящей стадией. На этот счет есть несколько альтернативных мнений. Одни говорят, что в ИТ вообще нет этапа воплощения (производства), другие утверждают, что в отличие от «строительства домов» производство программных продуктов состоит из бесконечного повторения коротких фаз проектирование-воплощение. Подобные дебаты сходятся в одном — затраты на инжиниринг составляют очень весомую часть всей структуры затрат. Немудрено, что многочисленные попытки внедрения классических методов мотивации инженеров и управления производством заканчиваются провалом.
Командам по разработке программного обеспечения жизненно необходимо узнавать о всех возможных технических проблемах как можно раньше. Ведь чем раньше проблема обнаружена — тем дешевле обойдется ее исправление. Утверждение кажется очевидным и применимым везде, не только в ИТ, но это только на первый взгляд. Книги и справочники, к примеру, содержат список исправлений на отдельных страницах в конце, практически любая дефектная деталь автомобиля может быть заменена на исправную и после начала эксплуатации. В примере с книгой стоимость внесения исправлений после выпуска продукции оказывается даже ниже — всего-то допечатать несколько страниц вместо замены всего тиража.
Несмотря на то, что внедрение непрерывной интеграции является разовой активностью и не отличается сложностью либо особым финансированием, многие компании отказываются от CI в попытках сэкономить. Такое неразумное поведение оборачивается весьма значительными (хотя и с трудом поддающимися точной оценке) временными и финансовыми потерями впоследствии. Время, инвестированное во внедрение непрерывной интеграции, окупается сторицей благодаря значительному уменьшению цикла обратной связи (feedback loop).
Клиенты ИТ-компаний желают видеть работающие приложения и системы как можно раньше. С другой стороны, разработчикам не всегда удается хоть сколько-нибудь точно оценить время, к которому новая часть системы будет пригодна для использования. Непрерывная интеграция — одна из немногих методик, реально помогающих (и даже подталкивающих) всегда иметь работающую версию продукта, готового к демонстрации.
Большинство методик предполагают итерации разработки длиной в несколько недель или даже месяцев. Такая величина цикла обратной связи может быть приемлема для менеджеров и заказчиков, но никак не для разработчиков. CI естественным образом подталкивает к сокращению итераций: команда может выпускать рабочую сборку ежедневно, а отклик непосредственно по коду получать при каждом внесении изменений. Все это позволяет уменьшить один из самых важных на сегодняшний день KPI — показатель time to market, не пренебрегая качеством продукта.
Прозрачность для всех
Совсем недавно мне посчастливилось побывать в Грузии. Как и в любом путешествии, глаз неизбежно цепляется за разного рода «аномалии». Одной из них стали полицейские участки. Они повсеместно прозрачны. Оказывается, не так давно правительство взяло курс на повышение уровня прозрачности работы государственных органов (не только правопорядка) для населения. И это указание было воспринято буквально. Нет, это отнюдь не повод для насмешек, напротив — такие меры позволили не только повысить уровень доверия со стороны населения к органам охраны правопорядка, но и изменить методы работы самой полиции к лучшему.
Клиенты ИТ-компаний все чаще обладают технической компетенцией, ищут возможности быть глубже вовлеченными в процесс разработки. Непрерывная интеграция позволяет им получать детальные отчеты о том, как себя «чувствует» продукт без отвлечения команды разработки или менеджеров. Прозрачность и автоматизация всего процесса дают заказчику чувство уверенности в том, что команда занимается наиболее важной задачей и делает это качественно.
Применение CI также дает больше информации для менеджеров. Они имеют постоянный доступ к важным данным: какая ревизия кода уже доступна для команды тестирования; насколько хорошо покрыт функциональными тестами тот или иной модуль системы; кто из разработчиков оказывает наибольшее влияние на метрики качества.
Удобство для разработчиков
Команда разработки — самый важный бенефициар от внедрения непрерывной интеграции. Прежде всего CI — это средство автоматизации. Создание сборок, прогон автоматических тестов, сбор статистики — рутинные задачи, которые непременно стоит автоматизировать. Не зря у компании IBM такой девиз: человек должен думать, а машина — работать.
CI увеличивает степень уверенности. Какое бы изменение разработчик не внес, он(а) всегда знает: его тщательно проверят, прогонят все тесты и эвристики, покажут, не повлияло ли изменение на другие части системы.
Сервер непрерывной интеграции можно использовать и для слежения за стандартами кодирования (форматирование, статический анализ). Даже самый внимательный code review не исключает попадания плохо отформатированного кода в репозиторий.
Конечно, наличие CI само по себе не дает всех описанных преимуществ. Для того чтобы все заработало, исходный код должен быть тестируемым, процедуры CI должны быть хорошо настроены, генерируемые отчеты — иметь удобный для машинного и человеческого восприятия вид.
Заключение
Время, потраченное на конфигурацию и тонкую настройку сервера непрерывной интеграции — это выгодная инвестиция. CI экономит время и денежные средства уменьшая feedback loop, значительно сокращая риски задержек, повышая уровень прозрачности. Позволяет предметно обсуждать возникающие проблемы, имея всю необходимую информацию под рукой. Служит средством автоматической сборки и выпуска готового продукта.
Наличие рабочей версии в любой момент времени позволяет делать релизы чаще и собирать больше отзывов от конечных пользователей, использовать эту информацию для улучшения продукта раньше конкурентов.
В мире ИТ, где компании постоянно соревнуются в скорости выпуска новых версий и сокращении затрат на производство для повышения конкурентоспособности, непрерывная интеграция, проверенная временем, это реально рабочая методика. Выгоду от нее получают не только разработчики, но и управленцы, и заказчики.
Автор статьи — заместитель технического директора по разработке корпоративных систем компании Itransition.