Эта статья была первоначально опубликована на TestProject — блог автоматизации тестирования .
Следующая статья содержит подробное введение в Continuous Integration (CI), обязательную практику разработки программного обеспечения, и Jenkins , стандартный инструмент непрерывной интеграции с открытым исходным кодом. Внедрив Continuous Integration и сервер Jenkins CI, вы узнаете, как развертывание Jenkins может помочь вашей команде разработчиков выпустить программное обеспечение более высокого качества и сэкономить драгоценное время.
Ищете больше о Дженкинс и непрерывной интеграции? Проверьте эти замечательные ссылки:
- Screencast: Какие инструменты непрерывной интеграции поддерживают Bitbucket?
- Подготовка и сборка проекта PHP в Дженкинс
- Непрерывная интеграция с Jenkins
- Повторное знакомство с Jenkins: автоматизированное тестирование с конвейерами
- Установка и защита Jenkins
Современные практики разработки программного обеспечения требуют развертывания хорошо функционирующего программного обеспечения в производстве как можно скорее или чаще. Например, гибкие методологии напрямую обеспечивают это поведение, когда команды работают над небольшими приращениями и внедряются в производство после каждого спринта (см. « Тестирование стратегии автоматизации для вашего гибкого проекта» ).
Дни, когда команда разработчиков месяцами занималась разработкой программного обеспечения, а затем передавала его в QA, UAT и все в производство, больше не существуют. В наши дни основной упор делается на хорошо работающее программное обеспечение и никогда не допускается ситуаций, которые могут поставить под угрозу качество программного обеспечения, например, когда в конце цикла выпуска вносятся существенные изменения программного обеспечения. Это где непрерывная интеграция вступает в использование.
Что такое КИ?
CI — это практика, которая обеспечивает частую интеграцию тестируемого кода в стабильную ветку вашего проекта. Я бы особо подчеркнул «протестированный код» , поскольку это означает, что функция, разработанная в отдельной ветке, также тестируется и, как таковая, интегрируется в стабильная ветка.
Кто делает КИ?
Как правило, инженеры DevOps обычно назначаются для настройки конвейера CI. В настоящее время роль инженера DevOps очень похожа на инженера-тестировщика, поскольку обеспечивает как качество процесса, так и качество программного обеспечения. Я обычно говорю, что QA и производство — самое близкое место встречи с клиентом. В этом смысле CI предоставляет очень мощные инструменты для инженеров-тестировщиков для повышения общего качества процессов и программного обеспечения, активно участвуя в следующих областях:
- Автоматизация тестирования. Пару лет назад обсуждался вопрос ручного тестирования и тестирования автоматизации. С помощью CI автоматизация тестирования становится незаменимой, что в конечном итоге сэкономит много драгоценного времени, чтобы сосредоточиться на других задачах тестирования. Также стоит сказать, что ручное тестирование и автоматическое тестирование не могут быть взаимоисключающими.
- Отчет об испытаниях. Для отчетов об испытаниях в CI мы можем использовать существующие решения для составления отчетов или создать собственный модуль отчетности . В обоих случаях это дает четкое представление о «работоспособности» кода нашего приложения при каждом запуске сборки. Важно, чтобы эта информация была доступна всем членам команды разработчиков, и для повышения качества кода будут приложены постоянные усилия.
- Процесс развертывания. Инженеры-тестировщики более активно участвуют в процессе развертывания приложения, что позволяет получить дополнительную информацию о внутренней архитектуре используемых инструментов или сред автоматизации тестирования. Эти знания имеют большое значение, особенно для выявления «скрытых» проблем приложения.
Преимущества CI
- CI делает упор на автоматизацию тестирования, позволяя инженеру по тестированию сосредоточиться на предварительном тестировании, тестировании крайних случаев или даже на поиске новых подходов в тестировании.
- Качество определенного коммита в конкретной ветке видно через несколько минут после коммита разработчика.
- Интеграция в стабильную ветвь выполняется очень осторожно после того, как код был проверен в ветке (предполагается, что процесс CI запускает это). Развертывание приложения выполняется автоматически после правильной настройки и не требует повторяющихся команд.
- С точки зрения команды, все эти преимущества умножаются.
Типичные сценарии CI
Команда разработчиков имеет свой собственный репозиторий контроля версий, в котором существует проект (в настоящее время это обычно Github). Стабильная ветвь (мастер) обычно рассматривается как рабочая ветвь, а разработка новых функций редко осуществляется непосредственно на мастере. Вместо этого разработчики создают свою собственную ветку, где разрабатывают новые функции (ветка A для функции A). Когда изменения передаются в хранилище в этой конкретной ветке, и разработчики делают запросы на извлечение, некоторые базовые тесты (дымовые тесты) должны выполняться для этой ветви. С точки зрения CI это обычно означает следующее:
Когда процесс CI завершен, с точки зрения инженеров-тестировщиков и разработчиков, существует несколько требований:
- Тестер: еще раз протестируйте функцию A на ветви A
- Разработчик: обзор кода от другого разработчика, чтобы убедиться, что качество кода достаточно хорошее
- Разработчик: вручную объединить код, чтобы освоить и разрешить любые конфликты слияния (если они возникнут).
Дымовые тесты экономят значительное количество времени как для разработчиков, которые будут выполнять проверку кода, так и для инженеров-тестировщиков, которым необходимо повторно протестировать функцию A в ветви запроса на извлечение. Если тесты дыма не выполняются по запросу извлечения, разработчики, работавшие над функцией A, теперь несут ответственность за исправление функции теста дыма и создание нового запроса извлечения (код с проблемой не будет объединен с мастером, пока он не будет исправлен).
Если это проходит, и новый код для функции A объединяется на главном с точки зрения CI, происходит следующее:
Это указывает на то, что слияние прошло успешно, функция тестирования дыма все еще работает, и теперь инженеры-тестировщики должны повторно протестировать функцию A еще раз в основной ветви (чтобы убедиться, что объединение не вызвало какого-либо побочного эффекта для функции A) , Конечно, с течением времени рекомендуется усовершенствовать свой пакет автоматизации тестирования, чтобы охватить большинство функций.
Это становится все более и более важным на последующих итерациях проекта, когда у инженеров-испытателей появляется больше задач (тестирование текущих функций, а также всех предыдущих функций). Вот где регрессионное тестирование становится удобным: с точки зрения CI выполнение регрессионных тестов обычно происходит либо тогда, когда инженер по тестированию явно запускает регрессионное тестирование, либо с помощью планировщика (например: выполнять регрессионные тесты каждую ночь). Рекомендуется настроить это задание таким образом, чтобы мы могли указать, для какой ветви будет выполняться это задание (здесь вы можете прочитать больше о том, почему и когда выполнять автоматизацию регрессионных тестов ). Процедура может выглядеть следующим образом:
Введение в инструмент Дженкинс
Терминология сервера Jenkins CI
Работа: самая важная «единица» в терминологии Дженкинса — это работа. Задание — это единица выполнения на сервере Jenkins CI, которая должна иметь определенный результат (пройти / не пройти). Например: задание может быть заданием развертывания, заданием на проверку дыма, заданием регрессионного тестирования и т. Д. Задание состоит из нескольких областей, которые выполняются последовательно, что будет объяснено в следующем параграфе: Анатомия задания Дженкинса.
Плагин: одна из основных функций автоматизации тестирования Jenkins — это возможность настроить его, используя существующие плагины или создавая свои собственные. Все в инструменте Jenkins, от частей конфигурации задания до частей конфигурации Jenkins, на самом деле является плагином. Поскольку сообщество Jenkins является значительным, уже существуют различные плагины Jenkins для использования самых сложных задач рабочего процесса CI. Это означает, что весьма вероятно, что вы встретите полезный плагин вместо создания собственного решения.
Узел: в простейшей установке экземпляр Jenkins будет работать на одной машине, и все задания будут выполняться там. Для небольших тестов и небольшого количества заданий это имеет смысл. Однако на практике часто бывают случаи, когда несколько команд используют один и тот же экземпляр Jenkins. Поскольку у них большое количество заданий, выполнение одного экземпляра считается плохой практикой по ряду причин: безопасность, аварийное восстановление, производительность, масштабируемость и т. Д.
Введите главные / подчиненные узлы в Jenkins: мастер Jenkins используется только для планирования заданий, которые будут выполняться на подчиненных машинах Jenkins. Таким образом, мастер-машина Jenkins не используется интенсивно, и у команд есть собственные подчиненные машины, размер которых наиболее подходит для их проекта автоматизации тестирования. Кроме того, подчиненные узлы затем настраиваются для обработки некоторого числа параллельных заданий, которые выполняются (количество исполнителей на каждый узел). Существует также возможность настройки узлов по требованию из AWS. Это означало бы, что узлы будут существовать только тогда, когда над ними нужно выполнить задание. Это очень полезно, поскольку нам нужны более крупные машины, которые будут полностью использоваться только при выполнении регрессионных тестов. В этом конкретном случае более крупный экземпляр EC2 будет запущен в AWS, задание будет выполнено в этом экземпляре, и после его завершения (на основе настроенного времени простоя) этот экземпляр будет работать некоторое время. После этого будет определено, что является более выгодным при использовании услуг, оплачиваемых за час (например, услуг AWS).
Анатомия Дженкинса Иова
На сервере Jenkins CI каждое задание Jenkins состоит из нескольких частей:
-
Общие сведения: здесь мы указываем имя проекта / проекта / описание, добавляем параметры для заданий, если это необходимо, определяем политику ротации журналов заданий и т. Д. На следующих экранах показано, как настроить ротацию журналов (вы можете указать количество дней для хранения журналов сборки или число из последних сохраненных журналов сборки, как параметризовать задание (добавив строку BUILD_ID со значением по умолчанию 0.0.1, но это значение можно указать при запуске задания) и как настроить, где будет выполняться это задание (имя подчиненного узла ):
-
Управление исходным кодом Jenkins. Как следует из названия, именно здесь мы определяем репозиторий исходного кода, такой как GitHub или Subversion на сервере Jenkins CI:
-
Триггеры сборки Jenkins: запланируйте время выполнения задания (периодически, после какого-либо другого задания, когда происходит запрос на получение GitHub, когда изменение передается в GitHub и т. Д.
-
Среда сборки Jenkins: здесь мы определяем параметры, относящиеся к среде, в которой будет выполняться сборка (удалять рабочее пространство при каждом выполнении задания, прерывать работу, если зависает в течение некоторого периода времени … и т. Д.)
-
Сборка Jenkins: На сервере Jenkins CI это самый важный шаг в каждой работе. Результат этого шага влияет на состояние задания в конце выполнения. В зависимости от установленных плагинов доступно много опций, наиболее часто используемые плагины: «Выполнить оболочку», «Выполнить Groovy», «Вызвать Ant / Maven / Gradle», «Выполнить пакетную команду Windows» и т. Д.
Это пример часто используемого плагина «Execute shell», который дает возможность либо написать собственный встроенный скрипт оболочки, либо выполнить существующий.
-
Действия после сборки Jenkins: эта часть задания используется для отчета о результатах работы или вызова других заданий в конвейере Jenkins. В общем, мы можем отправить электронное письмо со статусом выполнения задания, мы можем опубликовать отчеты в формате HTML, результаты JUnit, опубликовать артефакты, которые были встроены в фазу сборки, в S3 и т. Д.
Обратите внимание, как $ BUILD_ID указан в строке темы письма. Поскольку это задание параметризовано, это значение указывается при запуске этого задания. Этот параметр можно использовать как в части задания Jenkins Build, так и в части Post-build.
Вывод
К настоящему времени вы знаете об основных преимуществах CI-сервера Jenkins и о том, как сам CI добавляет процесс разработки программного обеспечения и инженера по тестированию. Как и с любой другой технологией, требуется время, чтобы понять основы и ощутить преимущества. Я настоятельно рекомендую инвестировать время в CI, это определенно будет стоить в долгосрочной перспективе. В частности, после применения сервера Jenkins CI многие болезненные и повторяющиеся процедуры будут автоматизированы, и внезапно у вас будет больше времени, чтобы сосредоточиться на улучшении продукта.
Ваша команда также реализует Continuous Integration и сервер Jenkins CI? Не стесняйтесь делиться опытом своей команды и задавать вопросы в комментариях!
Эта статья была первоначально опубликована на TestProject — блог автоматизации тестирования .