С какими инструментами CI/CD и сборки ты работал?

А, ну это я люблю, когда про пайплайны спрашивают! Сидел тут, блядь, как последний олух, настраивал эту всю хуйню, чтобы от коммита до продакшена всё летело само, как по маслу. Терпения ноль ебать, пока всё отладишь, но зато потом — красота, можно хоть чай пить.

Так вот, слушай историю. Взял я на вооружение GitLab CI/CD — инструмент, конечно, мощный, но иногда такой пиздопроебибна, что волнение ебать. Пишешь этот самый .gitlab-ci.yml, а он тебе: «А хуй тебе, а не пайплайн! Ошибка в 32-й строке». И сидишь, ебать копать, ищешь запятую потерянную. Но когда настроил — красота. Стадии там: build, test, security-scan, deploy. Докер-раннеры, кэши артефактов, окружения динамические поднимаются — ёперный театр, а не система. Кодчик вот такой простенький для примера:

stages:
  - build
  - test
  - deploy
build_image:
  stage: build
  script:
    - docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
    - docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA

Потом ещё GitHub Actions подключал — тоже, вротберунчик, удобная штука. Автоматизируешь там тесты, деплой на какую-нибудь VPS или в AWS — и спишь спокойно. Ну и Jenkins, старичок, куда ж без него. Настраивал эту всю архитектуру «мастер-агент», писал Jenkinsfile, цеплял SonarQube, чтобы код проверял, и Slack, чтобы оповещал, если всё накрылось медным тазом. Доверия ебать ноль к этому дженкинсу, потому что он вечно виснет, но работает.

Для сборки, ясное дело, Docker — святое дело. Контейнеризуешь всё, что шевелится. Делаешь многоступенчатые сборки, чтобы образы не весили овердохуища, а были лёгкими и быстрыми. А ещё Packer — это вообще песня. Собираешь заранее заточенные образы для AWS или GCP, где уже и докер стоит, и софт нужный, и конфиги. Приходит время — раз и поднял виртуалку с идеальной начинкой, не тратя время на установку.

Ну и самое мясо — Infrastructure as Code (IaC). Тут мой главный друг — Terraform. Чувак, это просто магия. Сидишь, попивая кофе, описываешь в конфигах всю свою инфраструктуру в AWS: VPC, EC2-шки, базы RDS, хранилища S3, права IAM. Потом команду terraform apply дал — и он тебе, как добрый волшебник, всё это разворачивает. Модули использовал для переиспользования кода, state файлы хранил в S3, чтобы команда могла работать, workspace для разделения сред (dev, staging, prod). Выглядит это примерно так:

resource "aws_instance" "app_server" {
  ami           = data.aws_ami.ubuntu.id
  instance_type = "t3.micro"
  tags = {
    Name = "ExampleAppServer"
  }
}

А для тонкой настройки уже развёрнутого — Ansible в руки. Configuration management — это его стезя. Настройка операционки, деплой приложений, управление пользователями, сервисами — хоть на обычных серверах, хоть на нодах внутри Kubernetes. Написал плейбук, запустил — и через полчаса двадцать серверов как под копирку настроены. Удивление пиздец, когда впервые видишь, как это работает.

Вот такой вот стек получается. Сначала, конечно, мозг вытекает, пока во всём этом разбираешься, но потом, когда всё пашет автоматически — чувствуешь себя повелителем вселенной, блядь. Ну, или хотя бы своим маленьким сегментом инфраструктуры.