Как код выходил в продакшн на последнем месте работы?

Типичный процесс деплоя кода в продакшн

Процесс развёртывания кода в продакшн — это ответственный процесс, который включает несколько этапов для обеспечения стабильности и надёжности приложения.

Стандартный workflow (Git + CI/CD)

1. Локальная разработка

// Разработчик создаёт фичу
git checkout -b feature/new-component
// Пишет код и тесты
// Запускает локально: npm run dev
// Проверяет: npm run lint && npm run test

2. Создание Pull Request (Code Review)

// Разработчик пушит код
git push origin feature/new-component

// На GitHub/GitLab создаётся PR с:
// - Описанием изменений
// - Скриншотами UI изменений
// - Ссылкой на задачу (Jira, Linear)

// Коллеги делают Code Review:
// - Проверяют качество кода
// - Тестируют в браузере
// - Пишут комментарии

// После одобрения 1-2 рецензентами PR мержится в main
git merge --squash feature/new-component

3. Автоматизированные тесты (CI Pipeline)

После мержа в main автоматически запускается CI/CD pipeline:

// .github/workflows/deploy.yml или .gitlab-ci.yml
// Этап 1: Установка зависимостей
npm ci  // clean install для reproducible builds

// Этап 2: Линтинг
npm run lint  // ESLint, TypeScript strict check

// Этап 3: Тестирование
npm run test:run  // Unit & Integration тесты
npm run test:coverage  // Coverage отчёт (минимум 90%)

// Этап 4: Сборка
npm run build  // Next.js build, проверка на ошибки

// Этап 5: Security scanning
// - npm audit
// - SAST сканирование (SonarQube, GitHub Advanced Security)
// - Проверка зависимостей на уязвимости

Staging окружение (Pre-production)

Прежде чем идти в prod, код развёртывается на staging:

// Автоматический deploy на staging
// 1. Сборка Docker образа
docker build -t myapp:staging .

// 2. Push в Docker registry
docker push myapp:staging

// 3. Развёртывание на staging сервер
docker pull myapp:staging
docker run -e ENV=staging myapp:staging

// 4. Smoke тесты (базовые проверки)
// - Проверка доступности (curl /api/health)
// - Проверка основного функционала
// - Performance тесты

// 5. QA тестирование
// - Ручное тестирование на staging
// - E2E тесты (Playwright, Cypress)

Процесс заморозки (Release Window)

// Обычно по расписанию (например, каждый вторник в 14:00 по MSK)
// 1. Создание release branch
git checkout -b release/v1.2.3

// 2. Обновление версии
npm version minor  // или patch, major
// В package.json и package-lock.json

// 3. Создание release notes
// Список всех изменений с момента последнего релиза

// 4. Финальная проверка
// - Code freeze: запрет на новые коммиты в main
// - Все PR должны быть смержены и протестированы

Развёртывание в продакшн

// На примере Dokku (как в PrepBro)

// 1. Мержим release branch в main и main в production
git checkout main
git merge release/v1.2.3

git checkout production
git merge main

// 2. Пушим в production (запускает deploy)
git push dokku production:main

// SSH команда (эквивалент)
ssh -p 24822 dokku@178.253.42.36 deploy

// 3. Что происходит на сервере:
// - Dokku получает push
// - Собирает Docker образ
// - Запускает новый контейнер
// - Проверяет health checks
// - Старый контейнер останавливается (zero-downtime deploy)
// - Данные базы (migrations) обновляются автоматически

Мониторинг и откат после деплоя

// 1. Real-time мониторинг
// - Sentiry/Sentry для ошибок
// - Datadog/NewRelic для метрик
// - CloudFlare/Prometheus для нагрузки
// - Логи приложения в ELK/Loki

// 2. Проверка здоровья
// curl https://prepbro.ru/api/v1/health
// {
//   "status": "healthy",
//   "timestamp": "2024-01-15T10:30:00Z",
//   "version": "v1.2.3"
// }

// 3. Инцидент? Откатываемся
// Способ 1: Откатиться на последний коммит
git revert <commit-hash>
git push dokku main

// Способ 2: Развернуть предыдущую версию (если сохранена)
dokku ps:rollback myapp

// Способ 3: Быстрый откат через Docker tag
docker tag myapp:v1.2.2 myapp:latest
dokku deploy myapp

Типичная структура в компании

// Backend разработчик
// - Пишет API
// - Создаёт PR
// - Ревьюит чужой код
// - Участвует в планировании релиза

// Frontend разработчик
// - Пишет компоненты
// - Создаёт PR с скриншотами
// - Пишет E2E тесты
// - На QA окружении вместе с QA проверяет

// QA инженер
// - Тестирует на staging
// - Проверяет регрессии
// - Создаёт тест-кейсы
// - Дефекты в Jira

// DevOps/Release Manager
// - Управляет releasе
// - Запускает deploy
// - Мониторит метрики
// - В случае проблем — откатывает

// Tech Lead
// - Одобряет релиз
// - Проверяет critical PRs
// - Решает архитектурные вопросы

Пример полного deployment script

// scripts/deploy.sh
#!/bin/bash
set -e

echo "Starting deployment..."

# 1. Проверка статуса
if [ "$(git status --porcelain)" != "" ]; then
  echo "Error: есть неопубликованные изменения"
  exit 1
fi

# 2. Обновление версии
echo "Updating version..."
npm version patch -m "Release v%s"

# 3. Сборка и тесты
echo "Running tests and build..."
npm run lint
npm run test:run
npm run build

# 4. Создание Docker образа
echo "Building Docker image..."
VERSION=$(cat package.json | grep version | head -1 | awk -F: '{ print $2 }' | sed 's/[",]//g' | tr -d ' ')
docker build -t myapp:$VERSION .

# 5. Deploy
echo "Deploying to production..."
git push origin main
git push dokku main:main

echo "✓ Deployment complete! Version: $VERSION"

Лучшие практики для деплоя

1. Автоматизация — максимум процесса автоматизируй через CI/CD
2. Code Review — всегда требуй approval перед merge
3. Тесты — coverage 90%+, E2E тесты для критичного функционала
4. Staging — тестируй на staging перед prod
5. Коммуникация — уведомляй команду о деплое
6. Мониторинг — следи за ошибками после деплоя
7. Откат — всегда имей план откатки
8. Документация — описывай критичные изменения в release notes

Процесс может варьироваться по компаниям

Это базовый workflow. Компании могут отличаться:

• Некоторые деплоят несколько раз в день (continuous deployment)
• Другие — один раз в неделю (scheduled releases)
• Blue-green deployment (две идентичные среды, мгновенный откат)
• Canary deployment (постепенное внедрение на 5%, 25%, 100%)
• Feature flags для контроля видимости новых фич