Если ваши релизы молниеносны, автоматизированы и надежны, пропустите эту статью.
Раньше наш процесс выпуска был ручным, медленным и пронизан ошибками.
Мы проваливали спринт за спринтом, потому что у нас не было времени завершить и опубликовать функции для следующего обзора спринта.
Мы ненавидели наши релизы.
Часто они длились три или четыре дня.
В этой статье мы опишем практику Stop the Line, которая помогла нам сосредоточиться на решении проблем производственного конвейера.
Всего за три месяца нам удалось увеличить скорость развертывания в 10 раз.
Сегодня наше развертывание полностью автоматизировано, а выпуск монолита занимает всего 4-5 часов.
Остановите линию.
Практика, придуманная командой Я помню, когда мы придумали Stop the Line. На общей ретроспективе мы обсуждали длинные релизы, которые мешали нам достичь целей спринта.
Один из наших разработчиков предложил:
— [Сергей] Давайте ограничим объём выпуска.Мы решили, что если релиз продлится более 48 часов, то включаем мигалку и останавливаем все команды, работающие над бизнес-фичами монолита.Это поможет нам тестировать, исправлять ошибки и быстрее развертывать.
— [Дима] Может, ввести ограничение на незавершенное производство (WIP limit)? Например, как только мы выполнили 10 задач, мы прекращаем разработку.
— [Разработчики] Но задачи могут быть разными по размеру.
Это не решит проблему больших релизов.
— [Me] Давайте введем ограничение, основанное на продолжительности релиза, а не на количестве заданий.
Мы прекратим разработку, если релиз займет слишком много времени.
Всем командам, работающим над монолитом, следует прекратить разработку и сосредоточиться на запуске текущей версии в производство или устранении причин, вызвавших задержку выпуска.
Когда релиз застрял, нет смысла создавать новые функции, потому что они все равно не скоро будут выпущены.
В это время запрещено писать новый код, даже в отдельных ветках.
Мы также представили доску «Остановить линию» на простом флипчарте.
Мы используем его для написания задач, которые либо помогают завершить текущий релиз, либо помогают избежать причин его задержки.
Конечно, Stop The Line — непростое решение, но эта практика — важный шаг на пути к непрерывной доставке и настоящему DevOps. История Dodo IS (техническая преамбула) Dodo IS написан в основном на платформе .
Net с пользовательским интерфейсом на React/Redux, с небольшим количеством jQuery и небольшим количеством Angular. Также есть приложения для iOS и Android, использующие Swift и Kotlin. Архитектура Dodo IS представляет собой смесь устаревшего монолита и около 20 микросервисов.
Мы разрабатываем новые бизнес-функции в отдельных микросервисах, которые развертываются либо при каждом коммите (непрерывное развертывание), либо по требованию, когда это необходимо бизнесу, даже каждые пять минут (непрерывная доставка).
Но у нас по-прежнему огромная часть нашей бизнес-логики реализована в монолитной архитектуре.
Монолит сложнее всего развернуть.
Для сборки всей системы требуется время (артефакт сборки весит около 1 ГБ), запуск модульных и интеграционных тестов, а также выполнение ручных регрессий перед каждым выпуском.
Сам релиз тоже медленный.
Каждая страна развернёт свой экземпляр монолита, поэтому нам придётся развернуть 12 экземпляров для 12 стран.
Непрерывная интеграция (CI) — это практика, которая помогает разработчикам постоянно поддерживать код в рабочем состоянии, наращивая продукт небольшими шагами, интегрируя хотя бы ежедневно в одной ветке, поддерживаемой CI-сборкой со множеством автотестов.
Когда несколько команд работают над одним продуктом и практикуют CI, количество изменений в общей ветке быстро растет. Чем больше изменений вы накопите, тем больше в них будет скрытых дефектов и потенциальных проблем.
Вот почему команды предпочитают часто вносить изменения, что приводит к использованию непрерывной доставки (CD) как следующего логического шага после CI. Практика компакт-дисков позволяет развертывать код в производство в любое время.
Эта практика основана на конвейере развертывания — наборе автоматических или ручных шагов, которые проверяют приращение продукта на пути к производству.
Наш конвейер развертывания выглядит следующим образом: 
Рис.
1. Конвейер развертывания Dodo IS
Освободим скорее: от проблемы к адаптированной практике Остановить очередь
Боль медленных релизов.
Почему они такие длинные? Анализ В экстремальном программировании (XP) есть золотое правило: если что-то болит, делай это как можно чаще.
Наши релизы всегда были болью.
Мы потратили несколько дней на настройку тестовой среды, восстановление базы данных, запуск тестов (обычно несколько раз), выяснение, почему они не удались, исправление ошибок и, наконец, выпуск продукта.
Спринт длится 2 недели, а релиз выходит в течение трёх дней.
Чтобы иметь возможность выпустить релиз до обзора спринта в пятницу, вам необходимо начать выпуск в понедельник.
Это означает, что мы работаем над достижением цели спринта только 50% времени.
А если бы мы могли выпускать каждый день, то продуктивный период работы увеличился бы до 80-90%.
Наш средний выпуск обычно занимал два-три дня.
Поначалу над кодом в общей ветке разработки работали шесть команд (а по мере роста компании количество команд увеличилось до девяти).
Незадолго до релиза мы запустили ветку релиза.
Пока эта ветка тестируется и регрессируется, команды продолжают разработку в общей ветке разработки.
Прежде чем ветка релиза достигнет рабочей среды, команды напишут довольно много кода.
Чем больше изменений в инкременте, тем больше вероятность того, что изменения, внесенные разными командами, повлияют друг на друга, а значит, тем тщательнее нужно тестировать инкремент и тем больше времени потребуется на его выпуск.
Это самоусиливающийся цикл (см.
рисунок 2).
Чем больше изменений в релизе («лошадиный» релиз), тем дольше время регресса.
Чем дольше время регрессии, тем больше времени между релизами и тем больше изменений вносят команды перед следующим релизом.
Мы называли это «лошади рожают лошадей».
Следующая диаграмма CLD (диаграмма причинно-следственной связи) иллюстрирует эту взаимосвязь: 
Рис.
2. Диаграмма CLD: длинные релизы ведут к ещё более длинным релизам
Автоматизация регрессии с командой контроля качества
Шаги, составляющие релиз- Настройка окружения.
Восстанавливаем базу продаж (675 ГБ), шифруем персональные данные и очищаем очереди RabbitMQ. Шифрование данных является очень трудоемкой операцией и занимает около 1 часа.
- Запускайте автоматические тесты.
Некоторые UI-тесты нестабильны, поэтому нам приходится запускать их несколько раз, пока они не пройдут. Исправление тестов перепрошивки требует большого внимания и дисциплины.
- Ручные приемочные испытания.
Некоторые команды предпочитают провести окончательную приемку до того, как код поступит в производство.
Это может занять несколько часов.
Если они находят ошибки, мы даем командам два часа на их исправление, в противном случае они должны откатить свои изменения.
- Развертывание для продолжения Поскольку у нас есть отдельные экземпляры Dodo IS для каждой страны, процесс развертывания занимает некоторое время.
После завершения развертывания в первой стране некоторое время смотрим логи, ищем ошибки, а затем продолжаем развертывание в остальных странах.
Весь процесс обычно занимает около двух часов, но иногда может занять больше времени, особенно если приходится откатывать релиз.
Два года назад ручной регресс Dodo IS длился целую неделю.
Тогда у нас была целая команда ручных тестировщиков, которые неделю за неделей тестировали одни и те же функции в 10 странах.
Такой работе не позавидуешь.
В июне 2017 года мы сформировали команду контроля качества.
Основной целью команды была автоматизация регресса важнейших бизнес-операций: приёма заказов и производства продукции.
Как только у нас было достаточно тестов, и мы начали им доверять, мы полностью отказались от ручного тестирования.
Но это произошло всего через 1,5 года после того, как мы начали автоматизировать регресс.
После этого мы распустили команду QA, и члены команды QA присоединились к командам разработчиков.
Однако UI-тесты имеют существенные недостатки.
Поскольку они зависят от реальных данных в базе данных, эти данные необходимо настроить.
Один тест может испортить данные другого теста.
Тест может провалиться не только потому, что нарушена какая-то логика, но и из-за медленной сети или устаревших данных в кеше.
Нам пришлось потратить немало усилий, чтобы избавиться от мигающих тестов и сделать их надежными и воспроизводимыми.
Один шаг, чтобы остановить очередь.
Инициатива #IReleaseEveryDay Мы создали сообщество единомышленников #IReleaseEveryDay и придумали, как ускорить процесс развертывания.
Первыми шагами были:
- Мы значительно сократили набор UI-тестов, исключив повторяющиеся и ненужные тесты.
Это сократило время тестирования на несколько десятков минут;
- Мы значительно сократили время, необходимое для настройки среды, за счет предварительного восстановления базы данных и шифрования данных.
Например, сейчас мы создаем резервную копию базы данных ночью, а как только стартует релиз, через несколько секунд переключаем тестовую среду на резервную базу данных.
Пришло время системных перемен.
Что, если.
Мы ввели правило, что если релиз длится более 48 часов, то мы включаем мигалку и останавливаем все команды, работающие над бизнес-фичами монолита.
Все команды, работающие над монолитом, должны прекратить разработку и сосредоточиться на выводе текущей версии на рынок или устранении причин, вызвавших задержку выпуска.
Когда релиз застрял, нет смысла создавать новые функции, потому что они все равно не скоро будут выпущены.В это время запрещено писать новый код, даже в отдельных ветках.
Этот принцип описан в статье Мартина Фаулера «Непрерывная доставка»: «Если есть проблемы с дисплеем, ваша команда должна поставить решение этих проблем в приоритет перед работой над новыми функциями».
Окружающая мигалка
Во время операции «Останови линию» в офисе загорается мигающая оранжевая лампочка.Этот визуальный сигнал видит каждый, кто приходит на третий этаж, где работают разработчики «Додо ИС».
Мы решили не сводить с ума наших разработчиков звуком сирены и оставили только раздражающее мигание.
Так и должно быть.
Как мы можем чувствовать себя комфортно, когда с релизом проблемы? 
Рис.
3. Остановите мигалку линии.
Командное сопротивление и небольшие диверсии
Поначалу Stop the Line понравился всем командам, потому что это было весело.Все радовались как дети и выкладывали фотографии наших мигалок.
Но когда горит 3-4 дня подряд, становится уже не смешно.
Однажды одна из команд нарушила правила и отправила код в ветку разработки во время Stop the Line, чтобы сохранить свою цель спринта.
Самый простой способ нарушить правило — если оно мешает вашей работе.
Это быстрый и грязный способ реализовать бизнес-функцию, игнорируя при этом системную проблему.
Я, как Скрам-мастер, терпеть не мог нарушений правил, поэтому поднял этот вопрос на общей ретроспективе.
У нас был трудный разговор.
Большинство команд согласились, что правила применимы ко всем.
Мы договорились, что каждая команда должна следовать правилам, даже если она с ними не согласна.
А заодно о том, как можно изменить правила, не дожидаясь следующей ретроспективы.
Что не получилось так, как планировалось?
Изначально разработчики не фокусировались на решении системных проблем с помощью конвейера развертывания.Когда релиз застревал, вместо того, чтобы помочь устранить причины задержки, они решили разработать микросервисы, на которые не распространялось правило Stop the Line. Микросервисы — это хорошо, но проблемы монолита сами собой не решатся.
Чтобы решить эти проблемы, мы ввели бэклог Stop The Line. Некоторые решения представляли собой быстрые решения, которые скрывали проблемы, а не решали их.
Например, многие тесты были исправлены путем увеличения таймаутов или добавления повторов.
Один из этих тестов длился 21 минуту.
Тест искал последнего созданного сотрудника в таблице без индекса.
Вместо исправления логики запроса программист добавил 3 ретрея.
В результате медленный тест стал еще медленнее.
Когда у Stop The Line появилась команда владельцев, занимавшаяся вопросами тестирования, в течение следующих трех спринтов они смогли ускорить наши тесты в 2-3 раза.
Как изменилось поведение команд после тренировки «Стоп линия»?
Раньше проблемы с релизом испытывала только одна команда — та, которая поддерживала релиз.Команды старались как можно быстрее избавиться от этой неприятной ответственности, а не вкладываться в долгосрочные улучшения.
Например, если тесты в промежуточной среде завершаются неудачно, вы можете перезапустить их локально, а если тесты пройдены, продолжить выпуск.
С появлением Stop The Line у команд теперь есть время стабилизировать свои тесты.
Мы переписали код подготовки тестовых данных, заменили некоторые UI-тесты на API-тесты и убрали ненужные таймауты.
Теперь практически все тесты проходят быстро и в любых условиях.
Раньше команды не решали системного технического долга.
Теперь у нас есть портфель технических улучшений, которые мы рассматриваем во время Stop the Line. Например, мы переписали тесты на .
Net Core, что позволило запускать их в Docker. Запуск тестов в Docker позволил нам использовать Selenium Grid для распараллеливания тестов и дальнейшего сокращения времени их выполнения.
Раньше команды полагались на команду контроля качества при тестировании и команду по инфраструктуре при развертывании.
Теперь вам не на кого рассчитывать, кроме себя.
Команды сами тестируют и выпускают код в Production. Это настоящий, а не фальшивый DevOps.
Ээволюция метода остановки линии
На общей ретроспективе спринта мы рассматриваем эксперименты.В течение следующих нескольких ретроспектив мы внесли много изменений в правила Stop the Line, например:
- Канал релиза.
Вся информация о текущем релизе находится в отдельном канале Slack. На канале собраны все команды, чьи изменения вошли в релиз.
В этом канале релизмен просит о помощи.
- Журнал релиза.
Лицо, ответственное за выпуск, протоколирует свои действия.
Это помогает найти причины задержки выпуска и выявить закономерности.
- Правило пяти минут. В течение пяти минут после объявления «Стоп линия» представители команд собираются вокруг мигалки.
- Отставание.
Остановите очередь.
На стене висит флипчарт с бэклогом Stop The Line — списком задач, которые команды могут выполнить, пока очередь остановлена.
- Не обращайте внимания на последнюю пятницу спринта.
Несправедливо сравнивать два релиза, например, один, который стартовал в понедельник, и другой, который стартовал в пятницу.
Первая команда может потратить два полных дня на поддержку релиза, а во время второго релиза в пятницу (обзор спринта, ретроспектива команды, общая ретроспектива) и в следующий понедельник (общее планирование и планирование командного спринта) будет проводиться множество мероприятий.
У пятничной команды меньше времени на выпуск поддержки.
Выпуск в пятницу с большей вероятностью будет остановлен, чем выпуск в понедельник.
Поэтому мы решили исключить из уравнения последнюю пятницу спринта.
- Ликвидация технического долга.
Через пару месяцев команды решили, что во время шатдауна можно поработать над техническим долгом, а не только над ускорением пайплайна развертывания.
- Владелец компании Stop Line. Один из разработчиков вызвался стать владельцем Stop The Line. Он глубоко изучает, почему релизы задерживаются, и управляет очередью Stop the Line. Когда очередь останавливается, владелец может привлечь любую команду к работе над элементами невыполненной работы «Остановить очередь».
- Посмертное.
Владелец Stop the Line проводит вскрытие после каждой остановки.
Стоимость потерь Из-за «Стоп-линии» мы пропустили несколько целей в спринте.Представители бизнеса были не слишком довольны нашим прогрессом и задавали много вопросов на Обзоре Спринта.
Следуя принципу прозрачности, мы объяснили, что такое Stop the Line и почему стоит подождать еще несколько спринтов.
На каждом обзоре спринта мы показывали командам и заинтересованным сторонам, сколько денег мы потеряли из-за Stop the Line. Стоимость рассчитывается как общая зарплата команд разработчиков во время простоя.
• Ноябрь — 2 106 000 руб.
• Декабрь — 503 504 руб.
• Январь — 1 219 767 руб.
• февраль — 2 002 278 руб.
• Март - 0 руб.
• Апрель - 0 руб.
• Май — 361 138 руб.
Эта прозрачность создает здоровое давление и мотивирует команды немедленно решать проблемы с конвейером развертывания.
Глядя на эти цифры, наши команды понимают, что ничего не бывает бесплатно, и каждый Stop the Line обходится нам в копеечку.
Результаты
Фактически практика «Остановить линию» преобразует цикл самоусиления (рис.2) в два цикла балансировки (рис.
4).
Stop the Line помогает нам сосредоточиться на улучшении конвейера развертывания, когда он становится слишком медленным.
Всего за 4 спринта мы:
- Выпущено 12 стабильных выпусков
- Сокращение времени сборки на 30%
- Стабилизированные тесты пользовательского интерфейса и API. Теперь они работают во всех средах и даже локально.
- Избавился от тестов прошивки
- Начали доверять нашим тестам
Рис.
4. Диаграмма CLD: остановка времени освобождения линейных балансов
Выводы Скрам-мастера
Stop The Line — яркий пример надежного решения, созданного самими командами разработчиков.Скрам-мастер не может просто принести в команды новую блестящую практику.
Практика сработает только в том случае, если команды сами ее придумали.
Для этого необходимы благоприятные условия: атмосфера доверия и культура экспериментирования.
Крайне важны доверие и поддержка со стороны бизнеса, что возможно только при полной прозрачности.
Обратная связь, такая как регулярные общие ретроспективы со всеми членами команды, помогает разрабатывать, внедрять и изменять новые практики.
Со временем практика «Остановить линию» должна уничтожить сама себя.
Чем чаще мы останавливаем линию, чем больше вкладываем в конвейер развертывания, тем стабильнее и быстрее становится релиз, тем меньше причин останавливаться.
В конечном итоге очередь никогда не остановится, если мы не решим снизить порог, например, с 48 до 24 часов.
Но благодаря такой практике мы значительно улучшили процедуру выпуска.
Команды приобрели опыт не только в разработке, но и в быстром обеспечении эффективности производства.
Это настоящий DevOps. Что дальше? Я не знаю.
Возможно, вскоре мы откажемся от этой практики.
Команды примут решение.
Но очевидно, что мы продолжим двигаться в направлении Continuous Delivery и DevOps. Однажды моя мечта выпускать монолит несколько раз в день обязательно сбудется.
Теги: #программирование #Управление проектами #ИТ-компании #ИТ-компании #Разработка веб-сайтов #релиз #конвейер #dodo is #непрерывная доставка #непрерывная интеграция #управление релизами #додо пицца инжиниринг #dodois #dodois #dodois #dodois #dodopizzaio #lean
-
Матик
19 Oct, 24 -
Сериализация В C++
19 Oct, 24 -
Упрощаем Жизнь С Помощью Sla
19 Oct, 24 -
Движок Unreal 4. Секвенсор Вместо Matinee
19 Oct, 24 -
Скажи «Стоп!» Негатива: Станьте Антикритиком
19 Oct, 24 -
Любопытные Курьезы «Вирусного Маркетинга»
19 Oct, 24
