Как вы использовали Git в DevOps-практиках?

Слушай, а ведь Git в DevOps — это не просто какая-то система контроля версий, это, блядь, фундамент всей нашей работы, основа основ для инфраструктуры как кода и всех этих CI/CD пайплайнов. Вот как я с ним работаю, чтобы не было потом пиздеца:

1. GitOps для инфраструктуры и конфигурации: Всё, что шевелится — манифесты для Kubernetes (хоть Kustomize, хоть Helm-овские values.yaml), модули Terraform, Ansible-плейбуки и конфиги приложений — всё это лежит в Git-репозиториях. Изменение в main-ветке — и тут же, ёпта, срабатывает триггер в ArgoCD или Flux, которые начинают всё это раскатывать в кластер. Автоматизация, хуле.

2. Стратегии ветвления и рабочий процесс:

• Trunk-based development с короткоживущими ветками: Основная движуха — в main. Берёшь задачу, отводишь от main свою ветку, делаешь дело, потом пулл-реквест, ревью, CI прогоняет — и только тогда мержишь обратно. Так интеграция идёт быстро, без этих долгих пиздецов с мержами.

  git checkout -b feat/add-prometheus-alerts
  # Тыкаюсь в манифесты PrometheusRule
  git add .
  git commit -m "feat: add critical pod restart alerts"
  git push origin feat/add-prometheus-alerts
  # Создаю Pull Request -> запускается CI (проверка yaml, terraform validate) -> после аппрува мердж в main.

• Окружения через Git: Вместо того, чтобы плодить ветки dev/staging/prod и потом в них нихуя не разобраться, я делаю по-другому. Либо разные папки в одном репе, либо разные файлы конфигов (типа values-prod.yaml). А потом просто настраиваю ArgoCD, чтобы он смотрел в нужное место. Просто, как три копейки.

3. Автоматизация через хуки и CI:

• Pre-commit хуки: Настраиваю pre-commit — это такая штука, которая проверяет код ещё до коммита. Чтоб не закоммитить какую-нибудь дичь, из-за которой потом весь пайплайн накроется медным тазом.

  # .pre-commit-config.yaml
  repos:
    - repo: https://github.com/pre-commit/pre-commit-hooks
      rev: v4.4.0
      hooks:
        - id: check-yaml
        - id: end-of-file-fixer
    - repo: https://github.com/antonbabenko/pre-commit-terraform
      rev: v1.81.0
      hooks:
        - id: terraform_fmt
        - id: terraform_validate

• Семантические коммиты и ченджлоги: Стараюсь писать коммиты по правилам: feat:, fix:, chore:. Это, во-первых, сразу понятно, что сделал. А во-вторых, потом из этого автоматом можно релизные заметки сгенерить и версию проапдейтить. Удобно же, ёпта.

4. Инцидент-менеджмент и постмортемы: А вот это, блядь, важный момент. Когда случается пиздец, не надо метаться. Сразу создаёшь ветку incident/<short-description> прямо от того коммита, на котором всё посыпалось. В этой ветке фиксируешь все действия по починке и анализ проблемы. Когда всё устаканилось — мержишь её обратно с большим, подробным коммитом-постмортемом, где ссылаешься на тикет. Чтобы потом, если что, можно было понять, что за хуйня произошла и как её починили. Доверия к процессу — овердохуища.