40ff73f647
Реальная настройка self-hosted CI Gitea Actions (починка раннера из restart-loop, кастомный cross-builder под ARM) вписана в опыт АО ТНИИС: LEGEND.md/STORY.md — расширены строки Gitea/Docker и раздел про два CI-инструмента отдела, docker/CASE.md — новый раздел 9 с воспроизводимыми фрагментами, ci-cd/CASE.md — ссылка на реальный кейс. SERVER.md/PROGRESS.md актуализированы: исправлена ошибочная запись про порт 3000 (это Grafana, не Gitea) и добавлен чек-лист, что нельзя ломать в CI-инфраструктуре сервера при прохождении курса Kubernetes.
98 lines
6.5 KiB
Markdown
98 lines
6.5 KiB
Markdown
# Кейс: 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».
|