Сегодня мы наблюдаем, как во всем мире постепенно отмирает waterfall-модель разработки. Ее не любят за тяжеловесность и плохую реакцию на изменения. Это напрямую влияет на актуальность продукта и увеличивает ТТМ (time-to-market), выливаясь в дополнительные затраты. Разработчики перестраиваются на рельсы agile, и мы здесь не исключение.
Методология agile изначально создавалась для маленьких команд, которые делают продукт под ключ в режиме end-to-end и сами отвечают за его качество. Но как быть, если разрабатываешь высококритичные банковские системы, над которыми трудятся десятки agile-команд? Как достичь той уверенности в продукте, которую дает долгое, исчерпывающее тестирование как в waterfall? В этом посте мы поделимся своим решением этого вопроса.
Все решают проблему по-разному, но обычно все сводится к автоматизации тестирования. Разрабатываются тесты на заглушках, общие правила формирования бэклогов соседних команд — фреймворки для межкомандного взаимодействия типа SAFe. В итоге благодаря синхронизации бэклогов команды смежных продуктов могут вместе писать и проводить тесты, в том числе интеграционные. Такие фреймворки есть и у нас.
Но теперь поставим себя на место владельца сложной и высококритичной банковской системы. Кто все-таки ответственен за качество всего этого продукта, если им занимается сразу десяток по-своему ответственных agile-команд? Нужна уверенность, что в продакшене ничего не завалится. Вводить дополнительные тестирования? Привет, waterfall, и пока, TTM.
Идеального решения здесь нет. В этой ситуации мы всегда будет иметь конфликт между принципами методологии и гарантированной надежностью результата. Вот какой компромисс нашли мы.
Quality Gates
Если специфика вашего продукта предполагает, что он не полностью изолирован от других, то в точках соприкосновения вы должны играть по одним правилам — соблюдать минимальный уровень качества. Код должен покрываться модульными тестами, не должен содержать критичных дефектов ИБ, дистрибутивы по мере поставки должны проходить смоук-тесты. Никакой жести, но требования обязательны для всех. Их выполнение — это пропуск к общему тестированию.
Так, в общем, и выглядит практика Quality Gates — набор автоматизированных проверок, встроенных в devops-пайплайн каждой системы. По сути она отражает тенденцию к шифт-лефт тестированию, о которой сейчас частенько говорят в рамках девопса.
Мы договорились со всеми командами о ряде проверок, quality gates, которые они должны проходить в ходе прохождения этапов жизненного цикла.
Кодинг
Перед сборкой кода нужен обязательный статический анализ, проверка кода на соответствие стандартам конкретного языка программирования. А также на полноту покрытия модульными тестами. Для этого существуют разные инструменты. Мы, например, любим SonarQube. Пройдя этот quality gate, команды могут быть уверены, что не нарушили ряд базовых правил еще на раннем этапе. Например, избежали значительного дублирования, которое увеличивает сложность кода и вероятность проблем.
Вторая проверка перед сборкой — это проверка ИБ. Есть общепринятые практики по выявлению проблем ИБ в коде и инструменты, которые могут просканировать код и выявить опасные места. Например, некорректно объявленная переменная может привести к проблемам в продакшене. Здесь мы договорились не допускать все, что можно выявить на этапе написания кода, до пентестов и более сложных проверок.
Сборка дистрибутива
При сборке дистрибутива мы обязательно проверяем результат: что сборка прошла корректно, что все службы запустились и работают как надо, что дистрибутив можно установить на нужную среду, и он заработает. Такой buiild verification test исключает потенциальное непонимание между тестировщиком и разработчиком. В waterfall-практике, бывало, разработчик заканчивал работу, передавал дистрибутив тестерам, а при установке на стенд выяснялось, что сборка даже не запускается. Тогда весь цикл нарушался, разработка растягивалась и вообще ничего хорошего не происходило.
У нас интеграционное взаимодействие выстроено очень непросто. Важно не сломать стенд, на котором могут проверяться и другие команды. Мы можем сделать это из-за плохого дистрибутива, и соседи по стенду узнают об этом раньше нас — мы просто нарушим им весь процесс работы. Кроме того, так можно испортить тестовые данные. А их подготовка тоже стоит денег и занимает немалое время. Особенно когда речь идет об обезличенных данных пользователей.
Смоук-тесты
По мере установки дистрибутива на каждый стенд тестирования он проходит ряд простых смоук-тестов. На стенде системного тестирования тестируется функциональность дистрибутива. Дальше дистрибутив ставится на стенд интеграционного тестирования, где тестируются интеграционные взаимодействия. На нем тоже выполняется набор смоук-тестов. Если дистрибутив их не проходит, он не может перейти на следующий этап.
С помощью этих quality gates мы получаем первичное представление о качестве дистрибутива. Если смоук-тесты прошли успешно, команда приступает к тестированию. Если дистрибутив не прошел смоук-тесты на этом этапе, он, скорее всего, не пройдет и мануальное тестирование. Здесь мы назначаем его только в том случае, когда сборка потенциально готова пойти в пром.
Quality gates как фреймворк
Мы стремимся к тому, чтобы quality gates стали полноценным фреймворком для управления качеством разработки большого количества продуктов в agile. Если какая-то команда постоянно не проходит даже обязательные quality gates — это сигнал о наличии проблем, которые нужно обсудить и решить. С другой стороны, если какая-то команда уже освоилась с базовыми quality gates и встроила их во внутренние процедуры, она может пойти дальше и включить дополнительные quality gates.
В будущем мы планируем выкатывать новые наборы обязательных quality gates. А также необязательных, чтобы каждая команда с достаточным уровнем зрелости могла выбрать, что ей нужно. Например, если стоит прорабатывать стабильность дистрибутива на интеграционных полигонах, команда возьмет одни quality gates. Если нужно следить, чтобы сложная и многокомпонентная сборка не затрудняла деплой — возьмет другие. У кого-то уклон в безопасность на фронте, у кого-то в сторону проверок нагрузочного тестирования, доступности стендов, отклика, у кого-то впереди интеграция или проверка на какие-то данные. Каждая команда сможет найти quality gates для своего случая.
Важно отметить, что quality gates — это не замена тестирования, а инструмент первичного контроля. Тестирование никто не отменяет. Главная задача здесь — как можно раньше минимизировать ущерб другим командам от низкого качества продукта.
Пример стороннего пайплайна, включающего quality gates
Итоги внедрения quality gates
В первую очередь, мы увеличили стабильность производственного цикла. Шифт-лефт в действии, мы можем сразу обнаруживать критичные баги функциональности. Меньше времени уходит на различные итерации тестирования, раньше обнаруживаются дефекты, так что их устранение обходится дешевле.
Уменьшился лид-тайм — время от начала кодинга фичи до ее внедрения в продакшн. Стабильность инженерного этапа ТТМ повысилась за счет того, что мы уменьшили простои в процессе поставки дистрибутива в промышленную среду. Чистое время на тестирование мы тратим такое же, но при этом у нас нет простоев из-за того, что развалился стенд, что нужно ждать пересборки дистрибутива.
Выросло время доступности сред для тестирования. Раньше ты мог поставить на нее сборку и забыть о ней на неделю. А тем временем смежные команды не могли протестироваться в этой среде, потому что твоя сборка дефективна и ты узнаешь об этом только через неделю. Теперь, когда ты ставишь сборку на полигон, то сам тестируешь ее на самые распространенные проблемы, при необходимости откатываешься, допиливаешь, возвращаешь обратно. И шанс никому не помешать становится гораздо выше. Внедрение quality gates также приведет к сокращению костов на восстановление стендов и переподготовку данных для тестирования.
Ваше мнение?
Как мы говорили в начале, противоречие между принципами agile и комплексной разработкой нельзя разрубить как гордиев узел. Можно лишь стремиться к тому, чтобы оно приносило как можно меньше проблем. В нашем случае помогает практика quality gates, но, конечно, мы не считаем ее идеальной. А как решаете эту проблему вы? Нам было бы очень интересно обсудить этот вопрос.
Николай Воробьев-Сарматов, Сбербанк-Технологии, Sberworks
Спасибо Михаилу Бижану за помощь в подготовке статьи!
Автор: Sberbank
