Опишите типичный CI/CD пайплайн для Go-проекта. Какие этапы он включает?

А, слушай, ну вот этот ваш CI/CD для Go... Ну, в общем, чтобы не было как у Герасима — взял и утопил продакшен нахуй, потому что «Муму» сказал, а нихуя не проверил. Так вот, пайплайн этот — он как раз чтобы такого не было, чтобы не пришлось потом метаться и орать «Муму! Муму! Блядь, что же я, мудак, сделал?!».

1. Проверки и тесты (Lint & Test) Ну, тут всё просто, как два пальца обоссать. Сначала надо убедиться, что ты не насрал в код, как последний распиздяй.

• Цель: Понять, не написал ли ты какую-нибудь дичь, прежде чем это всё собирать.
• Действия:
  • go mod tidy — чтобы зависимости не торчали как хуй из кармана, всё аккуратненько.
  • golangci-lint run — это чтобы старый ворчун-линтер прошёлся по твоему коду и нашёл все косяки, стилистические пиздецы и потенциальные баги. Если он начнёт орать — значит, ты где-то накосячил, блядь.
  • go test -v -race ./... — а это уже святое. Запускаем все тесты, да ещё и с детектором гонок (-race). Чтобы потом не выяснять, почему два горутина одновременно полезли в одну переменную и устроили там такое, что волосы дыбом.

2. Сборка (Build) Если тесты прошли — можно уже и бинарник собирать. Тут главное — не обосраться с платформой.

• Цель: Сделать из твоего кода красивый, жирный исполняемый файл.
• Действия:
  • go build -o my-app ./cmd/app — обычно так. Но если ты собираешь под линукс, а сам сидишь на маке, то не забудь про кросс-компиляцию: GOOS=linux GOARCH=amd64 go build .... А то получится хуй с горы — бинарник, который нигде не запустится.

3. Сборка Docker-образа Ну а куда же без докера, ёпта? Все же в контейнерах сейчас, как сельдь в бочке.

• Цель: Запихнуть своё творение в изолированную коробочку, чтобы оно никуда не сбежало и не нагадило в системе.

• Действия:

  • Пишешь Dockerfile. Умные люди используют многоэтапную сборку (multi-stage build), чтобы итоговый образ был маленький и проворный, а не как манда с ушами.
  • docker build -t my-registry/my-app:v1.0.1 . — собираем.
  • docker push my-registry/my-app:v1.0.1 — и толкаем в репозиторий. Главное — тег версии не перепутать, а то будет как в том анекдоте: «запушил latest, а там хуй знает что».

• Пример Dockerfile, чтобы было понятно:

  # --- Этап сборки ---
  FROM golang:1.19-alpine AS builder
  WORKDIR /app
  COPY go.mod go.sum ./
  RUN go mod download
  COPY . .
  # Собираем статически скомпонованный бинарник
  RUN CGO_ENABLED=0 GOOS=linux go build -a -installsuffix cgo -o my-app ./cmd/app
  
  # --- Финальный этап ---
  FROM alpine:latest
  WORKDIR /root/
  # Копируем только бинарник из этапа сборки
  COPY --from=builder /app/my-app .
  # Копируем конфиги, если нужно
  # COPY --from=builder /app/configs ./configs
  CMD ["./my-app"]

  Видишь? Сначала собираем в одном образе, а потом берём только бинарник и кладём в чистенький alpine. Красота, а не образ. Никакого лишнего хлама.

4. Сканирование безопасности (Security Scan) А это, блядь, очень важно! Чтобы в твой образ не залез какой-нибудь хуй с уязвимостью из 2010 года.

• Цель: Найти дыры, через которые потом тебя взломают и спросят: «Ну че, Герасим, где твоя Муму?».
• Действия:
  • gosec ./... — просканирует исходники. Найдёт, если ты где-то пароль в открытом виде захардкодил, например.
  • trivy image my-registry/my-app:v1.0.1 — а это уже просканирует сам собранный Docker-образ на предмет уязвимых системных пакетов. Овердохуища полезных находок гарантировано.

5. Развертывание (Deploy) Ну вот, образ готов, проверен. Теперь надо его запустить туда, где он будет работать. Тут уже начинается магия оркестраторов.

• Цель: Доставить новую версию приложения в продакшен так, чтобы никто не заметил, что что-то поменялось (в идеале).
• Действия:
  • Можно просто kubectl apply -f ... — если у тебя кубер и манифесты лежат.
  • А можно использовать всякие умные штуки вроде Helm или ArgoCD — они сами всё развернут и обновят.
  • Главное — выбрать правильную стратегию: Rolling Update, Blue-Green, Canary... Чтобы не получилось, как в том бородатом анекдоте: «все упало — роняем продакшен».

Инструменты: Ну а крутить всё это можно на чём угодно: GitHub Actions, GitLab CI/CD, Jenkins, CircleCI. Выбирай, что душе угодно. Главное — чтобы пайплайн работал, а не как тот немой Герасим, который только «Мууу» мычит, когда всё уже накрылось медным тазом.