Создание и внедрение программного обеспечения – сложное дело, и не верьте тем, кто утверждает обратное. Команды растут (и становятся более рассредоточенными), все больше рук одновременно работает с исходным кодом, люди приходят и уходят. Как при таком уровне сложности и текучки в команде организовать инфраструктуру таким образом, чтобы гарантировать, что каждый сотрудник при необходимости сможет собрать готовое приложение? Ответ – с помощью пайплайнов непрерывной интеграции и внедрения (CI/CD).

Заметки с полей

Только Фред может обновить эту службу

Если для компиляции, сборки и деплоя кода на продакшен вы используете только один конкретный компьютер (или одного человека), то вы попадаете в зависимость от них, что является проблемой. В подобную ситуацию попасть совсем несложно, и, поскольку все годами работает нормально, она не кажется чем-то серьезным и требующим немедленного решения. В портфельных компаниях, возглавляемых их основателями, я часто вижу, что за обновления отвечает один человек. Помню случай, когда ответственный сотрудник обновил библиотеки. NET на компьютере, после чего проект перестал компилироваться. Это вызвало общую панику, потому что теперь компания не могла обновить свой основной продукт. В качестве краткосрочного решения мы настроили для них виртуальную среду, что позволило сделать процесс сборки более управляемым и предсказуемым.

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

Философия CI/CD, как следует из названия, заключается в том, что как только код прошел ревью, одобрен и интегрирован в общую ветку, он автоматически проходит этапы компиляции и тестирования, а затем развертывается в указанном окружении. Об ошибке в любой части этого процесса немедленно уведомляются ответственные, с тем чтобы эти ошибки устранялись. Пример типичного пайплайна CI/CD показан ниже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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