Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
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
2 changes: 2 additions & 0 deletions .github/workflows/ci.yml
Original file line number Diff line number Diff line change
@@ -1,3 +1,5 @@
# Воркфлоу для автоматического тестирования при пуше в dev и PR в master
# Воркфлоу для автоматического тестирования при пуше в dev и PR в master
name: CI

on:
Expand Down
42 changes: 42 additions & 0 deletions docs/ci_cd_workflow.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
# CI/CD Workflow и правила работы с ветками

В данном репозитории настроен процесс непрерывной интеграции (CI) с использованием GitHub Actions. Он автоматически запускает тесты для проверки корректности кода.

## Как работает CI/CD
Файл конфигурации `.github/workflows/ci.yml` настроен следующим образом:
1. **При каждом пуше (push) в ветку `dev`**: запускаются все тесты. Это позволяет убедиться, что новые наработки не ломают проект.
2. **При создании Pull Request (PR) в ветку `master`**: тесты запускаются снова, чтобы гарантировать, что сливаемый код стабилен.

Если тесты завершаются с ошибкой, GitHub пометит коммит/PR крестиком, и необходимо будет изучить логи (в разделе Actions в GitHub), исправить ошибки и запушить исправления.

## Правильный процесс разработки (Workflow)

Рекомендуется следующий процесс работы с ветками, если их две (`dev` и `master`):

1. **Разработка новых фич и исправление багов**:
- Все изменения делайте в локальной ветке `dev`.
- Запушьте изменения в GitHub: `git push origin dev`.
- GitHub Actions автоматически запустит тесты для вашего коммита. Убедитесь, что они прошли успешно (зеленая галочка).

2. **Слияние проверенного кода в `master` (Релиз)**:
- Не пушьте напрямую в ветку `master`.
- Вместо этого, создайте Pull Request (PR) в интерфейсе GitHub: от ветки `dev` в ветку `master`.
- При создании PR снова запустятся тесты.
- Если тесты прошли успешно (all checks have passed), вы можете нажать кнопку "Merge pull request" для слияния кода в `master`.

## Настройка Branch Protection Rules в GitHub
Чтобы предотвратить случайное попадание сломанного кода в `master`, необходимо настроить защиту ветки. Это гарантирует, что PR не может быть слит до тех пор, пока тесты не пройдут успешно.

Как это настроить в вашем репозитории на GitHub:
1. Перейдите на страницу вашего репозитория на GitHub.
2. Нажмите на вкладку **Settings** (Настройки).
3. В левом меню выберите **Branches** (Ветки).
4. Нажмите кнопку **Add branch protection rule** (Добавить правило защиты ветки).
5. В поле **Branch name pattern** введите `master`.
6. Поставьте галочку **Require a pull request before merging**.
7. Поставьте галочку **Require status checks to pass before merging**.
- Появится строка поиска. Введите название job'ы из вашего ci.yml. По умолчанию она называется `test` (или точное имя шага, которое отображается в Actions). Выберите этот чек, чтобы он стал обязательным.
8. (Опционально) Поставьте галочку **Do not allow bypassing the above settings**, чтобы эти правила применялись даже к администраторам.
9. Нажмите **Create** (или Save changes) в самом низу страницы.

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