resume/stack/ci-cd/CASE.md

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

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

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

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

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

1. Gitea в Docker Compose

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:

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

# .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: пайплайн скачивает код, ставит зависимости и выполняет тот же molecule test, который до этого прогонялся вручную — то есть проверка идемпотентности и корректности роли теперь происходит автоматически при каждом push, без ручного запуска.

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

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 на практике

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).

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

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