Подписаться
Читать в телеграм
Когда компании пора переходить к Continuous Integration?
Как автотесты оптимизируют разработку?
Как убедить команду в целесообразности перехода на CI и кто должен возглавить этот процесс?
Почему менеджеры переводят команды на CI
Когда Time-to-Market становится ключевым принципом выпуска ПО, работать по «водопаду» уже не получается. Сроки вывода нового продукта на рынок сокращаются, поэтому приходится пересматривать устоявшиеся процессы разработки.
Классические недостатки водопадной модели, с которыми мне приходилось постоянно сталкиваться:
- Качество ПО обратно пропорционально количеству участников команды. Иными словами, чем больше команда, тем сложнее эффективно организовать ее работу и обеспечить требуемое качество создаваемого ПО. В «водопадной» модели мы регулярно сталкиваемся с эффектом поздней обратной связи. Несмотря на то что составляется план с четкими сроками разработки, тестирования, приемки со стороны заказчика, по факту получается примерно так: сроки разработки заканчиваются — и уже на стендах тестирования команда понимает, что реально ничего не работает. А если и работает, то не так, как это представлял себе заказчик.
- За этой проблемой тянется следующая: не выдерживаются сроки тестирования. Блокеры и критичные ошибки выявляются не сразу, тестирование может затягиваться. И хотя формально этап разработки закончился, программисты продолжают писать код, исправляя дефекты.
- Затем продукт показывают заказчику, который тоже находит с десяток дефектов. Если это сложные доработки, мы уходим на повторный круг. Либо идет задержка сроков, либо ПО выходит в продуктив с усеченным функционалом.
Главный звонок, что пора переходить на непрерывную интеграцию: сроки тестирования значительно превышают сроки разработки. Основной плюс при использовании CI: мы можем получать обратную связь по качеству создаваемого кода максимально быстро. Для тестирования функционала не нужно ждать окончания этапа разработки. Написали кусок кода — и сразу отправляем его на проверку. При таком подходе тестировщики и разработчики не тормозят друг друга. Одни проверяют готовые части ПО, другие пишут новый код. Так что слона не приходится есть целиком, мы делаем это частями.
CI — это плавный переход к Agile-практикам, в ходе которого члены команды учатся давать постоянную обратную связь друг другу. Обратная связь между элементами любой системы — это ключевое условие ее нормального функционирования. Попробуйте сделать что-нибудь с закрытыми глазами: сложность повышается, а результат может кардинально отличаться от задуманного. Поэтому нужно выстраивать прочные взаимосвязи между элементами системы. Это касается и цикла разработки ПО. Выполняя любой из его этапов, стремитесь как можно быстрее получить отклик от заказчика.
Непрерывная интеграция (Continuous Integration, CI) — набор практик и принципов разработки программного обеспечения, при котором команда проводит интеграцию ПО максимально часто. Каждая операция должна приводить к ряду автоматических проверок, позволяющих вылавливать проблемы на ранних этапах разработки. Впервые термин Continuous Integration использовал инженер Гради Буч в своей книге «Объектно-ориентированный анализ и проектирование» (1991 г.). Популярность методология обрела в середине 2000-х годов.
Важность автотестирования
Автотесты — это ключевой элемент, ради которого имеет смысл вносить изменения в релизный цикл.
На одном из проектов очень много проблем создавало большое число интеграций, необходимых для работы нашей системы. У нас было внушительное количество критичных компонентов. Неработоспособность какого-либо из них останавливала работу всего решения. При этом за каждый компонент отвечала отдельная команда. В результате единый интеграционный тест большую часть времени был блокирован: то в одном, то в другом модуле вылавливали блокер. На их устранение уходило от нескольких часов до суток. Время доступности полигона для тестирования составляло менее 10% от общего времени. Это напоминало оркестр с множеством ненастроенных инструментов. В результате был просто шум, без музыки. Нам пришлось внедрять фильтр: мы перестали пускать в оркестр ненастроенные инструменты. Этим фильтром как раз и стали автотесты. Компонент, который их не проходил, не допускался на интеграционный тестовый полигон. Также был создан дополнительный полигон «Барьер», куда в автоматическом режиме ставилась каждая сборка, прежде чем она попадала на стенд. На нем проходили автотесты, которые помечали ту или иную сборку как годную или негодную к установке на интеграционный полигон. Это повысило его доступность.
Автоматизированный процесс сборки — лишь одна из ступеней процесса разработки и тестирования продуктов. Безусловно, это базис, но без дальнейшего развития он не имеет особой ценности. Для выхода на новый уровень нам нужно построить всю лестницу. В итоге должен получиться CI-конвейер.
| Плюсы и минусы CI | |
|---|---|
| Минусы | Плюсы |
| Из минусов — необходимость дополнительных стендов тестирования. При этом компания сэкономит на ФОТе тестировщиков, работающих по неэффективной «водопадной» модели, что окупит затраты на дополнительную инфраструктуру. | Все минусы перекрывает один плюс — кардинальное ускорение Time-to-Market. Если компании необходимо сокращать сроки разработки и внедрения ПО, то переход на CI просто жизненно необходим. |
Из-за роста автоматизации увеличиваются сложность и хрупкость системы. Мы сталкивались с ситуациями, когда инфраструктура простаивала, потому что не справлялась с нагрузкой. Были ошибки, например, в автосборщиках. Но я бы назвал этот минус естественным недостатком подхода. | Еще одно преимущество CI: у компании высвобождаются ресурсы для исследовательского тестирования. Если все штатные проверки (например, на элементарные отклонения от бизнес-процесса) проходят в автоматическом режиме, то тестировщик проверяет уязвимости системы. Если же автотесты не внедрены, он занимается рутинными задачами и ищет проблемы, лежащие на поверхности, вместо того чтобы повышать качество продукта, отлаживать баги и проверять ПО на надежность. |
| Помимо приобретения железа, необходима его поддержка. Если речь идет о компании, работающей в разных часовых поясах, поддержка должна быть круглосуточной. |
|
| Наверняка при перестройке кто-то уйдет из команды. Это нормальный процесс. Если речь не идет о массовом исходе сотрудников, волноваться не о чем. Большая часть команды должна воспринять перемены с воодушевлением, ведь это новые возможности. CI сейчас становится базовым требованием при найме сотрудников. |
|
Как работать с командой
В сложившейся команде внедрять CI необходимо эволюционным путем, революции здесь неуместны. Как и с любой задачей, сначала стоит определиться, какой результат вы хотите получить, а затем — разделить весь процесс внедрения на шаги и установить для них сроки.
Команду нужно заинтересовать тем, что она получит от внедрения нового подхода. Первый этап внедрения CI всегда сопровождается повышенными трудозатратами, при этом его эффективность не сразу очевидна. Разработчикам и тестировщикам непонятно, зачем ломать привычную схему, если все и так работает. Поэтому очень важно постоянное общение с командой.
Не стоит внедрять CI прямо в процессе разработки. В этом случае вы гарантированно столкнетесь с противодействием команды: мы тут заняты, пишем код, а вы с какими-то автотестами к нам лезете. В этот момент перед вами встанет выбор: либо начинать разработку с нуля, либо доработать по «водопаду» и уж затем перестраивать процесс.
Очень важно, кто именно занимается внедрением CI. Я считаю, что это должны делать сами разработчики. Отлично, если это будет тим-лид, хотя, как правило, у него другие задачи и нет времени на продвижение нового подхода. Если так, ищите кого-нибудь из участников команды, кто загорится идеями CI.
Метод CI нужно встроить в работу команды. Когда непрерывная интеграция прорастает изнутри команды, ее воспринимают органичнее, соответственно, эффективность этого подхода значительно выше. Как правило, если код будут писать свои разработчики, а автотестами и DevOps-инструментами займется кто-то со стороны, КПД CI будет низким.
Следующий шаг — постепенное внедрение. Не стоит пытаться объять необъятное. Договоритесь с командой, что сначала вы покрываете автотестами 10% от реализуемого функционала. Процент условный, каждый может устанавливать собственную планку, ориентируясь на конкретный проект и команду. Затем эту планку нужно постепенно поднимать и сокращать сроки тестирования.
Человек инертен. Эксперта, который давно работает по определенной модели, сложно сместить на новую траекторию. Конечно, нужно убеждать в том, что CI будет только во благо. В то же время необходимы меры, которые помогут команде быстрее перейти на новые практики. В общем, классический метод «кнута и пряника».
Процесс внедрения CI можно считать завершенным, когда тестирование продукта занимает минимальное время. На одном из проектов мы сокращали тестирование с шести недель до одной. Конечно, в каждом случае показатели будут зависеть от специфики проекта.
