Алоха всем.
Все слышали о ci/cd, о том, что он должен быть в каждой компании и что он упрощает нашу жизнь.
У каждого свой ci/cd. 
CI/CD Некоторые люди предпочитают Дженкинса.
Особенно если у вас много микросервисов, команд и процессов, то с помощью Jenkins вы сможете достаточно гибко настроить ci/cd в компании.
Некоторые люди используют GitLab CI и настраивают свои собственные конвейеры и процессы для каждого репозитория.
Достаточно удобный и легко настраиваемый механизм сборки и доставки артефактов на стенды.
Не хуже действий GitHub. Для меня стало открытием, что в GitHub теперь есть такой функционал, о котором мы поговорим позже.
И, конечно же, всеми «любимый» скриптованный ci/cd. Куча скриптов, которые нужно выполнить в определенной последовательности, чтобы собрать и развернуть артефакты.
Также имеется руководство по использованию ci/cd. Но это особый вид извращения, с которым я не хочу, чтобы кто-нибудь столкнулся.
В котором вам нужно собрать артефакты на своей машине и использовать какой-нибудь readme для выполнения команд в терминале, зайти по ssh, чтобы увидеть, что всё скопировано, перезапустить службы и прочие развлечения.
Передо мной стояла задача спроектировать и написать новый сервер для проекта.
Изначально я вручную закидывал jars на сервер, чтобы проверить работоспособность и настроить сервер.
Ручное развертывание.
В какой-то момент меня это начало бесить и я задумался об автоматизации этого процесса.
Как вы понимаете, в моей компании под рукой не было специалиста по devops или кого-то, кто в этом разбирается.
Очень здорово, если у вас есть такой человек.
У меня был выбор развернуть скрипт, чего мне искренне не хотелось, так как вообще я не любитель копаться в терминале и скриптах, когда этого можно избежать.
Подключите Jenkins и настройте там задания и конвейеры.
Вариант очень крутой для крупной компании, но мне нужно развернуть только один сервер, а не тысячи микросервисов.
Да и зачем это скрывать, знаний о том, как настроить Jenkins с нуля, у меня было чуть меньше нуля.
В какой-то момент я вспомнил про GitLab CI, но для этого мне нужно было переместить свой репозиторий с GitHub. И естественно, ни я, ни моя команда этим особо не хотели заниматься.
Пришлось копать дальше.
И тут на помощь пришло обновление GitHub и появление в нем действий GitHub. Что это такое и как с этим жить? Действия GitHub — это последовательный набор команд, описанный в файлах .
yml. Используя эти действия, вы можете назначить определенные действия определенным событиям, например отправку в ветку или создание запроса на включение, например сборку проекта, запуск тестов, развертывание артефактов, перезапуск служб и многое другое.
Хм, у меня такое ощущение, что это именно то, что мне нужно.
И я начал изучать этот механизм, одновременно пытаясь внедрить его в свой проект. 
Сначала вам нужно добавить действия в ваш проект. Это можно сделать через пользовательский интерфейс GitHub или добавив эти файлы в проект. Дальше пошли различные эксперименты с возможностями действий GitHub. Например, вы можете запускать тесты каждый раз при отправке ветки.
Или, например, при создании пул-реквеста запускать тесты и сборку.
В поле запуска вы можете описать любые команды и собрать проект так, как вы привыкли.
Хорошо, со сборкой мы разобрались.
А что насчет развертывания? Для этого существуют специальные действия.
Как в целом выглядит процесс развертывания? Это сборка какого-то артефакта.
Переезд в определенное место.
И собственно перезапуск службы с новым артефактом.
Сборка есть, добавим движение артефакта.
Дальше 
Я их перемещаю в отдельную папку ci/cd, чтобы перед началом всего процесса развертывания почистить ее и не захламлять старыми артефактами.
А вообще в одну папку можно все положить.
Дело вкуса.
Кроме того, разные папки помогут вам в управлении версиями в будущем.
Отлично, мы переместили наш артефакт на сервер.
После этого мы можем остановить нашу службу, переместить новый артефакт и запустить службу.
В целом этого вполне достаточно, чтобы настроить автоматическую сборку и доставку артефактов на ваши сервера.
Но что это за волшебные параметры, используемые в экшн-играх? Это секреты GitHub. Я настоятельно рекомендую их записать и не потерять, поскольку изменить их можно только без возможности просмотра того, что на данный момент находится в этом секрете.
Да-да, это тяжело, но других вариантов нет. Итак, вы можете увидеть секрет в репозитории вашего проекта в настройках.
Здесь создаются секреты.
Секретное место.
Например, пользователь и пароль — это данные, с которыми сиай будет ходить по стендам и копировать/развертывать/выполнять действия.
Секретный стенд — это адреса серверов, куда вам нужно зайти.
SSH_PRIVATE_KEY : ${{ secrets.RUNNER_KEY }} - закрытый ключ бегуна УДАЛЕННЫЙ УЗЕЛ : ${{ secrets.HOST }} — адрес сервера, на котором развернуть УДАЛЕННЫЙ_ПОЛЬЗОВАТЕЛЬ :${{ secrets.USER }} - пользователь, под которым будет проходить теплое мероприятие 
После настройки такого ci/cd мне и команде стало намного легче жить, но через некоторое время появился нюанс, что этот процесс работает только с веткой разработки.
И развернут он только на стенде разработчика.
И мы хотели развернуть ветку RC на испытательном стенде.
Если в этом есть необходимость, давайте сделаем это.
Мы добавили новый yaml с конфигурациями для тестовых сред и отслеживания событий в ветке RC. Теперь мы все можем легко обновлять наши разработки и тестовые стенды.
Но появился один довольно тяжелый сервис, даже отдельное админское приложение, которое замедлило сборку и развертывание нашего проекта.
И вообще, мы не хотели запускать действия при изменении.
Поэтому в файл yaml было добавлено следующее: 
Также мы написали собственный yaml-файл специально для админ-консоли, чтобы при его изменении наше приложение обновляло и перезапускало админ-панель.
Это было неплохо, потому что ускорило развертывание и разгрузило действия, ведь на этом этапе изменения в админке происходили довольно редко, а сборка и развертывание занимало много времени.
И мы жили счастливо.
Трубопроводы работают. Тесты обновлены - все нормально.
Но, как всегда, появилось но.
Мы хотели развернуть на трибунах определенную ветку.
ХМ интересно.
Давайте попробуем это сделать.
Мне просто нужно было создать пару новых файлов yaml для разработчиков и тестового стенда и добавить это.
Да-да, по сути изменилась только одна строчка.
Ох, как эта возможность порадовала всю команду.
Теперь у нас есть возможность протестировать отдельные ветки функций.
Также есть возможность добавить git-хуки, которые будут проверять, например, что если ваша ветка не собрана, не прошли тесты, код стиля или что-то еще, то GitHub не позволит вам нажать кнопку слияния.
Это довольно удобно, так как обычно локально у меня «все работает», а не на стенде.
Теперь это должно работать на независимой машине.
Кстати о независимом автомобиле.
Где на самом деле происходит сборка? Действия Github имеют 2 варианта.
Возможно, их уже было больше, но я наткнулся на два.
Используйте серверы Github за определенную плату.
Быстро удобно дорого.
Или используйте свой собственный сервер, локальный компьютер или компьютер соседа, который всегда будет работать.
Вам придется потратить немного времени на настройку, но вам не придется платить каждый месяц и вы ни от кого не будете зависеть, если только ваш сервер не находится в облаке.
Существует масса документации и пояснений по настройке своей сборки автомобиля, поэтому примеры приводить не буду.
Помимо общего развертывания, естественно выделять каждую услугу отдельно.
Вы можете настроить сборку и развертывание в зависимости от условий.
Установите порядок сборки и запуска.
Сделайте сборку и развертывание сервисов параллельными.
В общем, можно много чего.
И это не может не радовать.
В общем, примерно так прошло мое первое знакомство с действиями GitHub и созданием ci/cd на моем проекте.
Вы пробовали действия GitHub? А как вы настроили ci/cd у себя в компании или это сделали девопы? Теги: #git #github #Программное обеспечение #Администрирование сервера #java #ci/cd #architecture #deploy #Github Actions #software #deployment #инструменты развертывания #сервер развертывания
-
Влияет Ли Ваш Ctr На Ваш Рейтинг В Google?
19 Oct, 24 -
«Отец Видеоигр» Умер В Возрасте 92 Лет
19 Oct, 24
