Итак, в вашем репозитории накопилось количество сборок превысившее число 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)


  1. funca
    30.10.2022 23:11
    +3

    В идеале надо, конечно же, отдельный компьютер с сервером сборки (Зомбик), чтобы на него могли заходить все заинтересованный в артефактах: разработчики, тестировщики, интеграторы, клиенты. Общий доступ можно организовать через TeamViewer или RDP

    "Васюки переименовываются в Нью-Москву, а Москва — в Старые Васюки. Ленинградцы и харьковчане скрежещут зубами, но ничего не могут поделать. Нью-Москва становится элегантнейшим центром Европы, а скоро и всего мира. — Всего мира! ! !" :)

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


    1. aabzel Автор
      30.10.2022 23:40

      А что дальше? Doker запускать?


      1. funca
        31.10.2022 00:15
        +4

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


        1. d-stream
          31.10.2022 00:42
          +2

          Ну с рядом оговорок docker desktop вполне себе накликивается мышкой. Так же как и minikube (вполне пристойно работающий даже с wsl).

          Ну а дальше - прям свой кубернетес)

          И в этом миникубе вполне в копипаст 1-2 строк поднимаются и свой гитлаб и дженкинс и т.п.

          (в том же lens - в один клик)

          Желательно только памяти побольше и на руках готовая мини-лаборатория.


          1. mayorovp
            31.10.2022 19:39
            +1

            Ну с рядом оговорок docker desktop вполне себе накликивается мышкой.

            Ага, накликивается-накликивается, а потом не запускается.


            1. d-stream
              01.11.2022 12:35
              +1

              Ну тут как в старом анекдоте про самый злобный вирус... который находится в 30 см от монитора)

              "оно само сломалось" - не бывает


              1. mayorovp
                01.11.2022 17:53
                +1

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


                1. d-stream
                  01.11.2022 18:47
                  +1

                  бывает и так

                  единственное отличие linux вариантов в таком режиме траблшутинга - гуглится большее количество советов на so разной степени полезности...


      1. randomsimplenumber
        01.11.2022 23:45

        Docker к Jenkins вроде как не относится никак Если нужна бомж-автоматизация на одном сервере - можно и не запускать;)


  1. randomsimplenumber
    30.10.2022 23:40
    +5

    при работе в моём Workspace работающий Jenkins будет мне только мешать

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

    Общий доступ можно организовать через TeamViewer или RDP

    Jenkins сам по себе общий доступ. Rdp тут точно лишний.


  1. rpc1
    31.10.2022 00:16
    +5

    С каких пор windows 10 ключевой компонент для Jenkins? хотя бы для себя попробовали бы установить на Linux его, тогда бы не понадобились Team Viewer, Tor и Windows (который еще и денег стоит)


    1. aabzel Автор
      31.10.2022 01:22
      -4

      У нас все сборочные скрипты это *.bat файлы. Их десятки накопилось за 2 года.
      Как вы *.bat скрипты запустите на Linux?


      1. kama
        31.10.2022 09:17
        +4

        Для этого нужны агенты на Windows.


      1. Tujh
        31.10.2022 12:24
        +2

        Кстати, запуск сборки на хосте, а не на агенте считается bad practice для Jenkins.


      1. aagzip
        31.10.2022 13:04
        +1

        Что мешает поставить сам дженкинс на линукс и использовать виндовый сервер для сборки как агент?


        1. mayorovp
          31.10.2022 19:47
          +1

          Наверное, тот факт мешает что нужно будет на 1 сервер больше.


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


          1. iig
            02.11.2022 10:08

            Схема из 2 серверов, один из которых занят сборкой проектов, а другой нужен по идеологическим причинам, выглядит странно. Особенно когда на одном сервере Windows, на другом linux.


    1. aabzel Автор
      31.10.2022 01:36
      -5

      хотя бы для себя попробовали бы установить на Linux Jenkins

      пробовал

      --Поставил Ubuntu, открыл браузер и там слал экран мерцать. Снес Ubuntu.

      --Поставил CentOS, Перезагрузил NetTop. Графическая оболочка вообще не запустилась. Только консоль. Снес CentOS

      --Поставил Mint. Открыл консоль стал устанавливать JDK и не устанавливается. Снес Mint.

      --Поставил Windows. Все заработало.


      1. Tujh
        31.10.2022 12:36
        +3

        Графическая оболочка вообще не запустилась.

        Зачем серверу с Jenkins GUI? (Вопрос риторический)


      1. iig
        02.11.2022 00:23
        +1

        Каждое из этих приключений достойно отдельной статьи ;) Или хотя бы хокку ;)

        Поставил Ubuntu

        открыл браузер и там слал экран мерцать.

        Снес Ubuntu

        Обычно эта история немного короче.

        Поставил ubuntu.

        Установил jenkins (через апплет Software).

        Конец истории.

        ЗЫ: Не совсем понятно, зачем linux, если все ваши скрипты .bat.


  1. Tujh
    31.10.2022 12:34
    +2

    Сборка настроена. Нажимаем Save.

    А ещё, всего этого можно было бы избежать, если использовать встроенные возможности Jenkins, в частности Pipline.

    Из плюсов - конфигурация сборки это ещё один файл под контролем, например git. Jenkins может автоматически запускать сборку для каждого коммита в репозиторий в любой бранч (удобно для pull-request, к примеру), при этом есть возможность запустить автоматическое тестирование по завершению сборки.

    Из минусов - там свой синтаксис, основанный на Groovy.


  1. awk795
    31.10.2022 15:41
    +2

    Tor Browser

    Для скачивания JDK

    Зачем? На Оракле свет клином сошелся? Ну хорошо, для энтерпрайза. Но для "на коленке"...