Завантаження проєкту на GitHub і автодеплой на сервер

Детальний цикл підключення проєкту до GitHub і подальший автодеплой на сервер. Підключатимемося за допомогою SSH-ключів. Важливо розуміти, що для різних цілей знадобиться генерація різних ключів.

Підключення комп’ютера до GitHub за допомогою SSH-ключів. Один раз і назавжди

У PowerShell введи команду генерації SSH-ключів:

Тепер публічний ключ треба додати на GitHub
Відкрий ключ C:\Users\ТВІЙ_КОРИСТУВАЧ.ssh\id_ed25519.pub і скопіюй вміст

Встав його
Settings → SSH and GPG keys → New SSH key → встав ключ → Add SSH key

І потрібно перевірити підключення командою в PowerShell

Якщо все гаразд, з’явиться повідомлення

Для початку роботи з Git і автодеплоєм важливо одразу розділити два різні типи SSH-ключів. Вони розв’язують різні задачі й не є взаємозамінними.

✅ Крок 1: Завантаження проєкту на GitHub

Насамперед потрібно вручну створити новий репозиторій на GitHub: https://github.com/new. Під час створення позначте, що вам потрібен файл .gitignore для Python. Під час автодеплою він відіграє важливу роль: файли, які відрізнятимуться локально й на сервері (під час роботи програми), потрібно одразу внести у файл .gitignore, щоб уникнути конфліктів.

Обов’язково перевірте, що Git встановлено і на сервері, і локально, інакше команди git просто не виконуватимуться

Далі по черзі виконати в терміналі такі команди (на комп’ютері заздалегідь має бути встановлений Git):

Якщо файлу .gitignore немає, створи його. Впиши стандартні винятки й додай свої:

Завершуємо клонування

Крок 2. Клонування проєкту на сервер.

Тут той самий принцип, але ключі мають бути інші, і додаємо ми їх уже до проєкту.

1. На сервері створити ключ лише для цього репозиторію

Крок 2. Додати публічний ключ у GitHub як Deploy key

Спочатку потрібно переглянути й скопіювати ключ. Для цього на сервері ввести команду

і скопіювати ключ вигляду
ssh-ed25519 AAAAC3NzaC1lZDI1NT.....

Далі в GitHub:

• Repo → Settings → Deploy keys → Add deploy key
• Title: server clone
• Key: вставляєш вміст .pub
• ✅ Allow write access.

Крок 3. На сервері зробити SSH config, щоб GitHub завжди брав потрібний ключ

Вставити:

Якщо на одному сервері потрібно 2 ключі й більше:

Права:

Крок 4. Перевірка, що ключ працює

Або, якщо у вас кілька ключів і ви налаштовували їх через конфіг, то

Очікуємо те саме повідомлення

Крок 5. Клонування на сервер

У репозиторії знайти посилання для клонування, але саме SSH, не HTTPS. Далі все робимо на сервері
Переходимо в потрібну папку командою cd (якщо потрібно) і запускаємо команду клонування

Якщо використовували кілька ключів

Якщо репозиторій уже є, потрібно зайти всередину репозиторію і ввести:

---

Крок 3. GitHub Actions ↔ Сервер (автодеплой)

Знову потрібно буде створювати ключі, але вже саме для автодеплою GitHub Actions.

Крок 1. На своєму ПК створити ключ для автодеплою

CСтворюємо ключ для автодеплою на ПК, щоб випадково не світити приватний ключ на сервері
У PowerShell
Заздалегідь зручно перейти в папку проєкту, тоді там і з’являться файли

Вийде 2 файли (у тій самій папці, де ввели команду):

• gh-actions-deploy-main (приватний)
• gh-actions-deploy-main.pub (публічний)

Публічний ключ додати на сервер у authorized_keys

На сервері (під тим користувачем, під яким буде деплой, наприклад freelancer):

Переходимо в PowerShell на ПК. Дивимося публічний ключ:

І встав його в кінець файлу на сервері:

Ctrl + O – зберегти

Ctrl + X -вийти

Крок 3. Приватний ключ покласти в GitHub Secrets

Repo → Settings → Secrets and variables → Actions → New repository secret

Додай секрет (назву використовуй саме таку):

• SSH_PRIVATE_KEY = вміст файлу gh-actions-deploy-main (приватний, без .pub)

Додатково зазвичай потрібно:

• SSH_HOST = IP/домен сервера
• SSH_USER = користувач на сервері (наприклад freelancer)
• SSH_PORT = 22 (якщо інший — вкажеш)

Одразу даю один правильний варіант (без розгалужень):

Крок 4: Створення GitHub Actions workflow

Щоб автодеплой працював, потрібно створити список команд, які запускатимуться на сервері після оновлення файлів. Для цього створюється файл workflow

На GitHub потрібного репозиторію треба перейти на вкладку Actions
Натискаємо на
Skip this and set up a workflow yourself 

Перейменовуємо main.yml на deploy.yml (мені так зручно)
Далі потрібно вставити вміст такого вигляду

де після script: |
потрібно писати дії, які має виконати автодеплой
У моєму випадку це
cd /root/<YOUR_PATH> – перейти в папку проєкту, напишіть свій шлях
git config pull.rebase true – Так, у сценаріях CI/CD (автодеплой), особливо якщо ти пушиш напряму в main, ПОТРІБНО явно вказати стратегію злиття, інакше під час git pull в автодеплої ти отримаєш фатальну помилку
source venv/bin/activate – активація віртуального оточення, якщо потрібно
git pull – підтягує всі зміни з git
sudo systemctl restart ttc_gunicorn – перезапускає gunicorn (етапи прописані в service-файлі ttc_gunicorn)

🔁 Після наступного git push в main GitHub автоматично виконає деплой на сервер!

✅ Як перевірити, що CI/CD працює

Внеси будь-яку зміну в код
Наприклад, додай # test ci у будь-який .py файл у репозиторії.

Закоміть і запуш у main:

1. Зайди в GitHub → твій репозиторій → вкладка “Actions”
   Там має з’явитися новий запуск workflow з назвою на кшталт CI/CD або Deploy.
2. Відкрий його і дивись лог:
   Там буде видно, як GitHub підключається по SSH, робить git pull, перезапускає gunicorn тощо.

---

💡 Якщо помилок немає:

Отже, усе спрацювало. Можеш внести реальну зміну в проєкт, і вона автоматично потрапить на сервер.

Якщо виникають конфлікти між локальною версією і версією на сервері
Найімовірніше, в автодеплої є файл, який створює на сервері власні дані. Цей файл ви побачите у звітах. Додайте його у файл .gitignore
І обов’язково потрібно прибрати його з відстеження git як локально, так і на сервері. Інакше .gitignore вже не допоможе.

А тепер закомітити зміни.