Руководство по jenkins

В новой статье рассмотрим основы CI/CD и познакомимся Jenkins. Вы узнаете, где применяется Jenkins и какие проблемы помогает решить, поймёте логику архитектурных решений и особенности структуры каталогов. А ещё научитесь устанавливать Jenkins и производить базовую конфигурацию.

За основу статьи взят первый урок нашего практического курса «CI/CD с Jenkins».

CI/CD: что это такое и зачем нужно

Скорость разработки продуктов — одно из главных конкурентных преимуществ в разработке ПО. Поэтому на смену старым моделям программирования пришла новая концепция CI/CD.

CI (Continuous Integration) — непрерывная интеграция. Разработчики, применяющие данный паттерн, могут проверять основную ветку репозитория каждый раз, когда что-то замержили в неё. Не просто запускать локальные проверки, а в рамках CI-пайплайна выполнять автоматические тесты, unit-тесты и др. 

CD, (Continuous Delivery) — непрерывная поставка. На этой стадии происходит автоматическое развертывание на стенды и тестовые окружения. Ещё CD расшифровывают как Continuous Deployment — непрерывное развёртывание. Это более продвинутый путь, на шаг дольше, чем непрерывная поставка. При таком подходе каждое изменение, которое мы коммитим в основную ветку репозитория, автоматически проходит все этапы CI и CD и затем попадает на продакшн.

Continuous Deployment Pipeline — высший пилотаж, который редко встречается на практике, потому что всегда есть определённые ограничения. Эти ограничения могут быть как в самом пайплайне, так и в бизнес-процессах с точки зрения безопасности. Но, однозначно, Continuous Deployment Pipeline — то, к чему нужно стремиться.

Цели CI/CD:

• обеспечение последовательного и автоматизированного способа сборки, упаковки и тестирования;

• автоматизация развёртывания в разных окружениях;

• сведение к минимуму ошибок и проблем. 

Добиться этих целей помогают четыре принципа, на которых основана концепция CI/CD. Первый принцип — разделение активности. Каждый из участников процесса делит ответственность за жизненные циклы продукта. Проектируется бизнес-логика, выбираются сквозные функции, проводятся тесты, организуется доставка кода из одного окружения в другое.

Второй принцип — снижение рисков. Чтобы баги не доходили до продакшена, контролируется корректность бизнес-логики, проверяется пользовательский опыт на стендах, улучшается процесс хранения и обработки данных. Чем раньше мы обнаружим риск, тем быстрее идентифицируем проблему и тем меньше средств потратим на её решение.

Третий принцип — сокращение цикла обратной связи. В рамках CI/CD мы стремимся увеличить скорость внесения изменений и согласования правок. 

Четвертый принцип — реализация среды. У разработчиков должно быть общее пространство для работы с основной веткой или со вспомогательными ветками. Это пространство должно быть отказоустойчивым и удобным для работы. 

Основные этапы CI/CD выглядят так:

Планирование основывается на пользовательском опыте и бизнес-функционале. Обычно за этот этап отвечают люди из анализа: они переводят требования с языка бизнеса на язык, понятный разработчикам и администраторам. Затем начинается этап работы с кодом — разработчики пишут код, проводят тестирования в ручном режиме и добавляют изменения в основную ветку репозитория. 

После того, как изменения попадают в репозиторий, система контроля версии инициирует сборку и тестирование проекта. Тестирование может быть как ручным, так и автоматическим — зависит от того, как работает команда. Далее всё уходит сначала на релиз, а затем на развёртывание. На этапе развёртывания уже протестированная версия приложения отправляется на продакшн и становится доступна пользователям.

Когда продукт попадает к пользователям, мы продолжаем следить за ним — этап поддержки и мониторинга. Мы контролируем, как пользователь идёт по бизнес-процессу, корректно ли работают интеграции. Если на стадии мониторинга мы обнаруживаем ошибку, возвращаемся к самому началу — к планированию. Аналитики разбирают, что пошло не так и предлагают новое решение, разработчики пишут код, и снова начинается процесс сборки.

Как и у любой методологии, у CI/CD есть свои плюсы и минусы:

Реализовать принципы CI/CD, свести к минимуму ошибки интеграции, а также ускорить релизы и повысить их качество помогает Jenkins.

Что такое Jenkins

Jenkins – не просто инструмент CI/CD. Это Framework, потому что он:

• Гибок и расширяем. Jenkins — опенсорсный проект с множеством внешних расширений.

• Минимален из коробки. У Jenkins есть контроллер. Вы можете подключить к нему несколько слоев и уже на этом сетапе собрать минимальный пайплайн, который позволит автоматизировать работу по обновлению сервисов.

• Требует настройки. Jenkins — один из кубиков, с помощью которого можно построить большую систему автоматизации. Но прежде чем сделать что-то, его придётся настроить.

Jenkins — это Java-приложение. У него есть контроллер или Master Mode — управляющий центр, который занимается планированием задач. Он запускает задачи согласно установленному расписанию на слэйвах, которые вы к нему прикрепили. Помимо этого контроллер хранит логи наших задач. Вся история хранится только на Master Mode, поэтому важно помнить о настройке правильной ротации логов.

Слэйвы или агенты — это то, что непосредственно выполняет сами задания. 

Коротко их взаимодействие можно описать так: контроллер запускает задачу и говорит агенту выполнить её, агент выполняет задачу и возвращает результат контроллеру. Контроллер получает результат и сохраняет его в build-логе.

Установка Jenkins

Разберём, как установить Jenkins, как настроить параметры JVM и почему это важно. Дополнительно познакомимся с Jenkins Home: что это за зверь и с чем его едят. Все действия будем выполнять на Ubuntu.

Перед установкой Jenkins нужно установить Java — без этого никак. Мы проверяем, есть ли на нашем виртуальном энвайронменте Java:

root@vs01:~# java --version

По умолчанию из коробки Java нет:

Рекомендуется использовать Java 11, потому что у неё более продвинутый Garbage Collector. Поставим её:

root@vs01:~# apt install openjdk-11-jre-headless

Проверим, что Java установилась:

root@vs01:~# java --version

Теперь нужно сконфигурировать файл limit.com. Но в Linux всё — файл, поэтому нужно установить фан-лимит, чтобы снять ограничения и позволить Jenkins генерировать файлы, дампы и др. Если не сделать этого, в каких-то случаях мы не сможем получить данные и понять, что же с Jenkins пошло не так.

Редактируем лимиты на Ubuntu:

root@vs01:~# vi/etс/security/limits.conf

И добавляем секцию управления и устанавливаем права на различные лимиты: хардовые, софтовые, size-файлы и др:

Дальше нужно установить фаервол на Ubuntu:

root@vs01:~# apt-get install ufw

Обязательно разрешаем OpenSSH-порт, потому что больше не сможем подключиться к этой машине:

root@vs01:~# ufw allow OpenSSH

8080 — порт, по которому работает Jenkins. 

root@vs01:~# ufw allow 8080

Проверяем Jenkins репозиторий, потому что по умолчанию его нет в стоке Ubuntu:

root@vs01:~# wget -q -o – http://pkg.jenkins.io/Debian-stable/jenjins.io.key|sudo gpg --dearmor -o /usr/share/keyrings/Jenkins.gpg

После того, как скопировали ключи, устанавливаем Jenkins в sources list:

Важно для Ubuntu делать apt-get update:

root@vs01:~# apt-get update -y

Теперь можем поставить Jenkins:

root@vs01:~# apt-get install Jenkins -y

Установка проходит довольно быстро. Если посмотреть верхнеуровнево, то Jenkins — это war-файл. И вы можете не устанавливать его в систему через system, а просто скачать war-файл и запускать через war.

Мы можем посмотреть статус Jenkins App:

root@vs01:~# systemctl status jenkins

Он активный, но нам этого недостаточно. Jenkins — это Java, а Java очень требовательно относится к памяти. Поэтому дальше поговорим про Garbage Collector — службу, которая очищает память от неиспользованных объектов. 

Мы немного «подтюним» Java-машину и добавим опции в файл etc systemd/system/jenkins.service:

root@vs01:~# vi /lib/systemd/system/Jenkins.service

Найдём Java OPTS:

Добавим больше опций: 

Обратите внимание, что в настройках мы указываем Xmx512m и Xms512 — размер оперативной памяти, который выделяем Java-машине для работы. Вообще размер зависит от количества доступной памяти в операционной системе и корректируется в соответствии с ней. По рекомендациям Cloud Business и личному опыту, нужно ставить не больше 16 гигабайт на hip size. Но при этом важно не забывать, что у вас есть Meta Space и система, которые тоже занимают память. Если у вас на машине 20 гигабайт памяти, смело можно ставить 16. Если у вас всего 18 гигабайт памяти, и вы выделяете 16 гигабайт под Jenkins и Java, не удивляйтесь, когда машина начнёт работать плохо, а в какой-то момент просто умрёт. 

Здесь выставляем Garbage Collector — UseG1GC:

И добавляем снятие автоматического дампа при out of memory:

Это полезная опция, когда Jenkins падает. Конечно, падения все равно будут случаться — мы не всегда можем рассчитать нагрузку и определить, сколько потребуется памяти для работы. Но параметр поможет понять, что произошло. 

Также в Garbage Collector выставляем лог — /var/lib/jenkins/gc.log:

Сохраняем.

Нужно перезагрузить Jenkins, но перед этим сделать daemon-reload:

root@vs01:~# systemctl daemon-reload
root@vs01:~# systemctl restart Jenkins

Проверим:

