ОПЕРАЦИИ IT ПРОЕКТА

ЧАСТЬ 1: ОКРУЖЕНИЯ
├── 1.1 Два режима работы
├── 1.2 LEGACY vs NEXT
├── 1.3 Структура окружений
└── 1.4 PREVIEW окружение

ЧАСТЬ 2: БЕЗОПАСНОСТЬ
├── 2.1 Контрольные точки (backup)
├── 2.2 Не чинить ядро (откат)
├── 2.3 Один шаг = одна проверка
├── 2.4 Записывать всё (DEVLOG)
├── 2.5 Git после проверки
├── 2.6 Откат немедленно
└── 2.7 Правило удалённых изменений

ЧАСТЬ 3: DEPLOYMENT
├── 3.1 Процесс деплоя
├── 3.2 Проверка перед deploy
└── 3.3 Rollback при ошибке

DEV        → разработка
STAGING    → точная копия prod, финальные тесты
PRODUCTION → боевой

1. Разработка на DEV
2. Деплой на STAGING
3. Тесты на STAGING (копия prod)
4. Если OK → деплой на PRODUCTION
5. Если НЕ OK → фикс на DEV → повтор с шага 2

DEV        → разработка + ВСЕ тесты
PRODUCTION → релиз + мониторинг

1. Разработка на DEV
2. Все тесты на DEV
3. Если OK → деплой на PRODUCTION
4. Мониторинг PRODUCTION
5. Hotfix если что-то сломалось

Domain: site.ru
Status: production (работает)
Version: v1.x.x
Поддержка: минимальная (только критические баги)

Domain: new.site.ru → (после миграции) → site.ru
Status: в разработке
Version: v2.0.0
Цель: заменить LEGACY

LEGACY (v1.x.x)          NEXT (v2.0.0)
site.ru (работает)       DEV → PREVIEW → PRODUCTION
        ↓
После миграции:
site.ru → archive.site.ru (выключить)
new.site.ru → site.ru (DNS переключение)

/home/user/
├── site.ru/           ← PRODUCTION
│   ├── web/
│   ├── vendor/
│   └── .env → PROD
│
└── stage.site.ru/     ← STAGING (копия prod)
    ├── web/
    ├── vendor/
    └── .env → STAGE

1. Разработка на DEV (localhost)
2. Деплой на PREVIEW (new.site.ru)
3. Тесты на PREVIEW
4. Миграция: new.site.ru → site.ru

STAGING:
- Копия ТЕКУЩЕГО прода
- Тестируем изменения LEGACY продукта
- Перед деплоем в PRODUCTION

PREVIEW:
- НОВЫЙ продукт (NEXT)
- Демо и тесты НОВОЙ версии
- Перед МИГРАЦИЕЙ на PRODUCTION

{тип}_{дата}_{время}.{ext}

vanilla-20260213-110019.tar.gz               ← L3: Голый дистрибутив
modules-before-deploy-20260213-143022.tar.gz ← L1
db-before-migration-20260213-143505.sql.gz   ← L2
full-backup-20260213-150000.tar.gz           ← L4

# L1: Модули
tar -czf "arh/modules-$(date +%Y%m%d-%H%M%S).tar.gz" modules/

# L2: БД
mysqldump -u user -p db_name | gzip > "arh/sql/db-$(date +%Y%m%d-%H%M%S).sql.gz"

# L3: Vanilla (после установки CMS)
cd ~/
tar -czf "backups/vanilla/vanilla-$(date +%Y%m%d-%H%M%S).tar.gz" site.ru/
mysqldump -u user -p db_name | gzip > "backups/vanilla/vanilla-db-$(date +%Y%m%d-%H%M%S).sql.gz"

# L4: Полный backup
tar -czf "$INFRA/backups/full-$(date +%Y%m%d-%H%M%S).tar.gz" site.ru/

~/                                    ← Рабочий проект
├── site.ru/                          ← Код
├── arh/                              ← L1-L2 (локальные backup)
│   ├── modules/
│   └── sql/
└── backups/                          ← L3 (vanilla backup)
    └── vanilla/

$INFRA/backups/            ← L4 (долгосрочные backup)

❌ НЕПРАВИЛЬНО:
1. Пытаться чинить core файлы
2. Накручивать workarounds
3. Продолжать если не работает

✅ ПРАВИЛЬНО:
1. ОТКАТ к последнему backup
2. Проверка: "это работает?"
3. Повторить изменение ПО-ДРУГОМУ

# Сломалось после установки модуля
# ❌ НЕ ДЕЛАТЬ: vim vendor/drupal/core/...

