Прежде чем планировать дорожную карту CI/CD, сначала проведите инвентаризацию

Вы садитесь с командой планировать внедрение CI/CD. Кто-то предлагает начать с самого критичного приложения. Другой хочет исправить процесс развертывания, который причиняет больше всего боли. Третий настаивает на создании нового пайплайна с нуля. У каждого есть веские аргументы, но никто точно не знает, с чем команде предстоит работать.

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

Что нужно каталогизировать

Инвентаризация звучит как бюрократия, но это основа для каждого последующего решения. Без неё вы гадаете, какие изменения наиболее важны. С ней вы видите паттерны, пробелы и зависимости, которые иначе остались бы незаметными, пока не заблокируют ваш прогресс.

Приложения

Начните с каждого приложения, которым управляет ваша команда. Включите те, которые редко меняются, внутренние инструменты, о которых никто не говорит, и легаси-системы, которых все избегают. Для каждого приложения запишите:

  • Язык программирования и фреймворк
  • Где находится исходный код (репозиторий, стратегия ветвления)
  • Как работает процесс сборки сегодня (ручные команды, скрипты, существующая автоматизация)
  • Кто лучше всего знает приложение

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

Базы данных

Многие команды забывают, что базы данных — часть процесса доставки. Пайплайн CI/CD, который обрабатывает код приложения, но игнорирует изменения в БД, потерпит неудачу, как только миграция запустится в продакшене. Для каждой базы данных, связанной с вашими приложениями, отметьте:

  • Тип и версию СУБД
  • Как сейчас управляются изменения схемы (ручные скрипты, инструменты миграции, ничего)
  • Кто отвечает за изменения в БД и кто реагирует, когда миграции падают
  • Тестируются ли изменения БД перед попаданием в продакшен

Изменения в базах данных несут другие риски, чем изменения в коде приложения. Плохой деплой часто можно быстро откатить. Плохая миграция может повредить данные или потребовать часов на восстановление. Знание ландшафта ваших БД помогает решить, сколько автоматизации и тестирования применять.

Инфраструктура

Приложения и базы данных где-то работают. Запишите, где именно находится каждый компонент:

  • Физические серверы, виртуальные машины или облачные сервисы
  • Как создаются и настраиваются окружения
  • Документирована ли конфигурация или управляется через ручные SSH-сессии
  • У кого есть доступ к продакшен-окружениям
  • Кто обычно занимается проблемами инфраструктуры

Инфраструктура, управляемая вручную, ограничит уровень автоматизации, который вы можете внедрить. Если каждый сервер — уникальная снежинка со своей конфигурацией, ваш пайплайн не сможет надежно развертываться ни на одном из них. Инвентаризация покажет, какие части инфраструктуры готовы к автоматизации, а какие требуют предварительной очистки.

Существующие пайплайны

У вашей команды уже может быть какая-то автоматизация, даже если она неполная. Задокументируйте, что существует:

  • Для каких приложений есть автоматизированные процессы сборки, тестирования или развертывания
  • Что каждый пайплайн на самом деле делает (только сборка, сборка и тесты, полное развертывание)
  • Чего не хватает (нет сканирования безопасности, нет миграции БД, ручные шаги утверждения)
  • Насколько надежны существующие пайплайны (частые сбои, нестабильные тесты, долгое время выполнения)

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

Владение

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

Также отметьте, кто может принимать решения об изменениях. Человек, поддерживающий компонент, может не быть тем, кто утверждает изменения в нём. Знание цепочки принятия решений предотвращает задержки в будущем.

Как построить инвентаризацию

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

Следующая блок-схема описывает рекомендуемый процесс инвентаризации:

flowchart TD A[Начать инвентаризацию] --> B[Список приложений] B --> C[Список баз данных] C --> D[Список инфраструктуры] D --> E[Список существующих пайплайнов] E --> F[Назначить владельцев] F --> G[Обсудить с командой] G --> H[Выявить пробелы] H --> I[Проанализировать паттерны] I --> J[Спланировать дорожную карту]

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

Ожидайте найти пробелы. У некоторых приложений может не быть четкого владельца. В некоторых базах данных могут быть недокументированные процессы миграции. Некоторая инфраструктура может работать на учетных данных, которые никто не помнит. Эти пробелы — не неудачи. Это именно та информация, которая нужна для планирования следующих шагов.

Что выявляет инвентаризация

Как только инвентаризация завершена, проявляются паттерны. Вы можете увидеть, что у одной команды зрелый пайплайн, а другая всё ещё развертывает вручную. Вы можете обнаружить, что изменения в БД обрабатываются тщательно, а подготовка инфраструктуры хаотична. Вы можете выяснить, что ваше самое критичное приложение имеет наименьшую автоматизацию.

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

Инвентаризация также выявляет зависимости, которые нельзя игнорировать. Приложение, зависящее от базы данных без процесса миграции, невозможно полностью автоматизировать, пока не будет решена проблема на стороне БД. Приложение, работающее на вручную настроенной инфраструктуре, потребует изменений в инфраструктуре, прежде чем пайплайн сможет надежно развертываться.

Практический чек-лист

Используйте этот чек-лист для руководства вашей инвентаризацией:

  • Перечислите каждое приложение, которым управляет ваша команда, включая внутренние и легаси-системы
  • Для каждого приложения запишите язык, репозиторий, процесс сборки и основного контактного лица
  • Перечислите каждую базу данных, связанную с этими приложениями
  • Для каждой БД запишите тип, версию, процесс миграции и ответственное лицо
  • Задокументируйте, где работает каждое приложение и база данных (сервер, ВМ, облако)
  • Отметьте, как создаются и настраиваются окружения
  • Задокументируйте существующие пайплайны: что они делают, чего не хватает, насколько они надежны
  • Запишите владельцев для каждого компонента
  • Определите, кто может утверждать изменения для каждого компонента

Конкретный вывод

Инвентаризация — это не бюрократическое упражнение. Это самое полезное, что можно сделать перед планированием любых улучшений CI/CD. Команда, которая точно знает, что у неё есть, может принимать решения на основе фактов, а не догадок. Команда, которая пропускает инвентаризацию, будет продолжать обнаруживать сюрпризы в середине внедрения, и эти сюрпризы будут стоить времени, доверия и темпа.

Начните свою дорожную карту с того, что вы уже знаете. Паттерны в вашей инвентаризации подскажут, куда двигаться дальше.