root@vs01:~# systemctl status Jenkins

oot@vs01:~# cat /proc/http://Jenkins.s043218.edu.slurm.io^C
root@vs01:~# cat /proc/67043/cmdline

Видим, что Java настроена как раз под те опции, что мы ей передали, и запускается Jenkins war:

Теперь откроем веб-интерфейс http://jenkins.s043218.edu.slurm.io. Он предлагает разблокировать Jenkins:

То есть первоначальная установка предполагает, что вы введете некий мастер-пароль. Jenkins сам подсказывает, где этот мастер-пароль можно найти — var/lib/jenkins/secret/initialAdminPassword. Давайте пойдём туда и посмотрим:

root@vs01:~# cd var/lib/jenkins/

root@vs01:/var/lib/jenkins/# cd secrets/
root@vs01:/var/lib/jenkins/secrets# ls -al

Initial password — пароль, который вы можете использовать один раз при первой установке Jenkins. После вы переключитесь на внутреннюю базу авторизации.

Следующий шаг — установить Suggested-плагины или самостоятельно выбрать плагины, которые хотите поставить. 

Список плагинов, которые используются в Suggested, достаточно правильный, поэтому рекомендуется просто поставить эти плагины автоматом. 

А пока Jenkins делает плагины, посмотрим на Home-директорию:

root@vs01:/var/lib/jenkins/secrets# cd ..
root@vs01:/var/lib/jenkins# ls -la

У Jenkins нет выделенной базы, как у некоторых систем. В качестве базы данных он использует директорию Jenkins Home, которая есть в каталоге файловой системы того сервера, на который выставили контролер. Здесь хранятся: конфиги, плагины, задания, которые мы делаем и всё, что связано с ними и т.д.

Вернёмся к Jenkins — он уже поставил домен и предлагает нам настроить первого пользователя. Заполним поля:

Далее Jenkins предлагает настроить URL:

Этот параметр достаточно важный, потому что его параметр будут использовать различные слэйвы для автоматического коннекта к мастеру. 

Итак, мы поставили Jenkins. Пока нет никаких заданий, но мы можем немного пройтись по Manage Jenkins:

Из наиболее интересного здесь:

• System information — хранит всю основную информацию (Java Home, версия Java, версия Ubuntu и т.д.). 

• System log — то, куда нужно смотреть, если непонятно, почему не подключается агент или не работает скрип. 

• Load statistics — показывает, сколько экзекьюторов всего онлайн.

На этом всё. В рамках первого урока мы повторили цели CI/CD, узнали, что такое Jenkins и рассмотрели область его применения. Ещё попробовали самостоятельно установить Jenkins на Ubuntu-сервер и познакомились с содержимым Jenkins Home. В следующих уроках подробно разберём администрирование Jenkins, научимся настраивать интеграции, создавать конфигурации Jenkins As a Code и многое другое. 

Введение в Jenkins

Здесь я выполняю упражнения по теме курса

https://github.com/ksemaev/project_template

Запуск виртуалок

Для запуска выполнить

vagrant up
vagrant provision

Что бы получить ssh нужно выполнить vagrant ssh jenkins. Ожидается, что в папке с Vagrantfile
существует папка с именем sync, она будет замаплена на каталог /vagrant на виртуалках.

После установки UI доступен через localhost:18080.
При первом входе будет запрошен пароль, который можно посмотреть командой

sudo cat /var/lib/jenkins/secrets/initialAdminPassword

Затем вероятно возникнет сообщение «Offline. This Jenkins instance appears to be offline.»
причиной которого являются просроченные сертификаты и как следствие неработающий https.
Лечится заменой https на http в теге url в файле /var/lib/jenkins/hudson.model.UpdateCenter.xml.
После это правки нужно рестартовать дженкинс sudo service jenkins restart и снова открыть интерфейс.

Появятся 2 кнопки выбор плагинов по умолчанию и избирательно, можно установить плагины по умолчанию.
После нажатия нужно дождаться завершения загрузки.

Затем будет предложено создать пользователя — можно отказаться и продолжить под учеткой админа (паролем будет код подтвержения см.выше).
Что бы установить пароль, нужно перейти в раздел «Пользователи», выбрать в списке «admin», в меню «Настроить»,
ввести новый пароль и подтверждение и нажать сохранить — это потребует перелогиниться.

Настройка ssh на слейв-машине

Дженскинс будет подключаться к целевой системе по ssh и выполнять в ней определенные действия.
Для этого ему нужно предоставить ssh-доступ по ключу.
Сначала нужно сгенерировать ключ, войти на машину с дженкинсом vagrant ssh jenkins и выполнить последовательность команд:

Проверить имя пользователя под учеткой которого работает jenkins. Зайти под этим пользователем, и сгенерировать ssh-ключ:

sudo su jenkins
ssh-keygen

принять имя файла и пустую контрольную фразу , .
Затем можно выйти из под учетки jenkins, «забрать» сгененрированный открытый ключ, и выйти из шелла:

exit
cp /var/lib/jenkins/.ssh/id_rsa.pub /vagrant
logout

Теперь нужно подключиться к слейву vagrant ssh slave.
Предполагается, что на слейве дженкинс будет работать под root.
Нужно перейти в root sudo su root, в домашнем каталоге создать папку cd ~ && mkdir .ssh, если её нет.
И скопировать в неё файл с открытым ключем из расшареной папки cp /vagrant/id_rsa.pub ~/.ssh/authorized_keys,
копия должна называться authorized_keys.
Можно выйти из учетки и из шелла:

Для проверки подключаемся к другой виртуалке vagrant ssh jenkins. Перейти под учетку jenkins
и попытаться подключиться по ssh:

sudo su jenkins
ssh root@192.168.33.20

При подключении возникнет запрос на подтверждение fingerprint, нужно ответить yes.
После этого должно произойти подключение с правами root. Это показатель успешной настройки.

Тестовый джоб

Сейчас всё готово, что бы можно было создать «hello world» джоб через интерфейс дженкинса.
Нужно зайти под админом, на основной вкладке будет отображаться предложение создать новый джоб.
После клика по кнопке отобразится экран на котором нужно ввести имя Item’a (джоба) например test-job,
и из вариантов выбрать «Создать задачу со свободной конфигурацией» и нажать «Ок».
Отобразится экран со множеством панелей, на панели «Сборка» нужно добавить шаг «Выполнить команду shell».
В поле ввести ssh 192.168.33.20 'hostname' — войти в систему slave под root и выполнить команду hostname.
Нажать «Сохранить», что переключит экран в раздел данного джоба. Здесть нужно выбрать «Собрать сейчас».
Джоб начнет выполняться, на что указывает прогрессбар в левой части экрана. Через некоторое время «шарик» станет красным —
джоб завершился с ошибкой. Это произошло т.к. дженкинс пытался подключиться к удаленной машине под учеткой jenkins.
Нужно исправить команду: ssh root@192.168.33.20 'hostname', для чего перейти в меню «Настройки» и повторить
шаги аналогиные созданию джоба.
Повторить «Соборку» — теперь шарик станет синим, это говорит о том, что задача выполнена без ошибок.

PS: Шарик синий т.к. в японии вместо зеленого используется синий цвет светофора (что можно исправить плагином «Green balls»).
Для установки плагина надо открыть меню «Настроить Jenkins» — «Управление плагинами» — «Доступные» и в списке отметить галочкой «Green Balls» (можно использовать фильтр),
нажать «Установить без перезагрузки», на следующем экране отметив «Перезапустить Jenkins по окончанию установки и отсутствии активных задач».
Во время установки интерфейс может зафризиться, поэтом через некоторое время можно попробовать нажать F5. Шарики должны стать зелеными.

Pipeline

Подготовительные шаги: установить git на машине jenkins: sudo apt-get -y install git, задать «DNS» для 192.168.33.20: echo '192.168.33.20 slave' >> /etc/hosts (возможно это можно сделать более «продакшн» способом).
После добавления DNS имени сервера нужно зайти под jenkins: sudo su jenkins и выполнить ssh root@slave, снова утвердительно ответить на вопрос про fingerprint, выйти из под jenkins.

Создать папку jenkinsfiles и в ней файл first_steps.jenkins — это описание пайплайна на groovy. Файлы этого проекта будут размещены на GitHub в репозитории https://github.com/Nikolayill/jenkins_tutorial

Теперь создадим пайплайн в Jenkins. На основном экране с джобами нужно выбрать «Создать Item», вести «first_steps», выбрать Pipline, нажать Ok. Перейти на вкладку Pipeline, Definition установить в «Pipeline script from SCM»,
SCM — «Git», Repository URL «https://github.com/Nikolayill/jenkins_tutorial.git», Script Path «jenkinsfiles/first_steps.jenkins», «Сохранить».
Теперь можно «Собрать сейчас», джоб должен выполниться без ошибок.
В меню джоба «Status» будут отображаться два выполненных стейджа, имена и команды для которых определены в first_steps.jenkins (см. комментарии в файле). Для каждого стейджа можно посмотреть отдельный лог, если кликнуть на соответсвующем прямоугольнике.

Установка Docker