# ✅ ДЕЛАТЬ:
cd ~/
tar -xzf backups/vanilla/vanilla-20260213-030000.tar.gz
gunzip -c backups/vanilla/vanilla-db.sql.gz | mysql -u user -ppass db_name

# Проверка
curl -I http://site.ru/
# HTTP/1.1 200 OK ✓

# Попробовать по-другому
# (не тот модуль / другая версия / другой подход)

1. СДЕЛАТЬ одно изменение
2. ПРОВЕРИТЬ что работает
3. ЗАПИСАТЬ в DEVLOG.md
4. GIT COMMIT
5. Следующее изменение

# 1. СДЕЛАТЬ
drush en commerce -y

# 2. ПРОВЕРИТЬ
drush pml --status=enabled | grep commerce
# commerce: enabled ✓

curl -I http://site.ru/admin/commerce
# HTTP/1.1 200 OK ✓

# 3. ЗАПИСАТЬ
cat >> DEVLOG.md << 'EOF'

## [MODULE] 2026-02-13 14:30

Commerce enabled:
- Version: 2.35
✓ Модуль включён
✓ Админка доступна
EOF

# 4. GIT COMMIT
git add DEVLOG.md
git commit -m "Setup: module commerce enabled"
git tag v0.2.0

[YYYY-MM-DD HH:MM] ДЕЙСТВИЕ: описание
  Параметр: значение
  ✓ Результат
  → Статус

[2026-02-13 03:00] INFRA CHECK: проверка окружения
  PHP: 8.4
  MySQL: 8.0
  ✓ Всё установлено
  → ГОТОВО к работе

[2026-02-13 03:15] VANILLA: настройка завершена
  URL: http://new.site.ru/
  Admin: http://new.site.ru/admin
  ✓ Сайт работает
  → VANILLA готова

[2026-02-13 03:30] MODULE: commerce enabled
  Версия: 2.35
  ✓ Модуль включён
  → Работает

[2026-02-13 04:00] BACKUP: создан L3
  Файл: ~/backups/vanilla/vanilla-20260213-040000.tar.gz
  Размер: 45M
  ✓ Проверен
  → Backup готов

[2026-02-13 14:30] DEPLOY: modules to production
  Модули: commerce, token, pathauto
  ✓ Деплой успешен
  → PRODUCTION обновлён

{Этап}: {действие}

git commit -m "Zero: Drupal 11.3.3 deployed"
git commit -m "Setup: database created"
git commit -m "Setup: modules enabled (locale, commerce)"
git commit -m "Vanilla: backup created"
git commit -m "Feature: custom module created"
git commit -m "Fix: form validation error"
git commit -m "Deploy: modules deployed to production"
git commit -m "Rollback: reverted to v0.5.0"

git tag v0.1.0  # первая фича
git tag v0.2.0  # вторая фича
git tag v1.0.0  # релиз в prod
git push origin --tags

# 1. СТОП работы

# 2. Найти последний рабочий backup
ls -lt ~/backups/vanilla/
# vanilla-20260213-030000.tar.gz  ← этот работал

# 3. Откат файлов
cd ~/
rm -rf broken.site.ru
tar -xzf backups/vanilla/vanilla-20260213-030000.tar.gz

# 4. Откат БД
gunzip -c backups/vanilla/vanilla-db-20260213-030000.sql.gz | \
  mysql -u user -ppass db_name

# 5. Проверка
curl -I http://site.ru/
# HTTP/1.1 200 OK ✓

# 6. Записать
cat >> DEVLOG.md << 'EOF'

## [ROLLBACK] 2026-02-13 15:00

Откат к vanilla:
- Причина: сломалась установка модулей
- Backup: vanilla-20260213-030000.tar.gz
✓ Откат выполнен
✓ Сайт работает
→ Попробовать другой подход
EOF

git add DEVLOG.md
git commit -m "Rollback: reverted to vanilla 20260213-030000"

# ❌ ОПАСНО (слепая перезапись)
echo "new_setting=1" > /etc/config.conf
# ← СТИРАЕТ ВСЁ остальное!

# ❌ ОПАСНО (UPDATE без WHERE)
UPDATE products SET price=0;
# ← ОБНУЛЯЕТ ВСЕ цены!

# ❌ НЕПРАВИЛЬНО
echo "server_name site.ru;" >> /etc/nginx/site.conf

# ✅ ПРАВИЛЬНО
cat /etc/nginx/site.conf  # сначала смотрим
# Понимаем структуру
# ПОТОМ вносим изменение
sed -i 's/old_value/new_value/' /etc/nginx/site.conf

-- ❌ НЕПРАВИЛЬНО
UPDATE products SET category_id=5 WHERE sku='ABC123';

