Skip to content

Docs: Add CI/CD workflow documentation #83

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 #83

Show file tree
Hide file tree
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
1 change: 1 addition & 0 deletions .github/workflows/ci.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
# GitHub Actions CI/CD workflow
name: CI

on:
Expand Down
34 changes: 34 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,34 @@
# Настройка CI/CD и рабочий процесс

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

## Рабочий процесс (Git Flow)

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

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

## Настройка защиты ветки `master` (Branch Protection Rules)

Чтобы гарантировать, что в `master` попадает только рабочий код, необходимо настроить защиту ветки в настройках репозитория на GitHub:

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

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