Итак, в вашем репозитории накопилось количество сборок превысившее число 1. Настало время задуматься о DevOps(е). В этом тексте я напишу как развернуть локальный сервер сборки на основе Jenkins.
Пролог
Зачем все это? Дело в том, что сам по себе репозиторий с кодом это Филькина грамота, если поверх кода нет работающего сервера сборки, который даст гарантию, что "это что-то" вообще хотя бы собирается компилятором без ошибок.
Потом, сами артефакты это Филькина грамота, если отсутствуют модульные тесты, которые дадут гарантию, что *.bin(ари) вообще работают.
Классический способ дать гарантию качества исходников это запустить поверх него сервер сборки. Есть множество готовых технологий для серверов сборки. Среди тех кто в теме на слуху такие программы как CircleCI, Jenkins и GitLab.
Идея проста. Сервер сборки это просто инфраструктурный прикладной процесс\утилита, который периодически запускает скрипты построения конкретных сборок и затем сохраняет результат (артефакты) в конкретную папку или архив. Обычно сервер сборки работает автономно 24/7 и собирает артефакты из репозитория с кодом сразу после новых коммитов.
Когда кому-то понадобится артефакты (прошивка), можно зайти в Web GUI и там выбирать, то, что нужно прямо как в супермаркете.
Достоинство серверов сборки
Всегда есть артефакт для отгрузки. Если не вчерашний, то позавчерашний.
Есть сортировка сборок по различным атрибутам. Размер бинаря, время сборки.
Сразу видны конфликты. Какие сборки с чем конфликтуют. Можно не глядя на код уже примерно понять в каком программном компоненте ошибки.
Можно анализировать полный лог сборки
Экономия времени на разработку. Например вас попросили собрать артефакт для какой-то конкретной платы. Вы просто дадите артефакт из сервера сборки.
Контроль прохождения модульных тестов
Сервер сборки нужен для контроля качества работы программистов. Тут всё просто. У хороших программистов сборки собираются, а модульные тесты проходят. У плохих программистов сборки не собираются, а тесты не проходят.
Простой контроль целостности репозитория
Азарт при разработке софтвера. Появляется желание исправить все конфликты в кодовой базе и построить по-настоящему модульный код.
Недостатки сервера сборки
При неправильной сборке могут переполнить жесткий диск. Всегда в настройках Jenkins Job(а) указывайте максимальное количество сборок, которое будет храниться на PC для каждой конкретной сборки. В противном случае вы просто переполните себе жесткий диск. У меня был случай как за полтора года Jenkins сохранил 79GByte артефактов и мне пришлось его сносить.
Желателен отдельный PC(NetTop) для работы сервера
Нужно вручную мышкой конфигурировать каждую сборку в Web интерфейсе
Пошаговое руководство запуска Jenkins на Win
Какой понадобится софтвер?
Программа |
Назначение |
*jdk-11.0.16.1_windows-x64_bin.exe |
Виртуальная машина для работы сервера сборки |
Notepad++.exe |
Текстовый редактор для изменения конфигов |
*Windows 10 |
Операционная система для сервера сборки |
git.exe |
Система контроля версий исходных кодов |
TeamViewer.exe |
Удаленный доступ к NetTop для коллективного доступа к серверу сборки |
*Tor Browser |
Для скачивания JDK |
Chrome.exe |
Браузер для просмотра таблицы сборок |
*jenkins.exe |
Сервер сборки |
Звездочной * отмечены ключевые программные компоненты. Остальное можно и заменить альтернативами.
Фаза 1: Установка Java Runtime Environment
Дело в том, что Jenkins работает поверх виртуальной машины Java. Так сделано специально, чтобы программа была переносима между различными операционными системами. Поэтому перед установкой Jenkins надо установить Java Runtime Environment(JRE). JRE это виртуальная машина для исполнения байт-кода, который генерирует компилятор Java. JRE входит в состав Java Development Kit(JDK). Это компилятор языка Java и Java Runtime Environment.
Если у вас нет java, то консоль Windows напишет это
C:\Users\xxx>java -version
'java' is not recognized as an internal or external command,
operable program or batch file.
C:\Users\xxx>
Всю JDK можно скачать по этой ссылке
https://www.oracle.com/java/technologies/javase/jdk11-archive-downloads.html
Сразу хочу отметить, что скачивать что-либо с сайта www.oracle.com следкет через Tor браузер так как РФ у них числится санкционной территорией. Плюс нужна регистрация сайте oracle. Надо скачать файл jdk-11.0.16.1_windows-x64_bin.exe
Скачивается jdk-11.0.16.1_windows-x64_bin.exe очень долго. Порядка часа. Получив дистрибутив запускаем установку
Запоминает адрес установки C:\Program Files\Java\jdk-11.0.16.1\ Он нам пригодится при установке Jenkins.
Признаком того, что Java установилась служит сообщение версии Java
C:\Users\xxxx>java -version
java version "11.0.16.1" 2022-08-18 LTS
Java(TM) SE Runtime Environment 18.9 (build 11.0.16.1+1-LTS-1)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11.0.16.1+1-LTS-1, mixed mode)
C:\Users\xxxx>
Фаза 2: Установка Jenkins
Прежде всего Jenkins надо установить на NetTop. Допустим у вас Windows. Скачать дистрибутив можно с официального сайта https://www.jenkins.io/download/
Указываем путь установки
Надо указать, что сервер будет работало локально
Указывает порт на котором будет работать Jenkins. По умолчанию 8080
Вот тут как раз следует прописать путь к JDK
Признаком работы Jenkins служит его появление в диспетчере задач
Как же открыть Jenkins? Надо в браузере и набрать этот URL
http://localhost:8080
придется настроить Jenkins. Jenkins попросит admin password из файла C:\Program Files\Jenkins\jenkins.err.log
Также придется еще подождать пока произойдет настройка плагинов. Это примерно 30 мин.
осталось только придумать логин и пароль
Открыть браузер и указать снова URL http://localhost:8080
и вот долгожданное сообщение. Jenkins установился.
Теперь остается только наполнить сервер задачами. Тут их называют Job(ами)
Фаза 4: Создание задачи Job(а)
Как же создать Jenkins Job, первую сборку?
Открывает URL http://localhost:8080/. Нажимаем New Item,
Надо придумать название сборки.
Пишем название сборки nrf5340_dk_headset_app_cmake, выбираем Freestyle project
А вот тут очень важно. Надо активировать опцию удаления устаревших сборок (Discard old builds). Иначе Jenkins увеличит папку C:\Windows\System32\config\systemprofile\AppData\Local\Jenkins\.jenkins\jobs до запредельных размеров. У меня как-то за полтора года набралось 79 GByte артефактов.
Надо указать адрес Workspace в котором данный Job будет искать скрипты сборки. То есть заполнить поле Use custom workspace
Надо указать при каких событиях будет происходить сборка. Самое простое это сказать, что надо собирать каждые 2 часа. Написать H H/2 * * *
Надо создать команду самой сборки. Нажимаем на кнопку Add build step
При работе в Windows выбираем Execute Windows batch command
Прописываем путь к скрипту сборки относительно корня репозитория. Тут как раз важно подчеркнуть, что сборки должны инициироваться скриптом. Даже если вы собираете из-под IDE вам придется разобраться как вызывать сборку IDE(шного) проекта из скрипта.
Последний шаг это сохранить артефакты. Нажимаем Add post-build action.
и выбираем вариант Archive the artefacts
И указывает конкретные расширения, которые надо сохранить
source/projects/board_build_cmake/build/**/*.elf, source/projects/board_build_cmake/build/**/*.hex, source/projects/board_build_cmake/build/**/*.bin, source/projects/board_build_cmake/build/**/*.dts, source/projects/board_build_cmake/build/**/*.map
надо прописать это в поле Archive the artifacts
Сборка настроена. Нажимаем Save.
Чтобы инициировать сборку надо нажать на кнопку Build Now. Как видно сборка собралась.
Тут сразу появилось множество интересных метрик: длительность сборки, размер прошивки, лог сборки, *.elf файл для отладки.
После всего этого вы можете конечно написать: "я не буду пользоваться сервером сборки потому, что у меня нет отдельного компьютера, а при работе в моём Workspace работающий Jenkins будет мне только мешать".
Разруливается эта ситуация очень просто. Вы организуете на своем локальном компьютере 2 репозитория: workspace и release. Workspace для редактирования кода, а release для генерации release(ных) артефактов. Release репозиторий он, как бы, только read only. Release репозиторий пополнять только из git pull(ами). Это важно, чтобы гарантировать, что все зависимости проиндексированы и находятся в репозитории c кодом.
В идеале надо, конечно же, отдельный компьютер с сервером сборки (Зомбик), чтобы на него могли заходить все заинтересованный в артефактах: разработчики, тестировщики, интеграторы, клиенты. Общий доступ можно организовать через TeamViewer или RDP.
Вот теперь вы умеете накатывать Jenkins и можете даже учить этому других.
Вывод
Надеюсь этот текст поможет сомневающимся начать практики коллективной разработки софтвера и развернуть соответствующий DevOps для этого. Пользуйтесь серверами сборки. В этом нет, ровным счетом, ничего сложного.
Links
https://www.jenkins.io/doc/book/installing/windows/
https://www.dmosk.ru/miniinstruktions.php?mini=jenkins-ubuntu
Комментарии (22)
randomsimplenumber
30.10.2022 23:40+5при работе в моём Workspace работающий Jenkins будет мне только мешать
Не будет. Вы же найдете в настройках jobы что-то связанное с SCM и не будете использовать Custom Workspace без причины. Jenkins сделает копию исходников и не будет никому мешать.
Общий доступ можно организовать через TeamViewer или RDP
Jenkins сам по себе общий доступ. Rdp тут точно лишний.
rpc1
31.10.2022 00:16+5С каких пор windows 10 ключевой компонент для Jenkins? хотя бы для себя попробовали бы установить на Linux его, тогда бы не понадобились Team Viewer, Tor и Windows (который еще и денег стоит)
aabzel Автор
31.10.2022 01:22-4У нас все сборочные скрипты это *.bat файлы. Их десятки накопилось за 2 года.
Как вы *.bat скрипты запустите на Linux?Tujh
31.10.2022 12:24+2Кстати, запуск сборки на хосте, а не на агенте считается bad practice для Jenkins.
aagzip
31.10.2022 13:04+1Что мешает поставить сам дженкинс на линукс и использовать виндовый сервер для сборки как агент?
mayorovp
31.10.2022 19:47+1Наверное, тот факт мешает что нужно будет на 1 сервер больше.
Профессиональным админам такие проблемы, может, и кажутся смешными — а вот небольшим командам вообще без админов, которые только-только доросли до стадии "у нас будет свой! сборочный! сервер!" необходимость сразу двух серверов очень помешает.
iig
02.11.2022 10:08Схема из 2 серверов, один из которых занят сборкой проектов, а другой нужен по идеологическим причинам, выглядит странно. Особенно когда на одном сервере Windows, на другом linux.
aabzel Автор
31.10.2022 01:36-5хотя бы для себя попробовали бы установить на Linux Jenkins
пробовал
--Поставил Ubuntu, открыл браузер и там слал экран мерцать. Снес Ubuntu.
--Поставил CentOS, Перезагрузил NetTop. Графическая оболочка вообще не запустилась. Только консоль. Снес CentOS
--Поставил Mint. Открыл консоль стал устанавливать JDK и не устанавливается. Снес Mint.
--Поставил Windows. Все заработало.
Tujh
31.10.2022 12:36+3Графическая оболочка вообще не запустилась.
Зачем серверу с Jenkins GUI? (Вопрос риторический)
iig
02.11.2022 00:23+1Каждое из этих приключений достойно отдельной статьи ;) Или хотя бы хокку ;)
Поставил Ubuntu
открыл браузер и там слал экран мерцать.
Снес Ubuntu
Обычно эта история немного короче.
Поставил ubuntu.
Установил jenkins (через апплет Software).
Конец истории.
ЗЫ: Не совсем понятно, зачем linux, если все ваши скрипты .bat.
Tujh
31.10.2022 12:34+2Сборка настроена. Нажимаем Save.
А ещё, всего этого можно было бы избежать, если использовать встроенные возможности Jenkins, в частности Pipline.
Из плюсов - конфигурация сборки это ещё один файл под контролем, например git. Jenkins может автоматически запускать сборку для каждого коммита в репозиторий в любой бранч (удобно для pull-request, к примеру), при этом есть возможность запустить автоматическое тестирование по завершению сборки.
Из минусов - там свой синтаксис, основанный на Groovy.
awk795
31.10.2022 15:41+2Tor Browser
Для скачивания JDK
Зачем? На Оракле свет клином сошелся? Ну хорошо, для энтерпрайза. Но для "на коленке"...
funca
"Васюки переименовываются в Нью-Москву, а Москва — в Старые Васюки. Ленинградцы и харьковчане скрежещут зубами, но ничего не могут поделать. Нью-Москва становится элегантнейшим центром Европы, а скоро и всего мира. — Всего мира! ! !" :)
На самом деле хорошая инструкция как сделать себе автоматизацию на коленках для локалхоста. Но боюсь, что дальше вы так просто уже не отделаетесь)
aabzel Автор
А что дальше? Doker запускать?
funca
По моему, Docker вписывается в концепцию бомж-автоматизации только на линуксах, где он родной и плюс-минус понятный. Для пользователей Windows это означает изучение кучи новых инструментов, не связанных напрямую с решаемой задачей, что может надолго отвлечь от основной работы. Поэтому я боюсь тут что-то советовать.
d-stream
Ну с рядом оговорок docker desktop вполне себе накликивается мышкой. Так же как и minikube (вполне пристойно работающий даже с wsl).
Ну а дальше - прям свой кубернетес)
И в этом миникубе вполне в копипаст 1-2 строк поднимаются и свой гитлаб и дженкинс и т.п.
(в том же lens - в один клик)
Желательно только памяти побольше и на руках готовая мини-лаборатория.
mayorovp
Ага, накликивается-накликивается, а потом не запускается.
d-stream
Ну тут как в старом анекдоте про самый злобный вирус... который находится в 30 см от монитора)
"оно само сломалось" - не бывает
mayorovp
Зато бывает, что оно просто недоустановилось, и без знания архитектуры докера или там WSL фиг найдёшь что именно надо доустановить. Потому что сообщение об ошибке максимально неинформативное...
d-stream
бывает и так
единственное отличие linux вариантов в таком режиме траблшутинга - гуглится большее количество советов на so разной степени полезности...
randomsimplenumber
Docker к Jenkins вроде как не относится никак Если нужна бомж-автоматизация на одном сервере - можно и не запускать;)