# Кейс: CI/CD (Git, Gitea, GitLab, TeamCity)

Связь с легендой: [../../legend/LEGEND.md](../../legend/LEGEND.md) — GitLab (ОКБ СУХОЙ, хранение тестовых скриптов), Gitea + TeamCity (АО ТНИИС, хранение Ansible-ролей и CI-конвейер с Molecule).

Ниже — учебная практика на GitHub Actions как доступной альтернативе TeamCity. Отдельно есть **реальный** опыт self-hosted CI на самом Gitea (Gitea Actions, собственные раннеры, включая кастомный cross-builder под кросс-сборку ARM) — разобран в [../docker/CASE.md](../docker/CASE.md) → раздел 9.

## Что нужно реально сделать (домашний стенд)

Поднять Gitea локально, запушить туда роль Ansible из [../ansible/CASE.md](../ansible/CASE.md), и настроить пайплайн через GitHub Actions (доступная бесплатная альтернатива TeamCity для домашней практики — принцип pipeline/stage/job идентичен, конкретный синтаксис отличается; на собеседовании это стоит явно проговаривать как «дома тренировался на GitHub Actions, на текущей работе — TeamCity, принцип тот же»).

### 1. Gitea в Docker Compose

```yaml
version: "3.8"

services:
  gitea:
    image: gitea/gitea:1.22
    container_name: gitea
    environment:
      - GITEA__database__DB_TYPE=sqlite3
      - GITEA__server__ROOT_URL=http://localhost:3001/
    ports:
      - "3001:3000"
      - "2222:22"
    volumes:
      - gitea_data:/data

volumes:
  gitea_data:
```

```bash
docker compose up -d
# зайти на localhost:3001, создать администратора, создать репозиторий "ansible-nginx-role"
git remote add gitea http://localhost:3001/<user>/ansible-nginx-role.git
git push gitea main
```

### 2. Пайплайн, прогоняющий molecule test на каждый push

```yaml
# .github/workflows/molecule.yml (для GitHub как доступной альтернативы; на реальном месте — эквивалент в TeamCity)
name: Molecule Test

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: "3.11"
      - name: Install dependencies
        run: pip install ansible molecule molecule-plugins[docker] docker
      - name: Run molecule test
        run: molecule test
```

Смысл именно в том, чтобы это был реальный прогон уже готовой роли из [../ansible/CASE.md](../ansible/CASE.md): пайплайн скачивает код, ставит зависимости и выполняет тот же `molecule test`, который до этого прогонялся вручную — то есть проверка идемпотентности и корректности роли теперь происходит автоматически при каждом push, без ручного запуска.

### 3. Модель веток

```bash
git checkout -b feature/add-ssl-support
# правки роли
git push gitea feature/add-ssl-support
# создать Pull Request в Gitea UI: feature/add-ssl-support -> main
```

Protected branch (`main`) в настройках репозитория Gitea — запрет прямого push, обязательное прохождение пайплайна (CI status check) и минимум одного ревью перед merge. Смысл: код не может попасть в основную ветку, минуя автоматическую проверку и код-ревью.

### 4. Базовые операции Git на практике

```bash
git rebase main                    # переносит коммиты ветки поверх актуального main, история линейная
git merge main                     # создаёт merge-коммит, сохраняет реальную историю параллельной разработки
git cherry-pick <commit-hash>      # переносит один конкретный коммит в текущую ветку
git bisect start
git bisect bad                     # текущий коммит содержит баг
git bisect good <старый-коммит>    # этот коммит был рабочим
# git автоматически предлагает коммиты между ними для бинарного поиска, где баг появился
```

## Что это даёт в разговоре с интервьюером

- Реально запушенный в Gitea код и реально прогнанный через CI пайплайн, проверяющий Ansible-роль — а не абстрактное «умею писать YAML».
- Понимание разницы rebase/merge не как определения, а с пониманием, когда какой подход уместен (rebase — для чистки локальной истории перед PR, merge — для сохранения факта параллельной разработки).
- Практическое понимание protected branches как механизма, а не просто слов.
- Умение нарисовать и объяснить типовой pipeline: lint → test/molecule → deploy — то, что реально спрашивали на нескольких собеседованиях (см. [../../interview/real-interviews.md](../../interview/real-interviews.md)).

## Как это ложится в легенду

Git-хостинги и CI — сквозная инфраструктура вокруг уже проработанного Ansible-кейса. Здесь не отдельный «продукт» для тестирования — кейс встраивает существующую роль в реальный пайплайн, замыкая рассказ «написал роль → протестировал локально через Molecule → теперь это же автоматически проверяется в CI на каждый push».