Портал №1 по управлению цифровыми
и информационными технологиями

Две основные проблемы с CI/CD, конвейерами, GitOps и проч., и как с ними быть

Конвейер развёртывания (в народе именуемый CI/CD) — основной и необходимый компонент DevOps, даже если под DevOps понимаются сугубо технические практики. Понятно, что без конвейера никуда, никакого DevOps не будет.

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

Такую команду на её пути подстерегают две большие проблемы.

Проблемы

Первая: даже в самых простых и тривиальных случаях (веб-приложение, виртуальная инфраструктура, современные языки, библиотеки и фреймворки) построить конвейер бывает не так просто. Дело в том, что конвейер предъявляет довольно строгие требования к другим областям, например, к работе с исходным кодом приложения. Очень сложно получить даже подобие CI/CD, если с git мы работаем кое-как, позволяем себе создавать десятки долгоживущих веток кода на каждый чих, имеем постоянный проблемы с merge, завязанные на одного очень умного парня, который не только давно работает с этой ИТ-системой, но и постоянно занят/перегружен. Равно как конвейер требует культуры создания и постоянного обновления автотестов, и если в вашей команде до сих пор идут дебаты «стоит ли, рационально ли, нужно ли, можем мы себе позволить ли писать автотесты», то с построением конвейера будут сложности. Ещё одна область — релизы. Если мы приучили заказчиков к релизам раз в месяц/раз в квартал/раз в как получится, то отучить заказчиков и себя — отдельный труд. Разумеется, работой с исходным кодом, автотестами и релизами требования не исчерпываются, это лишь примеры.

Вторая проблема — деградация. Я регулярно с ней встречаюсь в реальной жизни: вот вроде бы проделана большая работа, освоены современные технические практики, закуплен и «внедрён» инструментарий, выполнено первичное покрытие автотестами... И, довольно внезапно, выясняется, что команда (подчёркиваю — команда, а не какой-то один человек) приняла решение временно отключить часть автотестов, потому что они стали «красными», а разбираться с ними сейчас ну никак нельзя, потому что «обещания, сроки, дедлайны и вообще — потом разберёмся». Опять же, это лишь пример. Второй пример — freeze period, когда изменения по какой-то бизнес-причине проводить нельзя, а потому конвейер временно останавливается. Вся накопленная предыдущая практика работы идёт коту под хвост, потому что перезапуск конвейера — «ну это чуть позже, когда-нибудь, и вообще — потом»...

Со стороны может показаться, что проблемы слишком очевидны. И потому очень легко их обойти, что-то предусмотреть, договориться не делать плохо и затем не делать. Однако вспомним, что работают-то люди. Во-первых, команда, а не один человек. Отсюда — коллективное бессознательное, а также общая и взаимная (без)ответственность. Во-вторых, в команде есть авторитеты, а не самоорганизация. Они решают, они как бы отвечают за принятые решения. В-третьих, мнение людей зависит не только от настроения, но и от погоды. То есть — переменчиво даже в течение одного дня. В-четвёртых (снова) — обещания, обязательства, крайние сроки и SLA, которые давят. При этом мы сами их давали (обещания) и брали (обязательства).

Что же тогда делать с этими двумя проблемами? Как быть?

Решения

1.

С первой проблемой можно поступить следующим образом: составьте карту технических практик, необходимых для построения и работы полноценного конвейера развёртывания (для взрослых команд) или хотя бы чек-лист (для команд попроще). Осознайте и обсудите, что требует изменения. Оцените сегодняшний уровень и размер «разрыва» (как говорят консультанты) или «шага» (как говорят нормальные люди). Планомерно, ритмично и в рамках вашего «налога в 20%» реализуйте максимальное количество требований. Польза здесь кроется не только в реализации, это само собой. Существенная часть пользы заключается в том, что команда сама проходит этот путь, пусть и с временной сторонней помощью. Команда осваивает новые практики. Команда отказывается от прошлых практик. Команда сама себе объясняет — что она теперь делает иначе и почему.

Второй совет для первой проблемы, из практики — договоритесь о желаемых параметрах вашего конвейера заранее. Например, конвейер должен доносить изменение до продуктивной среды не дольше, чем за 15 минут. Такой ориентир поможет всем в будущем чётко определить — работает ли CI/CD, или нет. Полутона здесь ни к чему: «как бы работает, но не очень», или «да, есть, но медленный», или «вот вчера ещё был, сегодня нет, но завтра — мы верим! — появится снова».

2.

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

Второй совет для второй проблемы, снова из практики — постарайтесь не останавливаться на половине дороги. Continuous Integration — скучно, не интересно и не современно, Continuous Delivery — не сильно лучше, так софт разрабатывали десять лет назад. Поверьте, вам нужен только Continuous Deployment. А значит — нет больше «волшебного рубильника», когда кто-то умный, опытный, начальственный или ещё какой принимает решение — да, в бой! Всё сразу летит в бой, без вариантов. Поэтому, к примеру, халтурить с автотестами сегодня — это гарантированно получить проблемы завтра. Поэтому — не стоит даже думать.

Примечания

Важная оговорка: всё написанное выше относится к ситуации, когда у вас есть боевая среда с живыми пользователями. Если вы пишете софт, который пойдёт «в релиз», «в первую версию», «в MVP» когда-нибудь потом через полгода-год, то ваша жизнь не затрагивается всеми этими сложностями. Не в конвейере основная проблема.

Далее, не могу не отметить, что подобные вопросы мы обсуждаем на учебном курсе «DevOps». В группе на ближайшие даты 25-27 января есть ещё свободные места, милости просим. Также есть возможность поговорить про нашу консалтинговую услугу «Построение работы продуктовых команд».

И ещё забавный (и полностью бесполезный) факт: это моя двухсотая заметка на нашем портале. Наверное, повод отметить 🙂

 

«DevOps: современный подход к организации работы ИТ»
Учебный курс про менеджмент, а не про технические практики

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT