Паттерны и анти-паттерны CI/CD. Часть 1

Автор оригинала: http://www.alwaysagileconsulting.com/articles/pipeline-antipattern-artifact-promotion/
  • Перевод
Всем привет! Друзья, в последний день зимы у нас запустится новый поток по курсу «DevOps практики и инструменты». В преддверии старта курса делимся с вами первой частью статьи: «Паттерны и анти-паттерны CI/CD».



Задача пайплайна развертывания состоит из трех частей:

  • Видимость: Все аспекты системы поставки — создание, развертывание, тестирование и выпуск — видны членам команды и способствуют совместной работе.
  • Обратная Связь: Члены команды узнают о проблемах, как только они происходят, дабы устранить их как можно скорее.
  • Непрерывное Развертывание: С помощью полностью автоматизированного процесса вы можете развертывать и выпускать любую версию программного обеспечения в любом окружении.



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

1.1 Управление конфигурацией — паттерны и анти-паттерны

1.1.1 Настраиваемое Стороннее Программное Обеспечение

  • Паттерн: Оценить и использовать стороннее программное обеспечение, которое можно легко настраивать, развертывать и автоматизировать.
  • Анти-паттерн: Программное обеспечение, которое невозможно настроить извне. ПО без API и интерфейса командной строки, требующее от команды использования GUI.

1.1.2 Каталог Конфигурации

  • Паттерн: Поддержка каталога всех параметров каждого приложения, способов изменения этих параметров и места хранения каждого приложения. Автоматическое создание каталога, как часть процесса сборки.
  • Анти-паттерны: Параметры конфигурации не задокументированы. Каталог всех приложений и прочих ассетов — местный неописанный “фольклор”.

1.1.3 Mainline

  • Паттерн: Минимизация слияний, контроль количества активных codeline с помощью работы в mainline.
  • Анти-паттерны: Несколько веток на проект.

1.1.4 Ежедневные Мерджи

  • Паттерн: Изменения, закоммиченные в mainline, применяются на все ветки, как минимум, каждый день.
  • Анти-паттерны: Слияние всех итераций раз в неделю или реже раза в день.

1.1.5 Защищенная Конфигурация

  • Паттерн: Хранение информации о конфигурации в защищенном, доступном удаленно месте, например, в базе данных, директории или реестре.
  • Анти-паттерны: Открытые текстовые пароли и/или один компьютер или общий ресурс.

1.1.6 Репозиторий

  • Паттерн: Все исходные файлы — исполняемый код, конфигурация, среда хоста, данные — загружаются в репозиторий с контролем версии.
  • Анти-паттерн: Некоторые файлы зачекинены, другие, например, конфигурации среды или изменения данных — нет. Бинарные файлы, которые могут быть воссозданы в процессе сборки или развертывания, зачекинены.

1.1.7 Короткоживущие Ветки

  • Паттерн: Ветки должны быть короткоживущими, в идеале, несколько дней и не более одной итерации.
  • Анти-паттерны: Ветки, живущие больше итерации. Ветки для функционала продукта, живущие после релиза.

1.1.8 Окружение Единой Команды

  • Паттерн: Делать чек-аут репозитория проекта с контролем версий и запускать единую команду для сборки и развертывания приложения на любую доступную среду, включая локальную разработку.
  • Анти-паттерн: Требовать от разработчика определения и настройки переменных окружения. Заставлять разработчика устанавливать множество инструментов для сборки/развертывания.

1.1.9 Единый Путь до Эксплуатации

  • Паттерн: Управление конфигурацией целой системы — исходники, настройка, окружение, данные. Любые изменения можно отследить до конкретной ревизии в системе контроля версий.
  • Анти-паттерны: Части системы не имеют версии. Невозможно откатиться до предыдущей системной настройки ПО.

1.2 CI Непрерывная Интеграция — паттерны и анти-паттерны

1.2.1 Порог Сборки

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

1.2.2 Частые Коммиты

  • Паттерн: Каждый член команды регулярно чекинится — минимум, раз в день, но в идеале после каждой задачи, чтобы активировать систему CI.
  • Анти-паттерны: Коммит исходных файлов происходит реже, чем раз в день день из-за количества изменений, внесенных разработчиком.

1.2.3 Непрерывная Обратная Связь

  • Паттерн: Отправка автоматической обратной связи от системы CI всем членам межфункциональной команды.
  • Анти-паттерны: Уведомления не отправляются; уведомления игнорируются; система CI рассылает всем информацию, которой нельзя воспользоваться.

1.2.4 Непрерывная Интеграция

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

1.2.5 Принцип “Stop Line”

  • Паттерн: Чинить все баги поставки программного обеспечения, как только они возникают; “остановить линию”. Никто не чекинится в поломанной сборке, так как ее починка имеет наивысший приоритет.
  • Анти-паттерн: Сборки долго остаются поломанными, тем самым не дают разработчикам проверять работающий код.

1.2.6 Независимая Сборка

  • Паттерн: Написаны скрипты для сборки, которые отделены от IDE. Эти скрипты выполняются системой CI, чтобы сборка совершалась при каждом изменении.
  • Анти-паттерны: Автоматические сборки зависят от настройки IDE. Невозможно запустить сборку из командной строки.

1.2.7 Видимые Дашборды

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

Конец первой части.

Вот такой получился материал. Продолжение перевода можно прочитать здесь, а сейчас ждем ваши комментарии и приглашаем на открытый вебинар, который пройдет уже сегодня вечером.
  • +13
  • 8,3k
  • 2
OTUS. Онлайн-образование
524,00
Авторские онлайн‑курсы для профессионалов
Поделиться публикацией

Комментарии 2

    +1
    Спасибо большое за ваш пост!
      +1
      Слишком много странностей противоречивых пунктов.
      Если по 1.1.3 несколько веток на проект это антипаттерн, почему в 1.1.4 говорится про необходимость ежедневного слияния тех самых веток? Их же не должно быть. И в 1.1.7 вдруг ветки одобрены.
      1.2.1: с чего это вдруг ручное ревью это антипаттерн? Никакая автоматическая проверка не заменит того, что в коде должно делаться то, что по его спецификации, а не по тестам, и не сможет выловить все детали стиля.
      1.2.2: «чекиниться» «минимум раз в день, но после каждой задачи» это что за вредные советы по Остёру? Как раз несколько задач в одном коммите это и есть антипаттерн. В идеале и одна задача должна быть разделена на элементарные действия, каждое из которых понятно и воспроизводимо.
      1.2.4: вообще-то на каждый коммит это перебор (лучше — на цепочку, если система позволяет и цепочка потом не рвётся). Но нельзя говорить, что периодические сборки это плохо — хотя бы потому, что бывают неустойчивые тесты, и их надо ловить и обезвреживать.

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

      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

      Самое читаемое