Руководство по непрерывной поставке: надежный выпуск ПО в продакшн.
Для того чтобы идти в ногу с текущими тенденциями рынка и потребностями потребителей, разработка ПО претерпела значительные изменения в своих принципах и подходах. Несмотря на то, что традиционная каскадная, еще её называют водопадная, модель разработки была более последовательной и спланированной, у неё были недостатки с точки зрения удовлетворения ожиданий клиентов в отношении конечного продукта.
На тот момент agile-разработка (или гибкие методики разработки) стала идеальным решением, поскольку она обеспечивала доставку части функционала / функциональных возможностей в конце каждого короткого цикла разработки или спринта. Вскоре это стало нормальным образом жизни.
Однако, чтобы вывести Agile на новый уровень, необходимо тестировать ПО сразу же после его сборки. Этот метод “сдвига влево” или “раннего тестирования” значительно улучшает качество ПО, снижая количество ошибок.
Вместе с этим появилась необходимость прочно связать Agile с процессами непрерывной поставки (CD) и непрерывной интеграции (CI). Ведь именно эти процессы дают необходимый импульс для бесперебойного функционирования процессов сборки, тестирования и релиза.
Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ ПО АВТОМАТИЗАЦИИ ТЕСТИРОВАНИЯ
Содержание:
Что такое непрерывная поставка?
Внедрение непрерывной поставки
Инструменты непрерывной поставки
Роль QA в CD: непрерывное тестирование (CT)
Факторы, формирующие базу знаний для обеспечения CT
Что такое непрерывная поставка?
Мартин Фаулер из ThoughtWorks определяет непрерывную поставку как “систему правил разработки ПО, при которой вы создаете ПО таким образом, что оно может быть выпущено в продакшн в любое время”.
Исходя из этого, можно сделать несколько очевидных выводов:
- Создаваемое ПО в значительной степени зависит от процесса, который должен быть основательным, точным и повторяемым.
- Поскольку ПО всегда должно быть готово к выпуску в продакшн, то крайне важно, чтобы оно было более ориентировано на пользователя. Как этого добиться? Собирайте обратную связь от пользователей как можно раньше.
В основе CD лежит непрерывная интеграция (CI), которая позволяет пользователям всегда иметь сборку с последними изменениями кода. Это означает, что разработчики должны часто вносить изменения в код, что подразумевает частые сборки. Таким образом, CD напрямую использует непрерывную интеграцию и является ее расширенной версией.
Внедрение непрерывной поставки
Ниже приведен общий обзор ключевых составляющих CD:
1. Автоматизация. Процессы, в которых точность является насущной необходимостью, безусловно, требуют высокой степени автоматизации. Это также соответствует базовым правилам обеспечения качества ПО, которые рекомендуют инвестировать в автоматизацию тестов для постоянно повторяющихся задач.
Чтобы увидеть всю красоту непрерывной поставки, необходимо внедрять автоматизацию во всех возможных областях, начиная от простого сбора требований и заканчивая чуть более сложным развертыванием (деплоем). Налаживание процессов автоматизации – это первый шаг к достижению желаемой надежности в CD.
2. Система контроля версий. В быстро развивающейся проектной разработке над одним и тем же кодом или ресурсом проекта одновременно могут работать несколько человек. Это требует наличия системы контроля версий для облегчения отслеживания любых изменений и просмотра изменений членами команды.
3. Метрики качества. Измерение успеха и установление контрольных показателей играют важную роль для достижения положительных результатов процесса CD. Проблемные области находятся легко, когда налажены сбор метрик и аналитика. Затем, на основе выявленных проблем, определяются пути восстановления.
4. DevOps. Это, пожалуй, самое важное и фундаментальное, на чем следует сосредоточиться при внедрении процесса CD. DevOps обеспечивает объединение двух изолированных сущностей в жизненном цикле ПО (Software Development Life Cycle или SDLC): разработка и эксплуатация.
Начиная с создания сред окружения, их настройки, управления частью процесса сборки и тестирования развертывания сборок, DevOps несет большие перемены во взглядах на весь процесс. Такое сотрудничество обеспечивает быстрое развертывание. Поэтому можно с уверенностью сказать, что DevOps является отправной точкой для создания успешного процесса CD.
5. Улучшения и совершенствование. Определите, как процесс CD может постоянно улучшаться, легко поддерживаться и обновляться. В случае возникновения каких-либо сбоев в процессе, безусловно, лучше пресечь их на корню, чем использовать временное решение или обходной путь.
Инструменты непрерывной поставки
Поскольку автоматизация составляет основу CD (не просто автоматизация функционального тестирования, а комплексная автоматизация всего конвейера), существуют инструменты, используемые на каждом этапе процесса, вплоть до развертывания. Такие инструменты, как контроль версий, модульное тестирование, CI, автоматизация сборки, проверка качества и т.д., помогают комплексно решать задачи каждого этапа.
Вот полный список лучших инструментов непрерывной доставки
Конвейер непрерывной доставки
Ниже приведена диаграмма, отражающая общую схему работы процесса CD.
Обратите внимание, что:
- На каждом этапе конвейера, начиная с check-in кода и заканчивая отправкой в продакшн, есть стрелка, указывающая на предыдущий блок. Это лишь подтверждает, насколько сильно процесс CD зависит от обратной связи.
- Скажем, разработчик вносит новый код в систему контроля версий, запускается процесс CD, в ходе которого создается сборка и запускается тестирование согласованности (sanity testing). Только если сборка считается “хорошей сборкой”, она передается на следующий этап проверки качества.
- Здесь в дело вступает команда QA, которая проводит необходимые тесты. Это могут быть базовые функциональные проверки или нефункциональные (различные стресс-тесты, нагрузочные тесты, тесты производительности и т. д.).
- Если в какой-либо момент возникает сбой или несоответствие, они помечаются и должны быть исправлены, чтобы конвейер CD мог продолжить работу.
- Наконец, после того, как конкретная сборка будет одобрена с точки зрения качества, она развертывается на продакшн.
Роль QA в CD: непрерывное тестирование (CT)
Из приведенного выше конвейера CD мы видим, какое место занимает обеспечение качества в общей схеме вещей. Теперь давайте углубимся в понимание того, что означает CD с точки зрения QA и как нужно применять совершенно новый подход к QA.
В традиционной модели тестирования существует временной разрыв между внесением кода разработчиком и получением тестировщиком сборки, содержащей этот код. Однако в CD новый код интегрируется довольно часто и непрерывно. Поэтому подразумевается, что тестирование должно быть ускорено, чтобы оно оставалось “непрерывным”.
Как это возможно?
Ответ очевиден, и мы это уже обсуждали – автоматизация! Автоматизация тестирования – это ключ к успешному тестированию в процессе непрерывной доставки. Чем больше, тем лучше. На всех уровнях.
Во-вторых, из-за того, что доставки могут осуществляться небольшими частями, падение функций может произойти в течение нескольких дней. Это означает, что может не хватить времени для полного планирования проведения тестирования. Доставленная часть функционала может даже не иметь графического интерфейса пользователя в данный момент. Поэтому подход к тестированию должен быть переработан и подвергнут радикальным изменениям.
Что это значит для тестировщика?
Необходимо преодолеть строгое разграничение ролей разработчика и тестировщика, практически стерев границы между их навыками. Тестировщики с самого начала должны быть знакомы с тем, что разрабатывается, “прокачивать” необходимые навыки. И точно так же разработчики должны знать, как тестировать.
Факторы, формирующие базу знаний для обеспечения CT
1. Рассуждение и постановка вопросов
Помимо того, что тестировщики совершенствуют свои технические навыки и вовлекаются в процесс как можно раньше, они должны применять аналитические рассуждения о создаваемом продукте. Это означает, что тестировщики должны уметь:
- Видеть общую картину
- Понимать реальное использование продукта в бизнесе
- Определять, соответствуют ли полученные требования правильному вектору
- Оценивать среду окружения и настройки, необходимые для тестирования определенных сценариев
- Решать, как должны проводиться различные тесты: функциональные, нефункциональные, доступности, безопасности и т.д.
- Определять, как использовать автоматизацию по-максимуму
Это подводит нас к следующему пункту – разработке стратегии тестирования.
2. Создание стратегии тестирования
Разработка модели, обеспечивающей обширное тестирование для устранения любых потенциальных проблем на различных уровнях разработки, гарантирует резкое повышение качества. Это определяется как “наслоение тестов” и также включает в себя область разработки.
Чем больше слоев вы добавляете, тем выше качество.
Давайте лучше разберем это на примере.
Рассмотрим приведенную ниже модель непрерывного тестирования. Теперь каждый раз, когда происходит изменение кода, оно будет проходить через все слои.
- Как правило, перед фиксацией изменений (коммитом) разработчики запускают несколько автоматизированных модульных тестов, чтобы убедиться, что их код в пригодном виде. В этой модели, разработчики иногда заимствуют у QA тесты “счастливого пути” (happy path) и дополнительно их запускают. Это составляет первый блок модели.
- После фиксации изменений в системе контроля версий, CI запускает обширные автотесты на следующем слое.
- Теперь, если на предыдущем этапе произошли какие-либо сбои, хорошо бы добавить еще один слой, прежде чем код будет передан команде тестирования. Это объясняет пунктирную рамку в третьем слое. Назовем его блоком обратной связи. На основании неудач на предыдущем этапе можно провести несколько ручных тестов для проверки вменяемости (пригодности), проанализировать покрытие автотестами и добавить дополнительные тесты для максимального покрытия.
- Следующий слой, где QA берет на себя ответственность. Сюда входит проверка функциональности, тесты производительности и т.д.
- После того как предыдущий слой даст какую-то уверенность в стабильности функций и в том, что большинство ошибок исправлено, то для еще большей уверенности можно добавить следующий слой, включающий приемочные тесты.
- Наконец, когда ПО деплоится (развертывается) на продакшн, его нужно активно отслеживать на предмет любых ошибок, которые могут возникнуть.
3. Совершенствование процесса
Чтобы иметь преимущество, необходимо постоянно совершенствовать весь процесс тестирования в CD окружении. Это может быть как небольшое улучшение канала связи, так и значительное улучшение тестовых сценариев, тестового покрытия, инструментов тестирования и т.д.
4. Повышение технических навыков, использование тестовых инструментов
Тестировщикам стало необходимо поднять свою роль на новый уровень и усовершенствовать свои технические знания. Для этого придется разобраться в архитектуре, коде и зависимостях компонентов. Они также должны обладать знаниями в области программирования, которые им позволят повысить эффективность автоматизации. Совершенствование навыков также должно распространяться и на использование инструментов для тестирования, которые помогут в автоматизации и общих усилиях по тестированию в CD.
Преимущества CD
Принимая во внимание вышеизложенное, автоматически приходит понимание того, что существует множество преимуществ, которые можно извлечь из CD.
Вот наиболее очевидные из них:
- Меньше ошибок: поскольку небольшие фрагменты кода часто интегрируются, вероятность того, что какая-либо ошибка будет пропущена, значительно снижается.
- Быстрая обратная связь/время решения: благодаря ранней обратной связи, интегрированной в CD, качество продукта в целом выше. Это также помогает поставлять продукт, который действительно полезен конечному пользователю, тем самым привлекая больше клиентов.
- Быстрое время выхода на рынок: CD помогает справиться с постоянно меняющимся рынком и потребностями потребителей благодаря частым и быстрым релизам. Время от идеи до реализации предельно сокращено.
Заключение
Для того чтобы внедрить непрерывную поставку, организациям, придерживающимся Agile-процесса, необходимо кардинально изменить свою точку зрения. Хотя внедрить эту технологию и не очень просто, но концентрация на преимуществах, безусловно, прокладывает путь к воплощению этого в жизнь.
Перевод статьи «Continuous Delivery Tutorial: Reliable Software Release to Production».