Skip to content

docs: Add CI/CD workflow documentation #75

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
MarcusStill wants to merge 1 commit into
base: dev
Choose a base branch
from
Open

docs: Add CI/CD workflow documentation #75

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
40 changes: 40 additions & 0 deletions docs/ci_cd_workflow.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,40 @@
# Настройка CI/CD и рабочий процесс (Workflow)

## Общее описание
В проекте настроен непрерывный процесс интеграции (CI) с использованием GitHub Actions.
Конфигурация CI находится в файле `.github/workflows/ci.yml`.

## Ветвление
В репозитории используются две основные ветки:
1. **`dev` (development)** — ветка для разработки и тестирования новых функций. Все новые наработки отправляются сюда.
2. **`master`** — основная, стабильная ветка. Сюда попадает только проверенный и протестированный код из ветки `dev`.

## Рабочий процесс (Workflow)
Для того чтобы код попал в `master`, вам нужно следовать такому алгоритму:

1. **Разработка:** Вы пишете код и делаете коммиты в вашу локальную ветку (или сразу в `dev`, если работаете с ней напрямую).
2. **Отправка (Push) в `dev`:** При выполнении `git push` в ветку `dev`, GitHub Actions автоматически запускает тесты.
- Тесты запускаются в среде Ubuntu.
- Настраивается Python 3.12, устанавливаются необходимые пакеты и зависимости из `requirements.txt` (очищенного от Windows-специфичных пакетов).
- Выполняется команда для запуска тестов с использованием `pytest` (с фиктивными данными для БД и в виртуальном X-сервере `xvfb`).
3. **Проверка (CI):**
- **Если тесты не прошли:** вы получите уведомление (крестик в GitHub). В этом случае нужно зайти во вкладку *Actions* в репозитории, посмотреть логи ошибки, исправить баг в коде и сделать новый коммит в `dev`.
- **Если тесты прошли успешно:** появится зеленая галочка.
4. **Pull Request (PR):** Убедившись, что в `dev` все работает исправно (и CI светится зеленым), вы создаете Pull Request из ветки `dev` в ветку `master`.
- При создании PR в `master` снова автоматически запустятся тесты (согласно конфигурации `on: pull_request: branches: [master]`).
5. **Слияние (Merge):** Если тесты в PR прошли успешно и код ревью пройден (если требуется), PR сливается в `master`.

## Настройка защиты веток в GitHub (Branch Protection Rules)
Чтобы процесс работал корректно и никто случайно не сломал `master`, необходимо в настройках репозитория на GitHub включить защиту веток:

1. Перейдите в **Settings -> Branches**.
2. В разделе **Branch protection rules** нажмите **Add rule** (или отредактируйте существующее для `master`).
3. В поле **Branch name pattern** введите `master`.
4. Включите следующие опции:
- **Require a pull request before merging:** Запрещает прямые коммиты в `master`. Все изменения должны проходить через PR (в нашем случае из `dev`).
- **Require status checks to pass before merging:**
- Выберите эту опцию и добавьте в список обязательных проверок джоб из нашего CI (он называется `test` согласно `ci.yml`).
- Включите **Require branches to be up to date before merging**.
5. Сохраните изменения.

Аналогичные правила можно настроить для ветки `dev` (например, чтобы код попадал в `dev` тоже через PR из feature-веток), но если вы коммитите прямо в `dev` один, то защиту для `dev` можно оставить менее строгой. Главное — защитить `master`.