Конвейер развёртывания (в народе именуемый 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 января есть ещё свободные места, милости просим. Также есть возможность поговорить про нашу консалтинговую услугу “Построение работы продуктовых команд“.
И ещё забавный (и полностью бесполезный) факт: это моя двухсотая заметка на нашем портале. Наверное, повод отметить 🙂
