Настоящий CTO: думай как технический директор - Алан Уильямсон

Он запускается автоматически, когда кто-то делает коммит в определенную ветку в репозитории, обычно это develop, после проверки и мержа пулреквеста (pull request merge). Это запускает следующую последовательность действий, или шлюзов (gates), через которые проходит процесс деплоя и каждый из которых должен завершиться успешно:

• Фиксация (или коммит, от англ. commit). Событие, запускающее пайплайн, обычно это успешный коммит/слияние кода с заданной веткой.

• Анализ кода. Исходный код в ветке проходит серию проверок с использованием таких инструментов, как SonarQube.

• Компиляция/сборка. Затем код компилируется (если нужно) и создается артефакт, готовый к деплою.

• Модульные тесты. После сборки код проходит модульные тесты, проверяющие, что в кодовой базе не появилось ошибок.

• Тесты безопасности. Любые тесты или проверки для обеспечения безопасности.

• Развертывание (деплой). Наконец, код деплоится на серверы, например на серверы для разработки или для тестирования. В зависимости от ветки это может быть и деплой на продакшен.

Разумеется, вы можете добавить в пайплайн столько этапов, сколько необходимо для вашего проекта. Это мощный инструмент автоматизации, который гарантирует, что ни один шаг не будет пропущен и что каждый компонент или библиотека могут быть собраны не только на настольном компьютере разработчика. Таким образом, вам не придется выслушивать классические оправдания: «Ну, на моем компьютере все работает».

Настроить пайплайн CI/CD уже не так сложно, как раньше. Такие инструменты, как GitHub, Bitbucket и CodeCommit, в той или иной форме поддерживают пайплайны, а если вам требуется решать более сложные задачи, вы можете внедрить инструмент оркестрации, например популярный продукт с открытым исходным кодом Jenkins, позволяющий управлять всеми пайплайнами для многих репозиториев и сервисов.

По мере того как проект будет развиваться и вы будете привыкать к использованию пайплайнов, вы будете стараться встраивать больше проверок. Если для вас это в новинку, не мудрите и не переусердствуйте – простая схема коммит > сборка > деплой отлично работает во множестве проектов.

Если что-то пойдет не так и выполнение одного из этапов завершится ошибкой, вы будете точно знать, кто автор проблемы, благодаря истории изменений в системе контроля версий. Но используйте это не для того, чтобы обвинять кого-то, а для того, чтобы создать открытую среду, в которой не будет избранных, чьи действия не обсуждаются, и все работают сообща, чтобы обеспечить самое высокое качество вашего ПО.

Надежный пайплайн CI/CD поддержит быстрый рост вашего отдела и обеспечит уверенность в том, что все сотрудники будут действовать правильным и стандартным способом. Вот типовые проблемы, которые могут приводить к ошибкам сборки:

• Ошибка компиляции.

• Отсутствие библиотеки, от которой зависит проект.

• Нарушение требований/стандартов.

• Ошибки при прохождении тестов.

• Не выполнены требования безопасности (в коде обнаружены пароли или ключи доступа).

• Несоответствие структуры базы данных.

Чем больше у вас тестов, пусть и мелких, тем больше уверенность в качестве релиза и тем меньше риск. Надежный набор автоматических проверок способствует продвижению философии «выпускайте понемногу и часто». Вам решать, насколько часто вы хотите делать релизы, но какой смысл задерживать выкладывание исправлений, особенно если ваша инфраструктура позволяет делать релизы без прерывания сервиса (например, вы используете бессерверную среду)?

Некоторые команды делают несколько релизов в неделю, некоторые – один в день, а некоторые – много раз в день (одна крупная компания из списка Fortune 100 выпускает тысячи релизов в день в разных частях своей инфраструктуры). При правильной настройке пайплайнов никаких ограничений здесь нет, особенно если вы используете облачные сервисы, в которых все, что нужно для сборки проекта, запускается по вашему запросу.

9.6. Технический долг

Представьте себе автомобиль, который никто не обслуживает (не меняет масло, фильтры и шины). Конечно, в краткосрочной перспективе это экономит немного денег, но каждое пропущенное ТО увеличивает «долг» владельца перед автомобилем. В какой-то момент этот долг может превысить стоимость самого автомобиля, а затем в один прекрасный день посреди дороги у него заклинит двигатель или же лопнет колесо, последствия чего обойдутся еще дороже. Таким образом, дешевле исправлять мелочи, чтобы избежать крупных, неожиданных аварий или затрат.

То же самое происходит и в информационной системе предприятия, только вместо автомобиля здесь исходный код и отдельные компоненты. Каждый раз, когда для какой-либо проблемы используется обходное решение (прямо в коде указывается фиксированное значение, не выполняется проверка параметров функции, игнорируется необходимость обновления или применения патча безопасности), вы увеличиваете технический долг.

Технический долг возникает естественным образом, если ваша система развивается быстро. Это нормально – и способствует более быстрому выполнению задач. Однако к такому долгу необходимо относиться так же, как к кредитной карте: деньги с нее тратить можно, но в конце месяца обязательно погасите задолженность.

Сколько времени стоит тратить на устранение технического долга? Это во многом зависит от вашей компании, но, как правило, от 10 до 30 % рабочего времени вашей команды посвящается избавлению от долгов.

Измерить количество проблем в исходном коде можно довольно просто с помощью инструментов контроля качества, включенных в ваш пайплайн (SonarQube, опять же, хороший пример). Если вы замечаете проблемы во время ревью кода, а также во время релизов и обновлений, помечайте их и добавляйте в бэклог. Например, инструмент анализа мог не указать на какой-то фрагмент кода, потому что синтаксических проблем в нем нет, но вы знаете, что это было временное исправление, которое необходимо обязательно переделать, чтобы оно соответствовало общим требованиям.

Хороший CTO всегда знает уровень технического долга в своем проекте. Полезный совет, особенно если вы используете спринты, – через каждые 2–3 спринта выделяйте некоторое время для работ по устранению технического долга.

9.7. Релиз

Без результатов ваша работа не имеет никакого значения. Выпуск релизов вашего продукта или обновление всей активно используемой корпоративной платформы может стать безболезненным и будничным делом, но, если вы хотите, чтобы это не требовало усилий, – вам придется как следует поработать.

Прежде обновление программного обеспечения было целым отдельным проектом – для него планировался технологический перерыв, обычно в нерабочие часы, направлялись уведомления клиентам, готовился порядок действий, которые затем выполнялись в надежде, что все пройдет по плану, потому что об откате изменений не хотелось даже думать. Сравните с современной архитектурой, в которой обновления при необходимости выполняются несколько раз в день без прерывания сервиса.

В этом разделе мы рассмотрим составляющие грамотной стратегии выпуска релизов, а также что необходимо подготовить и какие коммуникации наладить для ее успешного выполнения. «Выпускай понемногу и часто» – это не просто красивые слова, это достижимая цель.

9.7.1. Релиз с прерыванием сервиса

Первый тип релизов выполняется с простоем: для него необходимо отключить систему. Это может быть связано с необходимостью перезапуска каких-то компонентов либо с необходимостью выполнить миграцию данных для перехода к новой версии. Такие релизы требуют больше усилий и предварительного планирования. Процедура их проведения может включать следующее:

• Определите, что нужно вывести в офлайн: серверы, компоненты.

• Что будут видеть конечные клиенты: нужно ли создавать специальную страницу с информацией о работах?

• Рассчитайте следующие сроки:

• время на выключение сервиса;

• время на резервное копирование;

• время на обновление программного и аппаратного обеспечения;

• время на проверку, что все работает;

• время на приведение системы в доступное для пользователей состояние.

• Для каждого из этих этапов распишите точный порядок действий.

• Для каждого этапа назначьте ресурсы и определите процесс перехода к следующему этапу.

• Определите совместно с бизнесом наиболее удобное время проведения релиза, желательно в период наименьшего использования системы.

• Составьте список тех, кому необходимо предоставлять отчеты о ходе работы, и тех, кого необходимо уведомить о завершении релиза.

Теперь у вас есть план выполнения релиза. Предусмотрите запас времени на случай возникновения проблем. Например, если выключение сервиса на все выходные не является проблемой для бизнеса и при этом вы ожидаете, что вам понадобится всего 2–4 часа, все равно планируйте выключение на все выходные. Если вы справитесь раньше –