Гайд Github Actions для самых маленьких

[personochka]

CI/CD с Github Actions для самых маленьких
Сегодня мы поговорим об одной крутой штуке, которая поможет нам автоматизировать процесс сборки и деплоя нашего приложения.
Постараюсь сильно не углубляться в подробности, но если интересна эта тема - пишите комментарии :)

Что такое CI?
Ну, смотри, CI - это почти "казино" для разработчиков (или по-человечески "непрерывная интеграция"), завалятся тесты (если ты их, конечно, написал) или нет.
Что нужно для реализации CI?

• Во-первых, должна быть базовая ветка (например, master, ты ведь пользуешься Git? :) ).
• Во-вторых, должны быть тесты, которые будут проверяться при каждом коммите, мердже или пулл реквесте в эту ветку.
• В-третьих, должен быть CI-сервер, который будет запускать тесты и выдавать результаты.

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

Примерами таких серверов могут быть:

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

Что такое CD?
Так, вникай. Если лототрон из предыдущего "казино" выбил тебе джекпот ввиде успешных тестов, то ты можешь смело деплоить свое приложение на сервер.

А как проходит этот ваш "деплой"? Зависит от того, как работает твой проект, но в общем случае это выглядит так:

1. CI дает зеленый свет на деплой
2. CI/CD-сервер забирает твой репозиторий и запускает скрипт сборки, билдит Dockerfile и т.д.
3. После успешного билда CI/CD-сервер деплоит твое приложение на сервер, по твоему сценарию (например, через SSH)

Ну вот, теперь ты знаешь, что такое CD и как он работает. Пора переходить к практике.

Практика
Мы будем использовать Github Actions для нашего CI/CD.
Почему? Потому что это бесплатно (ну почти, сервер на 2000 минут наш, либо ставь свой Runner на свой сервер), просто и удобно.

Установка Github Actions Runner (Если хочешь, чтобы твой раннер работал на твоем сервере)
Так, приступим. Я начну с установки своего Github Actions Runner`а на свой сервер.
Для установки раннера нужно подготовить сервер, на котором он будет работать.
Я буду использовать сервер на Ubuntu 22.04.

Создаем отдельного пользователя для раннера, чтобы не мучиться с правами:

sudo adduser <ник пользователя>

Выдадим пользователю права суперпользователя:

sudo usermod -aG sudo <ник пользователя>

Переключимся на пользователя:

su - <ник пользователя>

Приступаем к самому интересному - установке раннера.
Открываем репозиторий вашего проекта и переходим раздел "Settings", у него еще шестеренка в названии.

Далее переходим в раздел "Actions/Runners" и нажимаем на кнопку "New self-hosted runner". Выбираем нашу ОС и архитекрутуру, на которой будет работать раннер. Вводим команды, которые нам выдал Github и запускаем их на сервере, ты же разберешься, как это сделать, да?

После ввода последней команды, инсталлер Github Actions будет спрашивать дополнительную информацию (на это мы пока забьем), тыкаем Enter пока все не закончится.

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

sudo ./svc.sh install
sudo ./svc.sh start

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

Создаем пайпланы
Что такое пайплайн? Пайплайн - это набор шагов, которые выполняются нашим раннером, почти бесплатный раб, да?
Создаем файлик в корне репозитория .github/workflows/deploy.yml и пишем туда следующее:

name: 'Название пайплайна'

on: # Когда будет запускаться пайплайн
  push: # При коммите в ветки указанные ниже
    branches:
      - master # Название ветки, на которую будет реагировать пайплайн
  
jobs:
  deploy: # Имя задачи может быть каким угодно, делай как нравится
    runs-on: self-hosted # указываем, что пайплайн будет запускаться на нашем раннере, или укажи ubuntu-latest, 
                         # если хочешь, чтобы пайплайн запускался на серверах Github
    steps:
      - name: 'Checkout' # Название шага, делай как нравится
        uses: actions/checkout@v2 # Используем встроенный шаг для скачивания репозитория в папку раннера.
      
      - name: 'Run tests'
        run: 'go test ./...' # Запускаем тесты, в случае Golang проекта, если у тебя другой язык, то пиши свои команды,
                             # Если тесты завалились, то пайплайн завершится с ошибкой и сборка и деплой не начнется.

      - name: 'Build' # Собираем бинарник. Ты напиши свои команды, которые будут собирать твое приложение.
        run: |
          cd cmd
          go build -o app

      - name: 'Deploy' # для примера, перезапустим сервис приложения.
                       # Ты же напиши список своих команд, которые будут деплоить твое приложение.
        run: sudo service myBackend restart

Пушим в репозиторий и смотрим на результаты.

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

 

[SapDragon]

наконец гайды которые мы заслужили!!

 

[Egor_Kreed]

годно, но мне кажется спизжено

 

[personochka]

годно, но мне кажется спизжено

Написано мной с моральной поддержкой от ChatGPT

 

[Egor_Kreed]

Написано мной с моральной поддержкой от ChatGPT

фотограф получаеца