-- ✅ ПРАВИЛЬНО
SELECT * FROM products WHERE sku='ABC123';  -- сначала смотрим
-- Видим текущее состояние
-- ПОТОМ обновляем
UPDATE products SET category_id=5 WHERE sku='ABC123';

# Файлы: всегда с timestamp
cp /path/to/file /path/to/file.bak-$(date +%Y%m%d-%H%M%S)

-- БД: backup строк
CREATE TABLE products_backup_20260213_143500
AS SELECT * FROM products WHERE condition;

# ❌ ГЛОБАЛЬНО (опасно)
echo "new" > file.txt  # перезаписывает ВСЁ

# ✅ КОНКРЕТНО (безопасно)
sed -i 's/^old_line$/new_line/' file.txt  # меняет ОДНУ строку

-- ❌ ГЛОБАЛЬНО (опасно)
UPDATE users SET active=0;  -- меняет ВСЕ записи

-- ✅ КОНКРЕТНО (безопасно)
UPDATE users SET active=0 WHERE last_login < '2024-01-01';

# 1. Изменение
sed -i 's/listen 80/listen 8080/' nginx.conf

# 2. Проверка содержимого
grep "listen" nginx.conf
# listen 8080; ✓

# 3. Проверка синтаксиса
nginx -t
# syntax is ok ✓

# 4. Проверка работы
systemctl reload nginx
curl -I http://localhost:8080
# HTTP/1.1 200 OK ✓

-- 1. Изменение
UPDATE products SET price=price*1.1 WHERE category_id=5;
-- Query OK, 42 rows affected

-- 2. Проверка результата
SELECT COUNT(*), AVG(price), MIN(price), MAX(price)
FROM products WHERE category_id=5;
-- Проверить разумность цен ✓

-- 3. Проверка конкретной записи
SELECT * FROM products WHERE category_id=5 LIMIT 5;

-- Транзакции
START TRANSACTION;

UPDATE accounts SET balance=balance-100 WHERE id=1;
UPDATE accounts SET balance=balance+100 WHERE id=2;

-- Проверить
SELECT balance FROM accounts WHERE id IN (1,2);

-- Если OK → зафиксировать
COMMIT;

-- Если НЕ OK → откатить
-- ROLLBACK;

# Файлы: write to temp → rename (атомарная замена)
cat > /tmp/config.new << 'EOF'
new_content
EOF

# Проверить
cat /tmp/config.new

# Атомарная замена (одна операция)
mv /tmp/config.new /etc/config.conf

ПЕРЕД ИЗМЕНЕНИЕМ:
□ Есть backup?
□ Знаю команду rollback?
□ Проверил backup (можно восстановить)?
□ Записал что изменяю (в DEVLOG)?

ЕСЛИ ВСЁ ✓ → делать изменение
ЕСЛИ ЧТО-ТО ✗ → СТОП, сначала подготовить

┌─────────────────────────────────────────────┐
│ ЛЮБОЕ ИЗМЕНЕНИЕ НА УДАЛЁННОМ СЕРВЕРЕ/БД     │
└─────────────────────────────────────────────┘
                    ↓
         ┌──────────────────────┐
         │ 1. READ (прочитать)  │
         │ - Что там сейчас?    │
         │ - Понятна структура? │
         └──────────────────────┘
                    ↓
         ┌──────────────────────┐
         │ 2. BACKUP (сохранить)│
         │ - Файл: .bak-DATE    │
         │ - БД: backup таблица │
         └──────────────────────┘
                    ↓
         ┌──────────────────────┐
         │ 3. MODIFY (изменить) │
         │ - Конкретное место   │
         │ - НЕ всё подряд      │
         └──────────────────────┘
                    ↓
         ┌──────────────────────┐
         │ 4. VERIFY (проверить)│
         │ - Прочитать результат│
         │ - Тест (syntax/logic)│
         └──────────────────────┘
                    ↓
              ┌─────────┐
              │ OK?     │
              └─────────┘
               /       \
          ДА /         \ НЕТ
            ↓           ↓
   ┌──────────────┐  ┌──────────────┐
   │ 5. COMMIT    │  │ ROLLBACK     │
   │ - Применить  │  │ - Откатить   │
   │ - Записать   │  │ - Из backup  │
   └──────────────┘  └──────────────┘

# 1. READ
ssh server "cat /etc/nginx/sites-available/site.conf" > site.conf.current
cat site.conf.current  # изучаем

# 2. BACKUP на сервере
ssh server "cp /etc/nginx/sites-available/site.conf \
             /etc/nginx/sites-available/site.conf.bak-$(date +%Y%m%d-%H%M%S)"

# 3. MODIFY (локально)
cp site.conf.current site.conf.new
vim site.conf.new  # редактируем

