Для будущих студентов курса "QA Lead" и всех интересующихся подготовили перевод интересного материала.
Также приглашаем принять участие в открытом уроке по теме: "Организация тестирования при различных методологиях разработки".
Непрерывная доставка и развертывание (с общей аббревиатурой CD) далеко не новые концепции. Десять лет назад Джез Хамбл и Дэвид Фарли опубликовали книгу «Continuous Delivery». Патрик Дебуа в 2009 году организовал конференцию «DevOpsDays» и создал хэштег #DevOps (также пишется как devops, devOps или Devops).
Конечно, концепция CD для некоторых команд в новинку. По этой теме есть множество курсов и публикаций, помогающих организациям успешно внедрять CD. Как и в любой практике, когда вы разберетесь с основами, появятся проблемы, которые нужно решить. В январе 2020 года мне посчастливилось посетить новую конференцию DeliveryConf, на которой слушатели могут получить более глубокие технические знания о непрерывной интеграции (CI) и непрерывной доставке. Основываясь на том, что я узнала там, о чем могу рассказать из своего опыта и опыта сообщества, мне бы хотелось поделиться некоторыми задачами, с которыми сегодня могут столкнуться некоторые команды в вопросах CD.
Тестирование
Сессии DeliveryConf, на которых я была (или позже смотрела на YouTube-канале), помогли мне увидеть больше примеров практических кейсов, в которых технология непрерывной доставки меняет представление о тестировании.
Автоматизация сложных работ или тяжелого труда – не новая идея, однако выступление Джессики Керр открыло мне новые перспективы. Ниже я приведу несколько примеров того, как можно использовать автоматизацию, чтобы освободить больше вашего времени для важных дел:
Автоматизация для сокращения времени на подтверждение или проверки доступности машины.
Автоматизация таких вещей, как процедуры, инструменты, получение учетных данных, процесс проверки PR.
Развертывание сред тестирования в облаке для каждого нового изменения.
Получается меньше узких мест, меньше конкуренции за общие ресурсы, меньше времени потраченного на ожидание передачи ресурса, ускоряется цикл обратной связи. Непрерывная доставка «оживляет» ПО в наших умах, поэтому мы всегда знаем, что в текущий момент происходит с ним.
Преобразование пайплайнов
Карта потока создания ценности – это один из методов бережливого производства. Она представляет из себя способ визуализации того, каким образом команда доставляет ценность клиенту. Карта потока создания ценности отражает все критические этапы процесса, фокусируясь только на том, что добавляет ценности продукту. Она показывает время, которое занимает каждый шаг в потоке создания ценности, и время, затраченное на ожидание тех этапов, которые не добавляют ценности, таких как передача каких-либо данных или информации, связанной с этапом, время ожидания во время принятия решений, ожидание высвобождения ресурсов, таких как тестовые среды или люди определенных специализаций.
Стив Перейра в своем выступлении рекомендовал составить карту потока создания ценности вашего пайплайна, чтобы выявить узкие места и сократить петли обратной связи. Его команда создала карту в Google Sheets, чтобы каждый член команды мог посмотреть на нее. Они оценили те шаги, которые выполняются вручную, автоматические шаги, время на передачу и время ожидания. Они выполняли один шаг в единицу времени. В конце концов, им удалось сократить время, необходимое для запуска пайплайна с четырех недель до четырех дней!
Вот пример того, как может выглядеть часть карты потока создания ценности пайплайна, включая время выполнения каждого шага и время ожидания между шагами:
Стив поделился несколькими замечательными советами, которые я в последствие слышала и на других сессиях: при создании своего процесса не стоит основываться на том, что делает какая-то известная компания, - оставайтесь внутри своего контекста. Обязательно вспомните про людей из службы поддержки клиентов, маркетинга, продаж - всех, кого затрагивает ваш процесс развертывания и релиза, отраженный на карте. Например, в вашей карте также должны быть отражены вспомогательные материалы для разработки и справочные документы на ранних этапах, а не в самом конце, где эти процессы могут блокировать релиз.
Команды, которые уже какое-то время занимаются CI/CD скорее всего имеют legacy пайпланы – те, которые уже существуют какое-то время. Обычно они плохо документированы, и никто не понимает их от начала до конца, они даже могут оказаться крайне нестабильными. На DeliveryConf Лаура Сантамария поделилась своими переживаниями об устаревании пайплайнов. Она также рекомендовала создать карту потока создания ценности для пайплайна с помощью любой документации, которую вы сможете найти, включая все, что записано в системе отслеживания инцидентов. Так можно лучше понять пайплайн и найти способы его стабилизации, улучшения и документирования.
Нам нужна визуализация, которая поможет нам увидеть, что не работает, и поговорить о том, как нужно улучшать процессы. Внедрение карты потока создания ценности – это проверенный метод, который просто работает.
«Нетрадиционные» программные приложения
Эмили Горченски рассказывала о непрерывной доставке в контексте машинного обучения (ML), о шаблонах и распространенных проблемах. Мои знания ML весьма поверхностны, однако мне было очень интересно. Я и не подозревала, что у моделей машинного обучения есть срок годности.
Эмили объясняла, что системы, управляемые данными, недетерминированы, что затрудняет их тестирование и совершенствование. У них сложный критерий приемки и они нелинейны, их можно расценивать как черный ящик. Даже небольшие изменения могут иметь непредсказуемый эффект в неожиданном месте. Границы определяются крайне тяжело. Она говорила следующее: «Разработка, управляемая данными, — это действительно сложно, и мы все сейчас разбираемся в этом недостаточно хорошо.». Если коротко, то ML и CD в связке все еще работают тяжко. Звучит немного обескураживающе, однако для работы над этим требуется больше экспериментов.
Для получения данных, создания и тестирования ML-продуктов и технологических переходов между ними может потребоваться несколько команд. Отсюда получаются потенциальные задержки, поэтому, когда дело доходит до продакшена, основные инсайты, которые несет в себе продукт, устаревают. Решение этих проблем требует междисциплинарного сотрудничества и большой сложной инфраструктуры.
Основной вывод, который я сделала, заключается в том, что непрерывная доставка имеет отношение к широкому спектру программных продуктов. CD все чаще используется для веб-приложений, встроенного ПО, ПО операционных систем. Применяя его к другим типам продуктов, таким как ML-модели, BI-системы, видео или аудио цифровые продукты – это то, что команды пытаются интегрировать прямо перед релизом. Эти типы продуктов представляют довольно большие проблемы для непрерывной доставки, но CD в них не является чем-то невозможным. Мы можем продолжать искать пути сдвига в сторону улучшения качества всех типов продуктов, и сдвига в сторону способов мониторинга и изучения того, как использовать новые технологии на продакшене.
Меньше слов, больше дела
Самый сильный посыл DeliveryConf заключается в том, что нужно на самом деле двигаться к CD – хотя бы маленькими шажками. Сосредоточьтесь на самом важном для ускорения работы. Экспериментируйте, визуализируйте эти эксперименты, измеряйте свой прогресс. CD можно внедрить даже в legacy-системы – мы слышали историю о том, как кто-то внедрил CD в приложение по сборке VAX, которому уже 45 лет!
Меня поразил акцент на маленьких шагах и экспериментах. Те же мысли мы слышим на конференциях, посвящённых тестированию и Agile-разработке. DevOps – это устранение силосов в организации. Что случится, если мы будем усердно работать над устранением силосов в сообществах? Мы сможем многому научиться друг у друга. Есть множество виртуальных конференций, посвящённых DevOps, например, DivOps, Failover Conf, и All Day DevOps. Используйте эти возможности для обучения!
Автоматизация – не единственная важная часть CD. Организационная культура и взаимоотношения между людьми с различными навыками и ролями также важны. Опять же, это тот посыл, которым мы делимся в сообществах, посвященных тестированию и Agile, и он справедлив практически для любой деятельности, которая помогает решать проблемы наших клиентов с помощью программного продукта.
Посмотрите, что вы еще можете автоматизировать, чтобы улучшить существующую CD или создать новую. Идеи автоматизации могут возникать органично во время разговоров о насущных проблемах. Найдите способы интегрировать в пайплайн важные действия, которые не могут быть автоматизированы, но при этом, чтобы вы все еще получали оперативную обратную связь. Ищите инструменты и методы, которые помогут снизить риски внедрения новых изменений в продакшен.
Узнать подробнее о курсе "QA Lead".
Записаться на вебинар по теме: "Организация тестирования при различных методологиях разработки".
Прямо сейчас в OTUS действуют максимальные новогодние скидки на все курсы. Ознакомиться с полным списком курсов вы можете по ссылке ниже. Также у всех желающих есть уникальная возможность отправить адресату подарочный сертификат на обучение в OTUS.
Кстати, о "красивой упаковке" онлайн-сертификатов мы рассказываем в этой статье.