У меня используется старый дистрибутив Ubuntu поэтому установка докера будет несколько отличаться от туториала (см. https://docs.docker.com/install/linux/docker-ce/ubuntu/)

1. Добавление репозиториев

Добавление ключа (шаг 1-3 в ориг. документе):

sudo apt-get update

sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg-agent \
    software-properties-common
	
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -

Добавление репозитория (шаг.4):

sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   trusty \
   stable"

• здесь жестко прописан дистрибутив «trusty»

2. Установка пакетов

sudo apt-get update

sudo apt-get install docker-ce=17.03.0~ce-0~ubuntu-trusty

в отличие от более новых версий, в этой всё ставится одним пакетом — docker-ce-cli containerd.io ставить не требуется.

3. Предоставление прав для Jenkins

Что бы дженкинс мог работать стартовать докер, нужно включить его в группу docker: sudo usermod -a -G docker jenkins.
Можно переключиться на учетку jenkins и проверить работоспособность докера:

Должно отобразиться примерно такое сообщение:

Hello from Docker!
This message shows that your installation appears to be working correctly.

Выйти из учетки jenkins. И перезапустить jenkins что бы он «подхватил» изменения в системе после установки докера.

sudo service jenkins restart

Pipeline сборки docker образа

Протестируем работу докера на примере простейшей сборки образа.

Создадим новый пайплайн docker_build. Далее повторим шаги аналогично first_steps.
Выберем Script Path «jenkinsfiles/docker_build.jenkins». Теперь можно сохраниться и выполнить сборку.
PS: semaev/toolbox — название образа от автора оригинального курса было оставлено без изменений.

Запуск сборки по коммиту

Jenkins можно настроить на запуск пайплайна по факту изменений в Git (либо другой SCM). Настройка подразумевает два возможных режима работы — push и pull.
В режиме push оповещение об изменениях берет на себя SCM-система, а Jenkins предоставляет точку входа (hook — некий уникальный URL).
В режиме pull (poll?) Jenkins по расписанию опрашивает SCM и запускает пайплайн при изменениях.\

В данной конфигурации у нас нет возможности смоделировать работу pull механизма т.к. Jenkins находится в виртуалке за NAT-ом т.о. мы не можем предоставить точку входа для SCM.

Pull механизм настраивается в jenkins-файле добавлением секции triggers{ pollSCM('* * * * *') }, где через pollSCM задается cron-расписание опроса см. triggers.
В данном случае опрос производится с максимальной частотой (раз в минуту).

Docker registry

Для дальнейшей работы нам потребуется Docker-registry. Можно воспользоваться DockerHub, либо поднять registry локально (см.Быстрый запуск и использование своего открытого docker-registry)

Настройка локального регистра (репозитория)

Сначала нужно установить докер, действуя аналогично, как при установки докера на jenkins.
Что бы запустить регистр локально есть готовый образ https://hub.docker.com/_/registry/?tab=description:

sudo docker run -d -p 5000:5000 --restart always --name registry registry:2

Что бы докер на этом сервере мог пушить в регистр, нужно добавить опции для докер-демона.
В Ubuntu используется systemd поэтому опции задаются в *.conf файлах в /etc/systemd/system/docker.service.d см. https://docs.docker.com/config/daemon/systemd/

sudo mkdir -p /etc/systemd/system/docker.service.d
sudo su root
echo [Service] > /etc/systemd/system/docker.service.d/local_insecure.conf
echo Environment="DOCKER_OPTS=--insecure-registry localhost:5000" >> /etc/systemd/system/docker.service.d/local_insecure.conf
exit
service docker restart

здесь DOCKER_OPTS=--insecure-registry localhost:5000 указывает, что для доступа к этому регистру не нужен пароль.
теперь можно проверить регистр:

sudo docker pull ubuntu
sudo docker tag ubuntu localhost:5000/ubuntu
sudo docker push localhost:5000/ubuntu

и посмотреть на список образов docker images:

REPOSITORY              TAG                 IMAGE ID            CREATED             SIZE
localhost:5000/ubuntu   latest              549b9b86cb8d        3 weeks ago         64.2 MB

сразу видно ссылку на репозиторий.

Доступ к репозиторию по логину/паролю

Для доступа к регистру извне, по логину и паролю, потребуется настройка TLS, без которой
(см. Restricting access
и Use self-signed certificates)

Генерация ключей и сертификата

Создадим каталог и перейдём в него

mkdir registry && cd "$_"

здесь создадим каталог для сертификатов и другой для конфигов htpasswd mkdir certs auth.
Сгенерируем ключ

cd certs/
openssl genrsa 1024 > domain.key
chmod 400 domain.key

и используем его для генерации самоподписанного сертификата

openssl req -new -x509 -nodes -sha1 -days 365 -key domain.key -out domain.crt

ответим на вопросы, затем проверим (ls) созданы ли файлы domain.crt и domain.key.

Настройка TLS

Перейдём в каталог auth и сгенерируем файл htpasswd используя докер контейнер registry

cd ../auth/
docker run --rm --entrypoint htpasswd registry:2 -Bbn username password > htpasswd

последней командой, в контейнере registry запускается утилита htpasswd, ключ -Bbn
указывает, что запуск идет в пакетном режиме (b) т.е. логин/пароль (username/password)
передаются аргументами, для шифромания используется bcrypt (B) и результат выводится в stdout (n).
Вывод перенаправляется в файл htpasswd в текущем каталоге. См. htpasswd — Manage user files for basic authentication
Убедимся, что всё получилось cat htpasswd должен отобразить username:зашифрованный_пароль
Конфигурация завершена.

Тестовый запуск

Перед запуском нужно удалить/переименовать контейнер registry который был запущен при старте (что было настроено в предидущих шагах).

docker stop registry
docker rm registry

Теперь можно вернуться в каталог registry/ и из него запустить контейнер

docker run -d \
  --restart=always \
  --name registry \
  -v `pwd`/auth:/auth \
  -v `pwd`/certs:/certs \
  -v `pwd`/certs:/certs \
  -e REGISTRY_AUTH=htpasswd \
  -e REGISTRY_AUTH_HTPASSWD_REALM="Registry Realm" \
  -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
  -e REGISTRY_HTTP_ADDR=0.0.0.0:443 \
  -e REGISTRY_HTTP_TLS_CERTIFICATE=/certs/domain.crt \
  -e REGISTRY_HTTP_TLS_KEY=/certs/domain.key \
  -p 443:443 \
  registry:2

И наконец можно попытаться запушить в него, что нибудь:

docker pull busybox
docker tag busybox localhost:443/busybox
docker push localhost:443/busybox

появится сообщение вида:

The push refers to repository [localhost:443/busybox]
0314be9edf00: Preparing
no basic auth credentials

• нужно выполнить логин

docker login -u username https://localhost:443
Password:
Login Succeeded

и повторить пуш

docker push localhost:443/busybox

появится сообщение 0314be9edf00: Pushed что говорит об успешном пуше.

Доступ извне

До сего момента доступ к регистру выполнялся только с той же машины, на которой запущен докер.
Первое, что нужно для доступа извне — открытый 443 порт на хост-машине (через группу или фаерволл).
Второе — нужно сконфигурировать докер-демон на клиентской машине, что бы он использовал созданный сертификат.
Для этого скопируем сертификат в расшаренный каталог Vagrant

cp certs/domain.crt /vagrant/

Настройка клиента (машина с jenkins)

Завершим ssh сессию с машиной registry и зайдем на jenkins.
Первое, что нужно — добавить registry в hosts

sudo su root
echo '192.168.33.30 registry' >> /etc/hosts
ping registry

пинг должен пройти.

Теперь нужно и установить сертификат. Для этого нужно создать каталог

mkdir -p /etc/docker/certs.d/registry:443/

• здесь «registry» — домен регистра.
  Далее в этот каталог нужно поместить сертификат, файл нужно переименовать в ca.crt

cp /vagrant/domain.crt  /etc/docker/certs.d/registry\:443/ca.crt
exit

Выйти из под root и перейти в учетку jenkins sudo su jenkins
Что бы удостовериться, что настройка выполнена, нужно попытаться залогиниться в регистр

docker login -u username https://registry:443
Password:

• ввести пароль «password», который настроили в htpasswd. Должно быть выдано Login Succeeded,
  говорящее об успешном подключении к регистру. Можно повторить тест с контейнером busybox

docker pull busybox
docker tag busybox registry:443/busybox
docker push registry:443/busybox

появится сообщение о том, что пуш ссылается на репозиторий

The push refers to a repository [registry:443/busybox]
195be5f8be1d: Pushed

Links

Deploy a Docker Registry using self-signed certificates and htpasswd

(TODO) Настройка докер-демона для registry

Что бы при рестарте машины регистр становился доступен извне по логину/паролю, нужно передать в контейнер
переменные среды и ключи так, как он запускался в разделе «Тестовый запуск».
Если на шаге «Тестовый запуск» контейнер был удален и создан под тем же именем, то сохранит заданную конфигурацию. Но если он будет удален, придется выполнить docker run ... registry:2 заново.

Скрытие паролей в пайпах

Настройка Credentials

По многим причинам пароли не следует храить в jenkins-файле в открытом виде. Это не безопасно, и не удобно в поддержке.
Для управления используемыми аккаунтами в интерфейсе Jenkins существует отдельное конфигурационное меню.
Откроем http://localhost:18080/ и главной страницы пройдем в «Credentials» -> «System» -> «Global credentials (unrestricted)», в меню слева выберем «Add Credentials».
Заполним форму, Kind = «Username with Password», Scope = «Global». В поля Username и Password введем логин/пароль для доступа к registry (см. выше «Настройка TLS»).
В ID введем «registry_user» — это идентификатор который мы будем использовать в пайплайне и Description = «registry_user» (описание произвольного содержания). Сохранимся — «Ок».

Использование Credentials в пайплайне

Теперь нужно модифицировать пайплайн «jenkinsfiles\docker_build.jenkins», что бы он подключался к регистру используя учетные данные и пушил в него собранный образ.\

В начало пайплайна добавим шаг на котором будем выполнен docker login. В нём используем плагин withCredentials который связывает идентификаторы $USERNAME и $PASSWORD c логином и паролем указанными для registry_user.
Второй шаг (build) останется почти без изменений — в начало имени образа добавим имя репозитория.
Добавим третий шаг — push в наш репозиторий, команду: docker push registry:443/semaev/toolbox:latest.
После коммита изменений в git, должна произойти успешная сборка и пуш в удаленный репозиторий.\

Убедиться, что всё сработало можно например так

docker rmi registry:443/semaev/toolbox:latest
docker images

удаляем образ оставшийся после выполнения build, проверяем по списку.

docker push registry:443/semaev/toolbox:latest
docker images

в списке снова появится registry:443/semaev/toolbox:latest.

Дженкинс – Обзор

Jenkins – это программное обеспечение, обеспечивающее непрерывную интеграцию . Jenkins будет установлен на сервере, где будет происходить центральная сборка. Следующая блок-схема демонстрирует очень простой рабочий процесс работы Jenkins.

Наряду с Дженкинсом иногда можно увидеть ассоциацию Гудзона . Hudson – это очень популярный инструмент непрерывной интеграции на основе Java с открытым исходным кодом, разработанный Sun Microsystems, который впоследствии был приобретен Oracle. После приобретения Sun компанией Oracle была создана форк из исходного кода Hudson, что привело к появлению Jenkins.

Что такое непрерывная интеграция?

Непрерывная интеграция – это практика разработки, которая требует, чтобы разработчики регулярно интегрировали код в общий репозиторий. Эта концепция предназначалась для устранения проблемы обнаружения в дальнейшем проблем в жизненном цикле сборки. Непрерывная интеграция требует от разработчиков частых сборок. Обычная практика заключается в том, что всякий раз, когда происходит фиксация кода, сборка должна запускаться.

Системные Требования

JDK	JDK 1,5 или выше
объем памяти	2 ГБ ОЗУ (рекомендуется)
Дисковое пространство	Нет минимальных требований. Обратите внимание, что, поскольку все сборки будут храниться на машинах Jenkins, необходимо убедиться, что для хранения сборок доступно достаточно места на диске.
Версия операционной системы	Jenkins может быть установлен на Windows, Ubuntu / Debian, Red Hat / Fedora / CentOS, Mac OS X, openSUSE, FReeBSD, OpenBSD, Gentoo.
Контейнер Java	Файл WAR можно запустить в любом контейнере, который поддерживает Servlet 2.4 / JSP 2.0 или более позднюю версию (например, Tomcat 5).

Дженкинс – Установка

Скачать Дженкинс

Официальный сайт Дженкинса – Дженкинс . Если вы нажмете указанную ссылку, вы сможете получить домашнюю страницу официального сайта Jenkins, как показано ниже.

По умолчанию последняя версия и версия долгосрочной поддержки будут доступны для загрузки. Предыдущие выпуски также доступны для скачивания. Перейдите на вкладку «Долгосрочная поддержка» в разделе загрузки.

Нажмите на ссылку «Старая, но стабильная версия», чтобы загрузить файл войны Дженкинса.

Начиная Дженкинс

Откройте командную строку. В командной строке перейдите в каталог, где находится файл jenkins.war. Запустите следующую команду

D:\>Java –jar Jenkins.war

После запуска команды будут выполняться различные задачи, одной из которых является извлечение файла war, который выполняется встроенным веб-сервером winstone.

D:\>Java –jar Jenkins.war
Running from: D:\jenkins.war
Webroot: $user.home/ .jenkins
Sep 29, 2015 4:10:46 PM winstone.Logger logInternal
INFO: Beginning extraction from war file

Как только обработка завершится без существенных ошибок, в строке командной строки появится следующая строка.

INFO: Jenkins is fully up and running

Доступ к Дженкинс

После запуска Jenkins можно получить доступ к Jenkins по ссылке – http: // localhost: 8080.

Эта ссылка откроет панель управления Jenkins.

Jenkins – Настройка Tomcat

Следующие предварительные условия должны быть выполнены для установки Jenkins Tomcat.

Шаг 1. Проверка установки Java

Чтобы проверить установку Java, откройте консоль и выполните следующую команду Java.

Операционные системы	задача	команда
Windows	Открыть командную консоль	\> Java-версия
Linux	Открыть командный терминал	$ java – версия

Если Java правильно установлена ​​в вашей системе, вы должны получить один из следующих выводов, в зависимости от платформы, на которой вы работаете.

Операционные системы	Выход
Windows	Java версия “1.7.0_60” Среда выполнения Java (TM) SE (сборка 1.7.0_60-b19) 64-разрядная серверная виртуальная машина Java Hotspot (TM) (сборка 24.60-b09, смешанный режим)
Linux	Java-версия “1.7.0_25” Открытая среда выполнения JDK (rhel-2.3.10.4.el6_4-x86_64) Откройте виртуальную машину 64-разрядного сервера JDK (сборка 23.7-b01, смешанный режим)

Java версия “1.7.0_60”

Среда выполнения Java (TM) SE (сборка 1.7.0_60-b19)

64-разрядная серверная виртуальная машина Java Hotspot (TM) (сборка 24.60-b09, смешанный режим)

Java-версия “1.7.0_25”

Открытая среда выполнения JDK (rhel-2.3.10.4.el6_4-x86_64)

Откройте виртуальную машину 64-разрядного сервера JDK (сборка 23.7-b01, смешанный режим)

Мы предполагаем, что читатели этого учебного пособия установили Java 1.7.0_60 в своей системе, прежде чем приступить к этому учебному пособию.

Если у вас нет Java JDK, вы можете скачать его по ссылке Oracle

Шаг 2. Проверка установки Java

Установите переменную среды JAVA_HOME, чтобы она указывала на местоположение базовой директории, где установлена ​​Java на вашем компьютере. Например,

Операционные системы	Выход
Windows	Установите переменную среды JAVA_HOME в C: \ ProgramFiles \ java \ jdk1.7.0_60
Linux	экспорт JAVA_HOME = / usr / local / java-current

Добавьте полный путь расположения компилятора Java к системному пути.

Операционные системы	Выход
Windows	Добавить строку; C: \ Program Files \ Java \ jdk1.7.0_60 \ bin до конца системной переменной PATH.
Linux	экспорт PATH = $ PATH: $ JAVA_HOME / bin /

Проверьте команду java-version из командной строки, как описано выше.

Шаг 3: Загрузите Tomcat

Официальный сайт Tomcat – Tomcat . Если вы нажмете указанную ссылку, вы сможете получить домашнюю страницу официального сайта tomcat, как показано ниже.

Перейдите по ссылке https://tomcat.apache.org/download-70.cgi, чтобы получить загрузку для tomcat.

Перейдите в раздел «Двоичные распределения». Загрузите 32-битный zip-файл Windows.

Затем распакуйте содержимое загруженного zip-файла.

Шаг 4: Настройка Jenkins и Tomcat

Скопируйте файл Jenkis.war, который был загружен из предыдущего раздела, и скопируйте его в папку webapps в папке tomcat.

Теперь откройте командную строку. В командной строке перейдите в каталог, где находится папка tomcat7. Перейдите в каталог bin в этой папке и запустите файл start.bat.

E:\Apps\tomcat7\bin>startup.bat

Как только обработка завершится без существенных ошибок, в строке командной строки появится следующая строка.

INFO: Server startup in 1302 ms

Откройте браузер и перейдите по ссылке – http: // localhost: 8080 / jenkins . Дженкинс будет работать на кота.

Jenkins – Git Setup

В этом упражнении вы должны убедиться в наличии подключения к Интернету на компьютере, на котором установлен Jenkins. На панели инструментов Jenkins (домашний экран) выберите опцию Manage Jenkins с левой стороны.

На следующем экране выберите «Управление плагинами».

На следующем экране перейдите на вкладку Доступно. Эта вкладка предоставит список плагинов, которые доступны для скачивания. На вкладке «Фильтр» введите «Плагин Git»

Список будет затем отфильтрован. Отметьте опцию Git Plugin и нажмите кнопку «Установить без перезагрузки»

Затем начнется установка, и экран обновится, чтобы показать состояние загрузки.

После завершения всех установок перезапустите Jenkins, выполнив в браузере следующую команду. HTTP: // локальный: 8080 / Jenkins / перезагрузка

После перезапуска Jenkins Git будет доступен в качестве опции при настройке заданий. Чтобы проверить, нажмите New Item в опциях меню для Jenkins. Затем введите имя для работы, в следующем случае введенное имя будет «Демо». Выберите «Фристайл проект» в качестве типа элемента. Нажмите кнопку ОК.

На следующем экране, если вы перейдете в раздел «Управление исходным кодом», теперь вы увидите «Git» в качестве опции.

Jenkins – Maven Setup

Шаг 1: Загрузка и настройка Maven

Официальный сайт Maven – Apache Maven . Если вы нажмете указанную ссылку, вы сможете получить домашнюю страницу официального сайта maven, как показано ниже.

При просмотре сайта перейдите в раздел «Файлы» и загрузите ссылку на файл Binary.zip.

Как только файл загружен, распакуйте файлы в соответствующую папку приложения. Для этого файлы maven будут помещены в E: \ Apps \ apache-maven-3.3.3.

Шаг 2: Настройка Jenkins и Maven

На панели управления Jenkins (домашний экран) выберите «Управление Jenkins» в меню слева.

Затем нажмите «Настроить систему» ​​с правой стороны.

На экране настройки системы прокрутите вниз, пока не увидите раздел Maven, а затем нажмите кнопку «Добавить Maven».

Снимите флажок «Установить автоматически».

Добавьте любое имя для настройки и расположение MAVEN_HOME.

Затем нажмите кнопку «Сохранить» в конце экрана.

Теперь вы можете создать работу с опцией «Проект Maven». На панели инструментов Jenkins выберите параметр «Новый элемент».

Дженкинс – Конфигурация

Вы, вероятно, видели пару раз в предыдущих упражнениях, где нам приходилось настраивать параметры в Jenkins. Ниже показаны различные параметры конфигурации в Jenkins.

Таким образом, можно получить различные параметры конфигурации для Jenkins, щелкнув параметр «Управление Jenkins» в левой части меню.

Затем вам будет представлен следующий экран –

Нажмите на Настроить систему. Ниже обсуждаются некоторые параметры конфигурации Jenkins, которые можно выполнить.

Домашний каталог Дженкинс

Дженкинсу нужно немного дискового пространства для сборки и хранения архивов. Проверить это местоположение можно с экрана конфигурации Jenkins. По умолчанию это значение равно ~ / .jenkins, и это местоположение будет изначально сохранено в вашем профиле пользователя. В правильной среде вам нужно изменить это местоположение на подходящее место для хранения всех соответствующих сборок и архивов. Один раз можете сделать это следующими способами

• Установите переменную среды “JENKINS_HOME” в новый домашний каталог перед запуском контейнера сервлета.

• Установите системное свойство “JENKINS_HOME” для контейнера сервлета.

• Установите запись среды JNDI “JENKINS_HOME” в новый каталог.

Установите переменную среды “JENKINS_HOME” в новый домашний каталог перед запуском контейнера сервлета.

Установите системное свойство “JENKINS_HOME” для контейнера сервлета.

Установите запись среды JNDI “JENKINS_HOME” в новый каталог.

В следующем примере будет использоваться первая опция установки переменной среды «JENKINS_HOME».

Сначала создайте новую папку E: \ Apps \ Jenkins. Скопируйте все содержимое из существующего ~ / .jenkins в этот новый каталог.

Установите переменную среды JENKINS_HOME, чтобы она указывала на местоположение базовой директории, где установлена ​​Java на вашем компьютере. Например,

Операционные системы	Выход
Windows	Установите переменную среды JENKINS_HOME, чтобы указать, в каком месте вы находитесь. В качестве примера вы можете установить его в E: \ Apps \ Jenkins
Linux	export JENKINS_HOME = / usr / local / Jenkins или желаемое место.

На приборной панели Jenkins выберите «Управление Jenkins» в левом меню. Затем нажмите «Настроить систему» ​​с правой стороны.

В домашнем каталоге вы увидите новый настроенный каталог.

# исполнителей

Это относится к общему количеству одновременных выполнений заданий, которые могут выполняться на компьютере Jenkins. Это может быть изменено в зависимости от требований. Иногда рекомендуется оставить это число таким же, как и количество процессоров на машинах, для повышения производительности.

Переменные среды

Это используется для добавления пользовательских переменных среды, которые будут применяться ко всем заданиям. Это пары ключ-значение, к которым можно обращаться и использовать в сборках, где это необходимо.

Дженкинс URL

По умолчанию URL-адрес Jenkins указывает на localhost. Если у вас есть настройка доменного имени для вашего компьютера, установите это имя домена, иначе перезапишите localhost с IP-адресом компьютера. Это поможет в настройке ведомых устройств и при отправке ссылок с использованием электронной почты, поскольку вы можете напрямую обращаться к URL-адресу Jenkins с помощью переменной среды JENKINS_URL, к которой можно получить доступ как $ {JENKINS_URL}.

Уведомление по электронной почте

В области уведомлений по электронной почте вы можете настроить параметры SMTP для отправки электронных писем. Это необходимо для подключения Jenkins к почтовому серверу SMTP и отправки электронных писем в список получателей.

Дженкинс – Управление

Чтобы управлять Jenkins, выберите опцию «Manage Jenkins» в левой части меню.

Таким образом, можно получить различные параметры конфигурации для Jenkins, щелкнув параметр «Управление Jenkins» в левой части меню.

Затем вам будет представлен следующий экран –

Некоторые из вариантов управления следующие:

Настроить систему

Здесь можно управлять путями к различным инструментам, используемым в сборках, таким как JDK, версии Ant и Maven, а также параметры безопасности, серверы электронной почты и другие сведения о конфигурации всей системы. Когда плагины установлены. Jenkins добавит необходимые поля конфигурации динамически после установки плагинов.

Перезагрузить конфигурацию с диска

Jenkins хранит всю свою информацию о конфигурации системы и сборки в виде XML-файлов, которые хранятся в домашнем каталоге Jenkins. Здесь также хранится вся история сборки. Если вы переносите задания сборки из одного экземпляра Jenkins в другой или архивируете старые задания сборки, вам необходимо добавить или удалить соответствующие каталоги заданий сборки в каталог сборки Jenkins. Вам не нужно переводить Jenkins в автономный режим, чтобы сделать это – вы можете просто использовать опцию «Перезагрузить конфигурацию с диска», чтобы перезагрузить систему Jenkins и напрямую создать конфигурации заданий.

Управление плагином

Здесь можно установить самые разнообразные сторонние плагины прямо от различных инструментов управления исходным кодом, таких как Git, Mercurial или ClearCase, до отчетов о качестве кода и показателях покрытия кода. Плагины можно устанавливать, обновлять и удалять с помощью экрана «Управление плагинами».

Системная информация

На этом экране отображается список всех текущих системных свойств Java и системных переменных среды. Здесь можно точно проверить, в какой версии Java Jenkins работает, под каким пользователем он работает, и так далее.

На следующем снимке экрана показана некоторая информация о значении имени, доступная в этом разделе.

Системный журнал

Экран системного журнала – это удобный способ просмотра файлов журнала Jenkins в режиме реального времени. Опять же, основное использование этого экрана для устранения неполадок.

Загрузить статистику

На этих страницах отображаются графические данные о том, насколько занят экземпляр Jenkins, с точки зрения количества одновременных сборок и длины очереди сборки, что дает представление о том, как долго ваши сборки должны ждать перед выполнением. Эта статистика может дать хорошее представление о том, требуются ли дополнительные ресурсы или дополнительные узлы сборки с точки зрения инфраструктуры.

Консоль скриптов

Этот экран позволяет запускать скрипты Groovy на сервере. Это полезно для расширенного поиска и устранения неисправностей, поскольку требует глубоких знаний внутренней архитектуры Jenkins.

Управление узлами

Дженкинс способен обрабатывать параллельные и распределенные сборки. На этом экране вы можете настроить, сколько сборок вы хотите. Jenkins запускается одновременно, и, если вы используете распределенные сборки, настройте узлы сборки. Узел сборки – это еще одна машина, которую Jenkins может использовать для выполнения своих сборок.

Подготовьтесь к выключению

Если необходимо закрыть Jenkins или сервер, на котором работает Jenkins, лучше не делать этого при выполнении сборки. Чтобы аккуратно завершить работу Jenkins, вы можете использовать ссылку «Подготовка к выключению», которая предотвращает запуск любых новых сборок. В конце концов, когда все текущие сборки будут завершены, можно будет аккуратно завершить работу Jenkins.

Дженкинс – Настройка сборки

Для этого упражнения мы создадим задание в Jenkins, которое подберет простое приложение HelloWorld, соберет и запустит Java-программу.

Шаг 1 – Перейдите на панель инструментов Jenkins и нажмите на новый элемент

Шаг 2 – На следующем экране введите имя элемента, в данном случае мы назвали его Helloworld. Выберите «Фристайл проект»

Шаг 3 – появится следующий экран, в котором вы можете указать детали работы.

Шаг 4 – Нам нужно указать расположение файлов, которые нужно собрать. В этом примере мы будем предполагать, что был настроен локальный репозиторий git (E: \ Program), который содержит файл «HelloWorld.java». Поэтому прокрутите вниз и нажмите на опцию Git и введите URL-адрес локального репозитория git.

Примечание. Если вы размещаете репозиторий на Github, вы также можете ввести здесь URL этого репозитория. В дополнение к этому вам нужно будет нажать кнопку «Добавить» для ввода учетных данных, чтобы добавить имя пользователя и пароль в репозиторий github, чтобы код можно было получить из удаленного репозитория.

Шаг 5 – Теперь перейдите в раздел «Сборка» и нажмите «Добавить шаг сборки» → «Выполнить пакетную команду Windows».

Шаг 6 – В окне команд введите следующие команды и нажмите кнопку Сохранить.

Javac HelloWorld.java
Java HelloWorld

Шаг 7 – После сохранения вы можете нажать на опцию Build Now, чтобы увидеть, успешно ли вы определили задание.

Шаг 8 – Как только сборка запланирована, она запустится. Следующий раздел истории сборки показывает, что сборка выполняется.

Шаг 9 – Как только сборка завершена, статус сборки покажет, была ли сборка успешной или нет. В нашем случае следующая сборка была выполнена успешно. Нажмите на # 1 в истории сборки, чтобы открыть детали сборки.

Шаг 10 – Нажмите на ссылку Console Output, чтобы увидеть детали сборки

Помимо описанных выше шагов, существует очень много способов создания задания сборки, доступно множество вариантов, что делает Jenkins таким фантастическим инструментом непрерывного развертывания.

Дженкинс – Модульное тестирование

Jenkins предоставляет готовую функциональность для Junit и предоставляет множество плагинов для модульного тестирования для других технологий, например MSTest для модульных тестов .Net. Если вы перейдете по ссылке https://wiki.jenkins-ci.org/display/JENKINS/xUnit+Plugin, она предоставит список доступных плагинов для модульного тестирования.

Пример теста Junit в Дженкинсе

В следующем примере рассмотрим

• Простой класс HelloWorldTest, основанный на Junit.
• Ant как инструмент для сборки внутри Jenkins для соответствующей сборки класса.

Шаг 1 – Перейдите на панель инструментов Jenkins и нажмите на существующий проект HelloWorld и выберите опцию Configure.

Шаг 2 – Перейдите в раздел, чтобы добавить шаг сборки и выберите опцию Invoke Ant.

Шаг 3 – Нажмите на кнопку «Дополнительно».

Шаг 4 – В разделе файла сборки введите местоположение файла build.xml.

Шаг 5 – Затем нажмите опцию Добавить опцию после сборки и выберите опцию «Опубликовать отчет о результатах теста Junit»

Шаг 6 – В XML-файлах отчетов о тестировании введите местоположение, как показано ниже. Убедитесь, что отчеты – это папка, созданная в рабочей области проекта HelloWorld. «* .Xml» в основном говорит Дженкинсу забрать результирующие XML-файлы, которые создаются при выполнении тестовых случаев Junit. Эти XML-файлы, которые затем преобразуются в отчеты, которые можно просмотреть позже.

После этого нажмите кнопку Сохранить в конце.

Шаг 7 – После сохранения вы можете нажать на опцию Build Now.

Как только сборка будет завершена, статус сборки покажет, была ли сборка успешной или нет. В выходных данных Build вы теперь заметите дополнительный раздел под названием Test Result. В нашем случае мы ввели отрицательный контрольный пример, чтобы результат не удался, просто в качестве примера.

Можно перейти к выходу консоли, чтобы увидеть дополнительную информацию. Но что более интересно, если вы нажмете на «Результат теста», вы увидите развернутые результаты теста.

Дженкинс – Автоматизированное тестирование

Одним из основных принципов непрерывной интеграции является то, что сборка должна быть проверяемой. Вы должны быть в состоянии объективно определить, готова ли конкретная сборка перейти к следующему этапу процесса сборки, и наиболее удобный способ сделать это – использовать автоматизированные тесты. Без надлежащего автоматического тестирования вы обнаружите, что вам нужно сохранить множество артефактов сборки и проверить их вручную, что вряд ли соответствует духу непрерывной интеграции. В следующем примере показано, как использовать Selenium для запуска автоматических веб-тестов.

Шаг 1 – Перейти к управлению плагинами.

Шаг 2 – Найдите плагин Hudson Selenium и выберите установку. Перезапустите экземпляр Jenkins.

Шаг 3 – Перейти к настройке системы.

Шаг 4 – Сконфигурируйте jar сервера selenium и нажмите кнопку Сохранить.

Примечание . Файл селеновой банки можно загрузить с сайта SeleniumHQ.

Нажмите на загрузку для автономного сервера Selenium.

Шаг 5 – Вернитесь на свою панель инструментов и нажмите на опцию Configure для проекта HelloWorld.

Шаг 6 – Нажмите «Добавить сборку» и выберите опцию «SeleniumHQ htmlSuite Run»

Шаг 7 – Добавьте необходимые детали для теста на селен. Здесь suiteFile – это TestSuite, созданный с помощью IDE Selenium. Нажмите Сохранить и выполнить сборку. Теперь посткомпиляция запустит драйвер селена и выполнит тест html.

Дженкинс – Уведомление

Jenkins поставляется с готовой возможностью добавить уведомление по электронной почте для проекта сборки.

Шаг 1 – Настройка SMTP-сервера. Перейти к Управлению Jenkins → Настроить систему. Перейдите в раздел уведомлений по электронной почте и введите требуемый SMTP-сервер и сведения о суффиксе электронной почты пользователя.

Шаг 2. Настройка получателей в проекте Jenkins. При настройке любого проекта сборки Jenkins в самом конце появляется возможность добавить получателей, которые будут получать уведомления по электронной почте о нестабильных или поврежденных сборках. Затем нажмите на кнопку Сохранить.

Помимо стандартного, на рынке есть также плагин уведомлений. Примером является плагин уведомлений от Tikal Knowledge, который позволяет отправлять уведомления о статусе работы в форматах JSON и XML. Этот плагин позволяет настраивать конечные точки, как показано ниже.

Вот детали каждого варианта –

• «Формат» – это формат содержимого уведомления, который может быть либо JSON, либо XML.

• «Протокол» – протокол, используемый для отправки уведомлений, HTTP, TCP или UDP.

• «Событие» – события задания, которые вызывают уведомления: задание запущено, задание завершено, задание завершено или все события (опция по умолчанию).

• «URL» – URL для отправки уведомлений. Он принимает форму « http: // host » для протокола HTTP и "host:port" для протоколов TCP и UDP.

• «Тайм-аут» – Тайм-аут в миллисекундах для отправки запроса уведомления, по умолчанию 30 секунд.

«Формат» – это формат содержимого уведомления, который может быть либо JSON, либо XML.

«Протокол» – протокол, используемый для отправки уведомлений, HTTP, TCP или UDP.

«Событие» – события задания, которые вызывают уведомления: задание запущено, задание завершено, задание завершено или все события (опция по умолчанию).

«URL» – URL для отправки уведомлений. Он принимает форму « http: // host » для протокола HTTP и "host:port" для протоколов TCP и UDP.

«Тайм-аут» – Тайм-аут в миллисекундах для отправки запроса уведомления, по умолчанию 30 секунд.

Дженкинс – Отчетность

Как показано в предыдущем разделе, существует множество плагинов для отчетов, самым простым из которых являются отчеты, доступные для тестов jUnit.

В действии Post-build для любого задания вы можете определить отчеты, которые будут созданы. После завершения сборок опция «Результаты теста» будет доступна для дальнейшей детализации.

Дженкинс – Анализ кода

Дженкинс имеет множество плагинов для анализа кода. Различные плагины можно найти по адресу https://wiki.jenkins-ci.org/display/JENKINS/Static+Code+Analysis+Plugins.

Этот плагин предоставляет утилиты для плагинов статического анализа кода. Jenkins может анализировать файл результатов с помощью различных инструментов анализа кода, таких как CheckStyle, FindBugs, PMD и т. Д. Для каждого соответствующего инструмента анализа кода необходимо установить плагин в Jenkins.

Кроме того, доступен дополнительный плагин Static Analysis Collector, который объединяет отдельные результаты этих плагинов в единый график и представление тренда.

Плагины могут предоставить такую ​​информацию, как

• Общее количество предупреждений в работе
• Показ новых и исправленных предупреждений о сборке
• Отчеты о тенденциях, показывающие количество предупреждений на одну сборку
• Обзор найденных предупреждений для модуля, пакета, категории или типа
• Подробные отчеты о найденных предупреждениях, необязательно отфильтрованные по серьезности (или новые и исправленные)

Jenkins – Распределенные сборки

Иногда требуется много сборочных машин, если есть случаи, когда есть более крупные и тяжелые проекты, которые собираются на регулярной основе. И запуск всех этих сборок на центральной машине может оказаться не лучшим вариантом. В таком сценарии можно настроить другие машины Jenkins как подчиненные машины для снятия нагрузки с главного сервера Jenkins.

Иногда вам также может понадобиться несколько разных сред для тестирования ваших сборок. В этом случае использование подчиненного устройства для представления каждой из ваших необходимых сред является почти обязательным.

Подчиненный – это компьютер, который настроен на разгрузку проектов сборки с главного устройства, и после настройки это распределение задач выполняется довольно автоматически. Точное поведение делегирования зависит от конфигурации каждого проекта; некоторые проекты могут выбрать «придерживаться» определенной машины для сборки, в то время как другие могут свободно перемещаться между рабами.

Поскольку каждое ведомое устройство запускает отдельную программу, называемую «ведомым агентом», нет необходимости устанавливать полный Jenkins (пакет или скомпилированные двоичные файлы) на подчиненном устройстве. Существуют различные способы запуска подчиненных агентов, но, в конце концов, ведомому агенту и главному устройству Jenkins необходимо установить двунаправленный канал связи (например, сокет TCP / IP.) Для работы.

Чтобы настроить подчиненные узлы / узлы в Jenkins, выполните следующие действия.

Шаг 1 – Перейдите в раздел «Управление Jenkins» и прокрутите вниз до раздела «Управление узлами».

Шаг 2 – Нажмите на новый узел

Шаг 3 – Дайте имя для узла, выберите опцию Dumb slave и нажмите Ok.

Шаг 4 – Введите сведения о узле подчиненного компьютера. В приведенном ниже примере мы рассматриваем подчиненную машину как машину с Windows, поэтому в качестве метода запуска была выбрана опция «Разрешить Jenkins управлять этим подчиненным Windows как службой Windows». Нам также необходимо добавить необходимые данные о подчиненном узле, такие как имя узла и учетные данные для входа в систему для узла. Нажмите кнопку Сохранить. Метки, для которых имя вводится как «New_Slave», – это то, что можно использовать для настройки заданий на использование этого подчиненного компьютера.

После того как вышеуказанные шаги будут выполнены, новый узловой компьютер будет первоначально находиться в автономном состоянии, но перейдет в оперативный режим, если все настройки на предыдущем экране были введены правильно. При необходимости можно в любое время сделать подчиненную машину узла отключенной.

Дженкинс – Автоматизированное развертывание

Существует множество доступных плагинов, которые можно использовать для передачи файлов сборки после успешной сборки на соответствующее приложение / веб-сервер. Например, «Плагин для развертывания в контейнере». Чтобы использовать это, следуйте инструкциям ниже.

Шаг 1 – Перейдите в Управление Дженкинс → Управление плагинами. Перейдите в раздел «Доступные» и найдите плагин «Плагин для развертывания в контейнер» и установите плагин. Перезагрузите сервер Jenkins.

Этот плагин берет файл war / ear и развертывает его на работающем удаленном сервере приложений в конце сборки.

Tomcat 4.x / 5.x / 6.x / 7.x

JBoss 3.x / 4.x

Glassfish 2.x / 3.x

Шаг 2 – Перейдите к вашему проекту Build и выберите опцию Configure. Выберите опцию «Развернуть войну / ухо в контейнере»

Шаг 3 – В разделе «Развернуть war / ear to container» введите необходимые данные о сервере, на котором необходимо развернуть файлы, и нажмите кнопку «Сохранить». Эти шаги теперь обеспечат развертывание необходимых файлов в необходимом контейнере после успешной сборки.

Дженкинс – метрики и тенденции

В Jenkins есть различные плагины для демонстрации метрик для сборок, которые выполняются в течение определенного периода времени. Эти метрики полезны для понимания ваших сборок и того, как часто они терпят неудачу / проходят со временем. В качестве примера давайте рассмотрим плагин Build History Metrics.

Этот плагин рассчитывает следующие показатели для всех сборок после установки

• Среднее время до отказа (MTTF)
• Среднее время до восстановления (MTTR)
• Стандартное отклонение времени сборки

Шаг 1 – Перейдите на панель инструментов Jenkins и нажмите Manage Jenkins.

Шаг 2 – Перейдите к опции «Управление плагинами».

Шаг 3 – Перейдите на вкладку Доступно и найдите плагин «Плагин Build History Metrics» и выберите «Установить без перезапуска».

Шаг 4 – Следующий экран появляется, чтобы подтвердить успешную установку плагина. Перезапустите экземпляр Jenkins.

Когда вы перейдете на страницу «Работа», вы увидите таблицу с рассчитанными показателями. Метрики показаны за последние 7 дней, последние 30 дней и все время.

Чтобы увидеть общие тенденции в Jenkins, существуют плагины для сбора информации из сборок и Jenkins и отображения их в графическом формате. Одним из примеров такого плагина является плагин Hudson global-build-stats. Итак, давайте пройдемся по шагам для этого.

Шаг 1 – Перейдите на панель инструментов Jenkins и нажмите Manage Jenkins.

Шаг 2 – Перейдите к опции «Управление плагинами»

Шаг 3 – Перейдите на вкладку «Доступные» и найдите плагин «Hudson global-build-stats plugin» и выберите «установить без перезапуска».

Шаг 4 – Следующий экран появляется, чтобы подтвердить успешную установку плагина. Перезапустите экземпляр Jenkins.

Чтобы увидеть глобальную статистику, выполните шаги с 5 по 8.

Шаг 5 – Перейдите на панель инструментов Jenkins и нажмите Manage Jenkins. На экране «Управление Jenkins» прокрутите вниз, и теперь вы увидите опцию «Global Build Stats». Нажмите на эту ссылку.

Шаг 6 – Нажмите на кнопку «Инициализировать статистику». Что он делает, так это собирает все существующие записи для сборок, которые уже были выполнены, и диаграммы могут быть созданы на основе этих результатов.

Шаг 7 – После того, как данные были инициализированы, пришло время создать новую диаграмму. Нажмите на ссылку «Создать новый график».

Шаг 8 – Появится всплывающее окно для ввода соответствующей информации для новых деталей диаграммы. Введите следующую обязательную информацию

• Заголовок – Любая информация заголовка, для этого примера дана как «Демо»
• Ширина диаграммы – 800
• Высота диаграммы – 600
• Шкала времени графика – Ежедневно
• Продолжительность графика – 30 дней

Остальная информация может оставаться как есть. Как только информация введена, нажмите «Создать новый график».

Теперь вы увидите график, который отображает тренды сборок с течением времени.

Если вы щелкнете по любому из разделов диаграммы, вы получите подробную информацию о задании и его сборках.

Jenkins – Обслуживание сервера

Ниже приведены некоторые из основных действий, которые вы будете выполнять, некоторые из которых являются лучшими практиками по обслуживанию сервера Jenkins.

Параметры URL

Следующие команды при добавлении к URL-адресу экземпляра Jenkins будут выполнять соответствующие действия с экземпляром Jenkins.

http: // localhost: 8080 / jenkins / exit – отключение jenkins

http: // localhost: 8080 / jenkins / restart – перезапустить jenkins

http: // localhost: 8080 / jenkins / reload – перезагрузить конфигурацию

Резервное копирование Jenkins Home

Домашний каталог Jenkins – это не что иное, как место на вашем диске, где Jenkins хранит всю информацию для заданий, сборок и т. Д. Расположение вашего домашнего каталога можно увидеть, нажав «Управление Jenkins» → «Настроить систему».

Настройте Jenkins на раздел, в котором больше всего свободного дискового пространства. Поскольку Jenkins будет получать исходный код для различных заданий, определенных для выполнения непрерывных сборок, всегда проверяйте, что Jenkins настроен на диске, на котором достаточно места на жестком диске. Если на жестком диске не хватает места, все сборки на экземпляре Jenkins начнут давать сбой.

Другим лучшим методом является написание заданий cron или задач обслуживания, которые могут выполнять операции очистки, чтобы избежать переполнения диска, на котором настроен Jenkins.

Дженкинс – непрерывное развертывание

Jenkins обеспечивает хорошую поддержку для обеспечения непрерывного развертывания и доставки. Если вы посмотрите на процесс разработки программного обеспечения через развертывание, он будет таким, как показано ниже.

Основная часть непрерывного развертывания состоит в том, чтобы обеспечить автоматизацию всего процесса, который показан выше. Jenkins достигает всего этого с помощью различных плагинов, одним из которых является плагин «Развертывание в контейнер», который был замечен в предыдущих уроках.

Доступны плагины, которые могут фактически дать вам графическое представление процесса непрерывного развертывания. Но сначала давайте создадим еще один проект в Jenkins, чтобы мы лучше видели, как это работает.

Давайте создадим простой проект, который эмулирует этап QA и выполняет тест приложения Helloworld.

Шаг 1 – Перейдите к приборной панели Дженкинса и нажмите «Новый предмет». Выберите «Фристайл проект» и введите название проекта как «QA». Нажмите на кнопку ОК, чтобы создать проект.

Шаг 2. В этом примере мы сохраняем простоту и просто используем этот проект для выполнения тестовой программы для приложения Helloworld.

Итак, наш проект QA сейчас настроен. Вы можете сделать сборку, чтобы увидеть, правильно ли она собирается.

Шаг 3 – Теперь перейдите к вашему проекту Helloworld и нажмите на опцию Configure

Шаг 4 – В конфигурации проекта выберите «Добавить действие после сборки» и выберите «Построить другие проекты»

Шаг 5 – В разделе «Проект для сборки» введите QA в качестве имени проекта для сборки. Вы можете оставить параметр по умолчанию «Триггер, только если сборка стабильна». Нажмите на кнопку Сохранить.

Шаг 6 – Создайте проект Helloworld. Теперь, если вы увидите выходные данные консоли, вы также увидите, что после успешной сборки проекта Helloworld также будет происходить сборка проекта QA.

Шаг 7 – Позвольте теперь установить плагин доставки конвейера. Перейдите в Управление Дженкинс → Управление плагином. На доступной вкладке найдите «Плагин конвейера доставки». Нажмите «Установить без перезагрузки». После этого перезапустите экземпляр Jenkins.

Шаг 8 – Чтобы увидеть конвейер доставки в действии, на панели управления Jenkins нажмите значок + на вкладке рядом с вкладкой «Все».

Шаг 9 – Введите любое имя для имени представления и выберите опцию «Представление конвейера доставки».

Шаг 10 – На следующем экране вы можете оставить параметры по умолчанию. Можно изменить следующие настройки –

• Убедитесь, что опция «Показать результаты статического анализа» отмечена.
• Убедитесь, что опция «Показать общее время сборки» отмечена.
• Для начальной работы – введите проект Helloworld в качестве первой работы, которую следует построить.
• Введите любое имя для конвейера
• Нажмите кнопку ОК.

Теперь вы увидите великолепный вид всего конвейера доставки и сможете увидеть состояние каждого проекта во всем конвейере.

Другой известный плагин – плагин сборки конвейера . Давайте посмотрим на это.

Шаг 1 – Перейдите в Управление Дженкинс → Управление плагином. На доступной вкладке найдите «Построить плагин конвейера». Нажмите «Установить без перезагрузки». После этого перезапустите экземпляр Jenkins.

Шаг 2 – Чтобы увидеть конвейер сборки в действии, на панели управления Jenkins нажмите значок + на вкладке рядом с вкладкой «Все».

Шаг 3 – Введите любое имя для имени представления и выберите опцию «Построить представление конвейера».

Шаг 4 – Примите настройки по умолчанию, просто в выбранном начальном задании убедитесь, что вы ввели имя проекта Helloworld. Нажмите на кнопку ОК.

Теперь вы увидите великолепный вид всего конвейера доставки и сможете увидеть состояние каждого проекта во всем конвейере.

Jenkins – Управление плагинами

Чтобы получить список всех плагинов, доступных в Jenkins, можно перейти по ссылке – https://wiki.jenkins-ci.org/display/JENKINS/Plugins

Мы уже видели много примеров установки плагинов, давайте посмотрим на некоторые другие задачи по обслуживанию в отношении плагинов

Удаление плагинов

Чтобы удалить плагин, выберите «Управление Jenkins» → «Управление плагинами». Нажмите на установленную вкладку. Некоторые из плагинов будут иметь опцию удаления. Вы можете нажать эти кнопки, чтобы удалить плагины. Обязательно перезапустите экземпляр Jenkins после удаления.

Установка другой версии плагина

Иногда может потребоваться установить более старую версию плагина, в этом случае вы можете скачать плагин со страницы соответствующего плагина на веб-сайте Jenkins. Затем вы можете использовать опцию Загрузить, чтобы загрузить плагин вручную.

Дженкинс – Безопасность

В Jenkins у вас есть возможность настроить пользователей и их соответствующие разрешения на экземпляре Jenkins. По умолчанию вы не захотите, чтобы все могли определять задания или другие административные задачи в Jenkins. Таким образом, у Дженкинса есть возможность иметь конфигурацию безопасности на месте.

Чтобы настроить безопасность в Jenkins, выполните следующие действия.

Шаг 1 – Нажмите «Управление Jenkins» и выберите «Настроить глобальную безопасность».

Шаг 2 – Нажмите на опцию «Включить безопасность». В качестве примера, давайте предположим, что мы хотим, чтобы Jenkins поддерживал свою собственную базу данных пользователей, поэтому в области безопасности выберите вариант «собственная база данных пользователей Jenkins».

По умолчанию вы хотите, чтобы центральный администратор определял пользователей в системе, поэтому убедитесь, что опция «Разрешить пользователям регистрироваться» не выбрана. Вы можете оставить все как есть и нажать кнопку Сохранить.

Шаг 3 – Вам будет предложено добавить вашего первого пользователя. В качестве примера, мы настраиваем администраторов для системы.

Шаг 4 – Настало время настроить ваших пользователей в системе. Теперь, когда вы перейдете к управлению Дженкинс и прокрутите вниз, вы увидите опцию «Управление пользователями». Нажмите эту опцию.

Шаг 5 – Так же, как вы определили своего администратора, начните создавать других пользователей для системы. В качестве примера, мы просто создаем другого пользователя с именем «пользователь».

Шаг 6 – Теперь пришло время настроить ваши полномочия, в основном у кого есть доступ к чему. Перейдите в раздел «Управление Jenkins» → «Настроить глобальную безопасность».

Теперь в разделе «Авторизация» нажмите «Безопасность на основе матрицы».

Шаг 7 – Если вы не видите пользователя в списке групп пользователей, введите имя пользователя и добавьте его в список. Затем дайте соответствующие разрешения пользователю.

Нажмите на кнопку Сохранить, как только вы определили соответствующие полномочия.

Ваша безопасность Jenkins теперь настроена.

Примечание. Для проверки подлинности Windows AD необходимо добавить плагин Active Directory для Jenkins.

Jenkins – Плагин резервного копирования

Jenkins имеет плагин для резервного копирования, который может использоваться для резервного копирования критических параметров конфигурации, связанных с Jenkins. Следуйте приведенным ниже инструкциям, чтобы создать резервную копию.

Шаг 1 – Нажмите «Управление Jenkins» и выберите «Управление плагинами».

Шаг 2 – На доступной вкладке найдите «Плагин резервного копирования». Нажмите «Установить без перезагрузки». После этого перезапустите экземпляр Jenkins.

Шаг 3 – Теперь, когда вы перейдете в Управление Jenkins и прокрутите вниз, вы увидите «Диспетчер резервного копирования» в качестве опции. Нажмите на эту опцию.

Шаг 4 – Нажмите на настройку.

Шаг 5 – Здесь основным полем для определения является каталог для вашей резервной копии. Убедитесь, что он находится на другом диске, отличном от диска, на котором настроен ваш экземпляр Jenkins. Нажмите на кнопку Сохранить.

Шаг 6 – Нажмите «Backup Hudson configuration» на экране диспетчера резервного копирования, чтобы начать резервное копирование.

На следующем экране будет показано состояние резервной копии

Чтобы восстановить резервную копию, перейдите на экран диспетчера резервных копий, нажмите «Восстановить конфигурацию Hudson».

Появится список резервных копий, нажмите на соответствующую, чтобы нажать Launch Restore, чтобы начать восстановление резервной копии.

Дженкинс – дистанционное тестирование

Веб-тесты, такие как тесты селена, можно запускать на удаленных подчиненных компьютерах с помощью установки главного подчиненного и плагина селена. Следующие шаги показывают, как запускать удаленные тесты с использованием этой конфигурации.

Шаг 1 – Убедитесь, что ваша конфигурация master-slave установлена. Зайдите на ваш главный сервер Jenkins. Перейдите в Управление Дженкинс → Управление узлами.

В нашем списке узлов метка DXBMEM30 является подчиненной машиной. В этом примере и главная, и подчиненная машины являются машинами Windows.

Шаг 2 – Нажмите на настройку для ведомой машины DXBMEM30.

Шаг 3 – Убедитесь, что метод запуска установлен как «Запуск подчиненных агентов через Java Web Start»

Шаг 4 – Теперь перейдите на свой подчиненный компьютер и оттуда откройте экземпляр браузера для своего главного экземпляра Jenkins. Затем перейдите в Управление Дженкинс → Управление узлами. Перейдите к DXBMEM30 и нажмите на

Шаг 5 – Нажмите на экземпляр DXBMEM30.

Шаг 6 – Прокрутите вниз, и вы увидите опцию Launch, которая является опцией Start ‘Java Web Start’

Шаг 7 – Вам будет представлено предупреждение безопасности. Установите флажок «Принять» и нажмите «Выполнить».

Теперь вы увидите окно подчиненного Дженкинса, открытое и теперь подключенное.

Шаг 8 – Настройка ваших тестов для работы на ведомом устройстве. Здесь вы должны убедиться, что создаваемое задание предназначено специально для запуска только тестов селена.

В конфигурации задания убедитесь, что выбран параметр «Ограничить, где можно запустить этот проект», и в выражении «Метка» введите имя подчиненного узла.

Шаг 9 – Убедитесь, что селеновая часть вашей работы настроена. Вы должны убедиться, что файл Sample.html и файл selenium-server.jar также присутствуют на подчиненном компьютере.

После того, как вы выполнили все вышеперечисленные шаги и нажали на Build, этот проект запустит тест Selenium на подчиненном компьютере, как и ожидалось.

Изучите, как использовать Jenkins для автоматизации тестирования ПО, экономя время и повышая качество разработки!

Jenkins — это популярный инструмент для автоматизации процессов разработки и тестирования ПО. В данной статье мы рассмотрим основные аспекты использования Jenkins для проведения тестирования.

Что такое Jenkins и зачем он нужен?

Jenkins — это open-source инструмент, который предоставляет возможность автоматизировать различные этапы разработки и тестирования программного обеспечения. Он поддерживает множество плагинов и интеграций, что позволяет упростить процесс тестирования и ускорить его.

Установка и настройка Jenkins

Для начала работы с Jenkins необходимо установить его на свою машину или сервер. Официальный сайт предоставляет инструкции по установке для различных операционных систем: https://www.jenkins.io/download/.

После установки и первоначальной настройки Jenkins, можно приступать к созданию и конфигурации проекта.

Создание и настройка проекта

1. Создайте новый проект в Jenkins, выбрав «New Item» в меню.
2. Введите имя проекта и выберите тип проекта (например, «Freestyle project»).
3. На странице настроек проекта выполните следующие действия:

• Укажите репозиторий с исходным кодом вашего проекта.
• Настройте триггеры сборки (например, по коммиту в репозиторий).
• Добавьте шаги сборки, необходимые для компиляции и сборки вашего проекта.
• Добавьте шаги тестирования, в которых будут запускаться тесты и генерироваться отчеты.

Интеграция с системами тестирования

Jenkins поддерживает интеграцию с различными системами тестирования, такими как JUnit, TestNG, Selenium и другими. Для интеграции с конкретной системой тестирования может потребоваться установка соответствующего плагина.

Пример интеграции с JUnit:

1. Установите плагин «JUnit Plugin» через «Manage Jenkins» -> «Manage Plugins».
2. В настройках вашего проекта добавьте шаг сборки для выполнения тестов с использованием JUnit.
3. В разделе «Post-build Actions» добавьте «Publish JUnit test result report» и укажите путь к XML-отчету о результатах тестирования (например, **/target/surefire-reports/TEST-*.xml).

Теперь при каждой сборке проекта будут выполняться тесты, а результаты тестирования будут доступны на странице проекта в Jenkins.

Заключение

Использование Jenkins для автоматизации тестирования позволяет сократить время, затрачиваемое на ручное тестирование, минимизировать риск ошибок и повысить качество разрабатываемого ПО. Важно помнить, что успешное тестирование зависит не только от инструментов, но и от правильной организации процесса и квалификации специалистов.

Если вы хотите углубить свои знания в области тестирования ПО и изучить дополнительные инструменты и методики, рекомендуем обратить внимание на следующую онлайн-школу:

.