# 4. VERIFY (локально)
docker run --rm -v $(pwd):/etc/nginx nginx nginx -t -c /etc/nginx/site.conf.new
# syntax is ok ✓

# 5. UPLOAD
scp site.conf.new server:/tmp/site.conf.new

# 6. ATOMIC REPLACE
ssh server "sudo mv /tmp/site.conf.new /etc/nginx/sites-available/site.conf"

# 7. VERIFY на сервере
ssh server "nginx -t"
# syntax is ok ✓

# 8. COMMIT
ssh server "systemctl reload nginx"

# 9. CHECK
curl -I https://site.ru
# HTTP/1.1 200 OK ✓

# ROLLBACK (если что-то не так):
# ssh server "cp /etc/nginx/sites-available/site.conf.bak-DATE \
#              /etc/nginx/sites-available/site.conf && \
#              systemctl reload nginx"

-- 1. READ (сколько затронем?)
SELECT COUNT(*) FROM products WHERE sku LIKE 'ABC%';
-- 5000 rows! ← СТОП, это много!

-- Уточняем
SELECT COUNT(*) FROM products WHERE sku='ABC-123';
-- 1 row ✓

-- 2. BACKUP
CREATE TABLE products_backup_20260213_143500
AS SELECT * FROM products WHERE sku='ABC-123';

-- 3. MODIFY
UPDATE products
SET price=999.99
WHERE sku='ABC-123';
-- Query OK, 1 row affected ✓

-- 4. VERIFY
SELECT sku, price FROM products WHERE sku='ABC-123';
-- sku='ABC-123', price=999.99 ✓

-- ROLLBACK (если ошибка):
-- UPDATE products p
-- SET price=(SELECT price FROM products_backup_20260213_143500 b
--            WHERE b.id=p.id)
-- WHERE sku='ABC-123';

1. DEV: разработка + тесты
   ├─ git commit -m "Feature: X"
   └─ git tag v0.5.0

2. STAGING: деплой + тесты на копии prod
   ├─ rsync/git pull на STAGING
   ├─ Тесты на STAGING
   └─ Если OK → шаг 3
      Если НЕ OK → фикс на DEV → шаг 1

3. PRODUCTION: деплой
   ├─ BACKUP prod (L1+L2)
   ├─ rsync/git pull на PRODUCTION
   ├─ Проверка работоспособности
   └─ Если OK → релиз
      Если НЕ OK → ROLLBACK

1. DEV: разработка + ВСЕ тесты
   ├─ git commit -m "Feature: X"
   ├─ git tag v0.5.0
   └─ Все тесты пройдены ✓

2. PRODUCTION: деплой
   ├─ BACKUP prod (L1+L2)
   ├─ rsync/git pull на PRODUCTION
   ├─ Проверка работоспособности
   └─ Если OK → релиз
      Если НЕ OK → ROLLBACK

ПЕРЕД ДЕПЛОЕМ (обязательно):
□ Backup создан (L1+L2)
□ Тесты пройдены (на DEV/STAGING)
□ Git tag поставлен (v0.x.x)
□ DEVLOG заполнен
□ План rollback готов

ЕСЛИ ВСЁ ✓ → deploy
ЕСЛИ ЧТО-ТО ✗ → СТОП

# L1: Модули
tar -czf "arh/modules-before-deploy-$(date +%Y%m%d-%H%M%S).tar.gz" \
  modules/custom/

# L2: БД
mysqldump -u user -ppass db_name | \
  gzip > "arh/sql/db-before-deploy-$(date +%Y%m%d-%H%M%S).sql.gz"

# 1. СТОП деплоя

# 2. Найти backup ПЕРЕД деплоем
ls -lt arh/modules/
# modules-before-deploy-20260213-143022.tar.gz

ls -lt arh/sql/
# db-before-deploy-20260213-143505.sql.gz

# 3. Откат файлов
tar -xzf arh/modules/modules-before-deploy-20260213-143022.tar.gz \
  -C modules/

# 4. Откат БД
gunzip -c arh/sql/db-before-deploy-20260213-143505.sql.gz | \
  mysql -u user -ppass db_name

# 5. Проверка
curl -I http://site.ru/
# HTTP/1.1 200 OK ✓

# 6. Записать
cat >> DEVLOG.md << 'EOF'

## [ROLLBACK] 2026-02-13 14:50

Deploy откачен:
- Причина: ошибка после деплоя модулей
- Backup: modules-before-deploy-20260213-143022.tar.gz
- DB backup: db-before-deploy-20260213-143505.sql.gz
✓ Откат выполнен
✓ Сайт работает
→ Исправить проблему на DEV
EOF

git add DEVLOG.md
git commit -m "Rollback: deploy reverted to 20260213-143022"