Skip to content

docs: Add CI/CD workflow and branch protection guide #77

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 and branch protection guide #77

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
43 changes: 43 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,43 @@
# CI/CD Workflow и работа с ветками (GitHub)

Данный проект использует GitHub Actions для автоматического тестирования и непрерывной интеграции (CI/CD). Ниже описано, как устроен процесс работы с ветками `dev` и `master`, а также как настроить защиту веток в GitHub.

## 1. Структура веток

В проекте используется две основные ветки:
* **`dev`** — ветка для активной разработки. Сюда отправляются все новые коммиты (наработки, исправления, фичи).
* **`master`** — стабильная ветка. Сюда попадает только проверенный код, который успешно прошел тесты в ветке `dev`.

### Правильный рабочий процесс (Workflow)
1. Вы работаете локально и делаете коммиты в ветку `dev`.
2. Отправляете изменения на сервер (GitHub): `git push origin dev`.
3. GitHub Actions автоматически запускает тесты (из каталога `tests/`) для ветки `dev`.
4. Если тесты проходят успешно (зеленая галочка), вы создаете **Pull Request (PR)** из ветки `dev` в ветку `master`.
5. При создании PR тесты могут быть запущены повторно, чтобы убедиться в совместимости.
6. Если всё "ОК", вы сливаете (merge) PR в `master`.
7. Если тесты падают ("крестик"), вы смотрите логи в GitHub Actions (вкладка **Actions**), исправляете ошибки локально, делаете новый коммит в `dev`, пушите, и тесты запускаются заново.

## 2. Настройка автоматического запуска тестов (уже настроено)

В репозитории уже есть файл настроек GitHub Actions: `.github/workflows/ci.yml`.
Он настроен следующим образом:
- Срабатывает при каждом `push` в ветку `dev`.
- Срабатывает при создании и обновлении `pull_request` в ветку `master`.
- Запускает виртуальную машину (Ubuntu), устанавливает зависимости и выполняет команду запуска тестов через `pytest`.

## 3. Как запретить слияние в `master` с ошибками (Branch Protection)

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

1. Откройте страницу вашего репозитория на GitHub.
2. Перейдите в раздел **Settings** (Настройки).
3. В левом меню выберите **Branches** (Ветки).
4. Нажмите кнопку **Add branch protection rule** (Добавить правило защиты ветки).
5. В поле **Branch name pattern** (Шаблон имени ветки) введите: `master`
6. Поставьте галочку **Require a pull request before merging** (Требовать PR перед слиянием).
7. Поставьте галочку **Require status checks to pass before merging** (Требовать успешного прохождения проверок статуса перед слиянием).
- В появившемся поле поиска проверок (Search for status checks) найдите и выберите `test` (это имя задания из нашего `ci.yml`).
- Рекомендуется также поставить галочку **Require branches to be up to date before merging** (Требовать, чтобы ветка была актуальной).
8. Нажмите кнопку **Create** (или **Save changes**), чтобы сохранить правило.

Теперь никто не сможет напрямую запушить код в `master` или слить Pull Request, если тесты в GitHub Actions завершились с ошибкой.