Всем Алоха. Все слышали про ci/cd, про то что он должен быть в каждой компании и то, что он упрощает нам жизнь. У всех свой ci/cd. 

   Кто-то предпочитает Jenkins. Особенно если у вас куча микросервисов, команд и процессов, то при помощи дженкинса можно достаточно гибко настроить ci/cd в компании. Кто-то использует GitLab CI и для каждого репозитория настраивает свои пайплайны и процессы. Достаточно удобно и просто настраиваемый механизм сборки и доставки артефактов на стенды. Ничуть не хуже GitHub actions. Это было открытием для меня, что в GitHub появился такой функционал, о котором мы поговорим позже. Ну и конечно всеми «любимый» скриптовый ci/cd. Пачка скриптов, которые нужно выполнить в определенной последовательности, чтобы собрать и задеплоить артефакты. Есть ещё так сказать хэнд мэнуал ci/cd. Но это особый вид извращения, с которым не пожелаю столкнуться никому. В котором нужно собрать артефакты у себя на машине и по какому-нибудь ридми выполнять команды в терминале, лазить по ssh смотреть, что все копировалось, перезапускать сервисы и другие развлечения. 

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

    В один момент я вспомнил про GitLab CI, но для этого мне нужно было перемещать мой репозиторий с GitHub. А делать этого естественно ни я, ни моя команда не очень то хотели. Нужно было копать дальше. И тут на помощь пришло обновление GitHub и появление GitHub экшенов в нем. Что это такое и как с этим жить? GitHub actions это последовательный набор команд, описываемых в .yml файлах. При помощи этих экшенов можно повесить на какие-то события, например на пуш в ветку или создание пул реквеста, определенные действия, типа сборки проекта, прогона тестов, деплой артефактов, перезапуск сервисов и многое другое. Хм, сложилось такое ощущение, что это именно то, что мне нужно. И я начал изучать этот механизм параллельно пробуя внедрить его в свой проект. 

Для начала нужно добавить экшены в свой проект. Это можно сделать через UI GitHub или добавив эти файлы в проект 

    Дальше пошли различные эксперименты с возможностями GitHub экшенов. Для примера, можно при каждом пуше ветки запускать тесты. Или например, при создании пул реквеста запускать тесты и билд. 

    В run поле можно описать любые команды и собирать проект, как вы  привыкли.

    Годится, разобрались со сборкой. А как быть с деплоем? Для этого есть специальные экшены. Что из себя представляет процесс деплоя в целом? Это сборка какого-то артефакта. Перемещение в определенное место. И собственно перезапуск сервиса с новым артефактом. Сборка есть, давайте добавим перемещение артефакта. 

Далее     

Я перемещаю их в отдельную папку ci/cd, что бы перед началом всего процесса деплоя, очистить ее и не захламлять старыми артефактами. Но в целом можно все помещать в одну папку. Дело вкуса. Так же разные папки в будущем помогут вам с версионированием.

 Отлично мы переместили наш артефакт на сервер. После этого, мы можем остановить наш сервис, переместить новый артефакт и запустить сервис. 

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

    Но что это за магические параметры используются в экшенах? Это GitHub секреты. Крайне рекомендую их записывать и не терять, потому как их можно только изменить без возможности просмотреть, что сейчас находится в этом секрете. Да да, жестко, но других вариантов нет. Так вот, вы в репозитории своего проекта можете в настройках увидеть секрет. Как раз там и создаются секреты. Тайное место. Например юзер и пароль это данные с которыми сиай будет ходить по стендам и копировать/деплоить/выполнять действия. Секрет стенд это адреса серверов куда нужно ходить. 

SSH_PRIVATE_KEY: ${{ secrets.RUNNER_KEY }} - приватный ключ раннера

REMOTE_HOST: ${{ secrets.HOST }} - адрес сервера куда нужно деплоить

REMOTE_USER: ${{ secrets.USER }} - пользователь под которым будет происходить теплой

После наладки такого ci/cd жить мне и команде стало намного легче, но спустя время появился нюанс, что этот процесс работает только с девелоп веткой. И деплоится только на дев стенд. А нам хотелось деплоить RC ветку на тест стенд. Раз есть в этом необходимость, давайте сделаем. Мы добавили новый yaml с конфигурациями для тестовых окружений и отслеживанием событий в RC ветке.    

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

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

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

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

Да да, по сути поменялась всего лишь одна строчка. 

       Ооо как эта возможность обрадовала всю команду. У нас появилась возможность тестировать отдельные фича бранчи. 

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

    Кстати про независимую машину. А где вообще происходит сборка? У гитхаб экшенов есть 2 варианта. Может уже больше, но я столкнулся с двумя. Использовать сервера гитхаба за определенную плату. Быстро удобно дорого. Или же использовать свой собственный сервер, локальный комп или комп соседа, который постоянно будет работать. Немного придётся потратить времени на настройку, но вам не придётся платить каждый месяц и вы не будите ни от кого зависеть, если только ваш сервак не в облаке. Документации и объяснений, как настроить свою билд тачку куча, поэтому не буду приводить примеры. 

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

    В целом примерно так у меня прошло первое знакомства с GitHub  экшенами и созданием ci/cd у меня на проекте. А вы пробовали GitHub экшены на вкус? И как вы настраивали ci/cd у себя в компании или это сделали девопсы?