Что такое Agile?

Слушай, а вот Agile, эта самая гибкая методология... Ну, в теории-то всё красиво: итерации, спринты, пост-иту ретро. А на деле-то что? Это ж просто способ заставить тебя не спать две недели подряд, потому что "работающий продукт — показатель прогресса", ёпта! Ну и показали мы им прогресс — пол-фичи и три бага, которые в прод улетели, потому что тесты отвалились. Но, бля, в этом и есть вся соль!

Вот смотри, как это в DevOps вмантивается. Без Agile там вообще пиздец начинается. Все эти принципы — они не для красивых слайдов, а чтоб реально не сойти с ума.

Вот эти ихние принципы, на которых всё держится, если по-человечьи:

• Работающий продукт — главный показатель. Ну, типа, не надо мне тут сторис про то, как ты красиво архитектуру нарисовал. Покажи, что эта хрень хотя бы собирается! В DevOps это значит, что у тебя каждый коммит — это потенциально готовая к продакшену херовина. Автоматический пайплайн собрал, протестировал, упаковал в контейнер — вот он, твой "рабочий продукт", получай. А не "ой, у меня на машине всё работало".
• Готовность к изменениям. Ага, щас. Заказчик вчера хотел красную кнопку, сегодня — зелёную, а завтра она должна издавать звук бульканья. И если твоя инфраструктура — это ручками накрученные двадцать серверов, ты просто сдохнешь. Поэтому всё в коде: инфраструктура, конфиги, зависимости. Захотел зелёную кнопку — поменял переменную, запустил пайплайн, и через пятнадцать минут она уже в тестовом окружении булькает. Хуй с горы, а не изменения!
• Частые поставки. Это вообще, ядрёна вошь, священная корова! Раньше релизились раз в полгода, а теперь — по несколько раз на дню. И это не потому что мы все ебанько, а потому что так безопаснее. Маленькие изменения, быстрая обратная связь, если что-то пошло не так — откатились на предыдущую версию за минуту. Волнение ебать, но зато не накрываешься медным тазом одним огромным релизом.

А на практике в команде это выглядит так, что сам от себя охуеваешь иногда.

Сидим мы, значит, в своём двухнедельном спринте. Чувак какую-то фичу запилил в своей ветке. Дальше — священный ритуал: создаёт Merge Request. И вот тут начинается магия, а для кого-то и пиздец. Запускается этот самый CI/CD пайплайн в GitLab, который я тебе сейчас покажу. Смотри, не зевай:

# .gitlab-ci.yml (упрощенно)
stages:
  - test
  - build
  - deploy-staging
  - deploy-prod

unit-test:
  stage: test
  script:
    - make test

build-container:
  stage: build
  script:
    - docker build -t my-app:$CI_COMMIT_SHA .
    - docker push my-registry/my-app:$CI_COMMIT_SHA

deploy-to-staging:
  stage: deploy-staging
  script:
    - kubectl set image deployment/my-app app=my-registry/my-app:$CI_COMMIT_SHA -n staging
  only:
    - merge_requests

# Ручное или автоматическое развертывание в prod после ревью кода
deploy-to-prod:
  stage: deploy-prod
  script:
    - ./scripts/blue-green-deploy.sh $CI_COMMIT_SHA
  when: manual # Требует подтверждения
  only:
    - main

Видишь эту строчку when: manual на прод? Это, бля, тот самый момент, когда у тебя вся ответственность наступает. Ты сидишь, смотришь на зелёные тесты, на апрувы от коллег, и палец твой зависает над кнопкой. Доверия ебать ноль к самому себе, но деваться некуда. Нажал — и понеслась: сине-зелёное развёртывание, никакого даунтайма, пользователи даже не узнали, что кнопка стала булькать.

Так что Agile в DevOps — это, ёб твою мать, не про то, чтобы стендапы вовремя начинать. Это про то, чтобы вся команда, от разработчика до тестировщика, могла безопасно и быстро запиливать ценность, не превращая каждый релиз в "Хиросиму и Нагасаки". Вротберунчик, а не процесс!