Деплой та відкат

Симптоми

• Після деплою сервіс почав давати помилки, метрики деградували, з’явилися 5xx у CloudWatch / Telegram-logger.

Швидка перевірка

1. Що деплоїлось у вікно інциденту? Зіставити commit-hash з тегом контейнера / Amplify build / Railway deploy.
2. Це code change (CodePipeline / Amplify / Railway) чи config change (SSM)?
3. Помилка корелює з deploy за часом?

Відкат — по платформах

ECS Fargate (Abitly API, Abitly Web prod)

# 1. Знайти попередню task-def revision
aws ecs describe-services \
  --cluster abitly-prod-backend --services abitly-prod-backend \
  --profile abitly --region eu-central-1 \
  --query 'services[0].deployments'

# 2. Оновити service на попередню revision
aws ecs update-service \
  --cluster abitly-prod-backend --service abitly-prod-backend \
  --task-definition abitly-prod-backend:<previous-revision> \
  --profile abitly --region eu-central-1

Альтернатива — --force-new-deployment на тій самій revision, якщо потрібно redeploy без зміни task-def.

Elastic Beanstalk (Studsearch backend)

# Список версій
aws elasticbeanstalk describe-application-versions \
  --application-name studsearch-backend \
  --profile abitly --region eu-central-1 \
  --query 'ApplicationVersions[].{label:VersionLabel,date:DateCreated}'

# Відкат
aws elasticbeanstalk update-environment \
  --environment-name studsearch-prod-env \
  --version-label <previous-label> \
  --profile abitly --region eu-central-1

EC2 (Strapi)

CodePipeline abitly-prod-strapi зберігає попередні artifacts у S3 abitly-prod-strapi-pipeline-*. Відкат:

• У CodePipeline UI → попередній execution → Retry. Або
• SSH/SSM → EC2 abitly-prod-strapi → перезапустити процес з попереднього артефакту (TODO: уточнити agent — CodeDeploy / SSM RunCommand).

Amplify (Abitly Web dev, Studsearch Web)

Amplify Console → app → branch → попередній successful build → Redeploy this version.

Railway (Telegram bot, Mini App)

mcp__railway__list-deployments → знайти попередній SUCCESS
mcp__railway__redeploy → передати deploymentId

Або у Railway UI → Service → Deployments → старий SUCCESS → ⋯ → Redeploy.

SSM-config rollback

Якщо причина — зміна /abitly/prod/<scope>/<key>:

# Подивитись історію версій параметра
aws ssm get-parameter-history --name '/abitly/prod/backend/<key>' \
  --profile abitly --region eu-central-1 \
  --query 'Parameters[].{ver:Version,date:LastModifiedDate}'

# Повернути попереднє значення
aws ssm put-parameter --name '/abitly/prod/backend/<key>' \
  --value '<previous-value>' --overwrite \
  --profile abitly --region eu-central-1

Lambda abitly-prod-ssm-redeploy автоматично форсне ECS rolling restart.

Після відкату

1. Перевірити, що сервіс здоровий (health endpoints + service-down triage).
2. Зафіксувати причину (issue в репо сервісу).
3. Не передеплоювати поки не виправлено.

Профілактика

• Перевірка на dev перед prod (особливо для DB-міграцій).
• Canary / staged rollout — поки не налаштовано (TODO: чи варто).
• Чіткі release-теги (commit-hash вже у тегу образу ECR).
• Для конфігу — спочатку оновити dev-параметр, перевірити, потім prod.