architect/standards/arh/it-projects.md

type: standard
aspect: guidance
title: "IT ПРОЕКТЫ: ОСНОВЫ РАЗРАБОТКИ"
version: 1.0.0
date: 2026-02-19
status: active

IT ПРОЕКТЫ: ОСНОВЫ РАЗРАБОТКИ

Версия: 2.0.0
Дата: 2026-02-14
Статус: Мастер-индекс

НАЗНАЧЕНИЕ

Этот документ — фундамент для работы с любыми IT проектами.

Содержит:
- Ключевые понятия (что помнить всегда)
- Главные принципы (как работать)
- Навигация (где искать детали)

Детали в документах:
- PROJECT_INIT.md — Инициализация проекта (PATH A и PATH B)
- PROJECT_DEV.md — Ежедневная разработка (workflow)
- PROJECT_OPS.md — Операции (окружения, деплой, rollback)

КЛЮЧЕВЫЕ ПОНЯТИЯ

Три состояния проекта

ZERO        VANILLA         WORKING         PRODUCTION
────────    ────────────    ───────────     ──────────
Установка   Голый дистр     Версии v0.x     Релиз v1.0+
из коробки  v0.0.0          с изменениями   в проде
НЕ работает ОТКАТ точка    git tags        боевой

ZERO:
- Система установлена, НЕ настроена
- БД не подключена
- Как телефон после распаковки

VANILLA:
- ⚠️ КРИТИЧНО: Vanilla = ВСЕГДА чистая CMS
- Drupal/Laravel/WordPress из коробки
- БД подключена, система работает
- Базовые модули (locale, commerce)
- НЕТ кастомизации, НЕТ custom кода
- Точка отката при проблемах

WORKING:
- Версии с изменениями (v0.1.0, v0.2.0, ...)
- Каждая версия = git tag
- Есть custom код, модули, настройки

PRODUCTION:
- Релиз v1.0.0+
- Работает в проде
- Стабильная версия

Два пути создания проекта

PATH A: Создание с нуля
Zero → Vanilla (v0.0.0) → Working (v0.1.0+) → Production (v1.0.0+)
↑                          ↑
Установка CMS              Разработка

PATH B: Онбординг существующего
Получение → Онбординг (v1.0.0) → Working (v1.1.0+)
            ↑
            НЕ vanilla! Это рабочий проект

PATH A:
- Нет готового решения
- Выбираем CMS сами
- Создаём Vanilla → разработка

PATH B:
- Есть готовое решение
- Переезд с другого сервера
- Получение → настройка → работа
- ⚠️ Результат ≠ vanilla (уже кастомизировано)

Детали: PROJECT_INIT.md

Версионирование

Формат: MAJOR.MINOR.PATCH (v1.2.3)

PATH A (новый проект):

v0.0.0 = Vanilla (чистый дистрибутив)
v0.1.0 = Первая фича
v0.x.x = Разработка (не в проде)
v1.0.0 = Релиз в production
v1.1.0 = Новая фича в проде
v1.1.1 = Баг-фикс

PATH B (онбординг):

Если есть версия → сохранить (v2.3.1 → v2.3.2)
Если нет версии → v1.0.0 (онбординг завершён)

Что менять:
- MAJOR (1.0.0 → 2.0.0): Breaking changes
- MINOR (1.0.0 → 1.1.0): Новая фича
- PATCH (1.0.0 → 1.0.1): Баг-фикс

ГЛАВНЫЕ ПРИНЦИПЫ

🔴 ПРИНЦИП ОТКАТА

ЗАПРЕЩЕНО:
- ❌ Править ядро (core) системы
- ❌ Чинить сломанное на месте
- ❌ Накручивать workarounds

ПРАВИЛЬНО:
- ✅ Откатиться к предыдущей рабочей версии
- ✅ Продолжить с чистого состояния
- ✅ Искать где именно поломка

Алгоритм:

1. ПЕРЕД изменением → backup (контрольная точка)
2. ДЕЛАТЬ изменение → одно за раз
3. ЕСЛИ сломалось → СТОП! Откат
4. НИКОГДА не менять ядро CMS

Детали: ROLLBACK_POLICY.md, PROJECT_OPS.md

📝 ПРИНЦИП ЗАПИСИ

ОБЯЗАТЕЛЬНО после каждой операции:

  1. DEVLOG.md — что сделано, что работает
  2. Git commit — зафиксировать изменения
  3. Git tag — поставить версию (v0.x.x)

Формат DEVLOG:

## [v0.2.0] 2026-02-13 14:30

СДЕЛАНО:
• Установлен модуль dru_lider_catalog
• Включены базовые блоки

РАБОТАЕТ:
✓ /admin/modules — модуль active
✓ /admin/structure/block — блоки видны

ОТКАТ:
git checkout v0.1.0

Детали: PROJECT_OPS.md

⚡ ПРИНЦИП АТОМАРНОСТИ

ОДИН ШАГ = ОДНА ПРОВЕРКА

❌ НЕПРАВИЛЬНО:
1. Установить 5 модулей
2. Изменить конфиг
3. Деплой
4. Проверить всё сразу

✅ ПРАВИЛЬНО:
1. Установить модуль 1 → проверка → git commit
2. Установить модуль 2 → проверка → git commit
3. Изменить конфиг → проверка → git commit
4. Деплой → проверка → git commit

Если на шаге N сломалось:
- Откат к шагу N-1
- Изменить подход
- Повторить шаг N

Детали: PROJECT_OPS.md

🔒 ПРИНЦИП БЕЗОПАСНЫХ ИЗМЕНЕНИЙ

Правило READ-MODIFY-WRITE для удалённых серверов:

❌ ОПАСНО:
vim /etc/nginx/sites-enabled/site.conf  ← правим вслепую
service nginx restart                    ← может не запуститься

✅ БЕЗОПАСНО:
1. READ:   cat /etc/nginx/.../site.conf > backup.conf
2. MODIFY: vim site.conf (локально)
3. TEST:   nginx -t (проверка синтаксиса)
4. WRITE:  загрузить на сервер
5. CHECK:  nginx -t && service nginx reload
6. VERIFY: curl http://site.ru

Для БД:

1. READ:   mysqldump db > backup.sql
2. MODIFY: создать миграцию
3. TEST:   проверить на локальной копии БД
4. WRITE:  применить миграцию на prod
5. CHECK:  проверить результат
6. VERIFY: проверить работу сайта

Детали: PROJECT_OPS.md

НАВИГАЦИЯ ПО ДОКУМЕНТАЦИИ

Создание проекта → PROJECT_INIT.md

PATH A: Создание с нуля
- Zero → Vanilla → Разработка
- Выбор CMS, установка, настройка
- Создание контрольных точек

PATH B: Онбординг существующего
- Получение проекта
- Настройка на нашем сервере
- Версионирование существующего

Эталонные данные:
- .credentials.md — пароли (НЕ в git)
- .project-config.md — параметры (в git)
- Принцип наследования через ${VAR}

Разработка → PROJECT_DEV.md

Ежедневный workflow:
- Разработка локально
- Тестирование
- Code review
- Интеграция

(будет заполнено позже)

Операции → PROJECT_OPS.md

Окружения:
- DEV (разработка)
- STAGING (тестирование)
- PRODUCTION (боевой)
- PREVIEW (новая версия продукта)

Deployment:
- Режим полного цикла (DEV → STAGING → PROD)
- Режим быстрого цикла (DEV → PROD)
- LEGACY vs NEXT (параллельная разработка)

Backup и откат:
- Уровни backup (L1-L4)
- Алгоритм отката
- Хранение контрольных точек

Безопасность:
- Правило удалённых изменений (READ-MODIFY-WRITE)
- Git после проверки
- Откат немедленно при ошибке

ЧЕКЛИСТ ПЕРЕД НАЧАЛОМ РАБОТЫ

Для ЛЮБОГО проекта (всегда):

Для нового проекта (PATH A):

Для онбординга (PATH B):

Для работы с окружениями:

БЫСТРАЯ СПРАВКА

Команды

Действие Команда
Создать контрольную точку tar -czf vanilla-$(date +%Y%m%d).tar.gz project/
Откатиться к Vanilla tar -xzf vanilla-YYYYMMDD.tar.gz
Записать в DEVLOG vim DEVLOG.md → добавить запись
Создать версию git tag v0.1.0 && git push --tags
Проверка nginx nginx -t
Backup БД mysqldump db_name > backup-$(date +%Y%m%d).sql

Формулы

Vanilla:

Vanilla = Чистый дистрибутив CMS
        = Точка отката при проблемах
        = v0.0.0 (PATH A)

Rollback:

Сломалось → Откат к Working → НЕ чинить → Повторить по-другому

Git после проверки:

Изменение → Проверка → DEVLOG → Git commit → Git tag

Удалённые изменения:

READ (backup) → MODIFY (локально) → TEST → WRITE → CHECK → VERIFY

СВЯЗАННЫЕ ДОКУМЕНТЫ

Документ Назначение
PROJECT_INIT.md Инициализация проекта (PATH A, PATH B)
PROJECT_DEV.md Ежедневная разработка
PROJECT_OPS.md Операции (окружения, деплой, backup)
ROLLBACK_POLICY.md Политика отката
DEPLOYMENT.md Процесс деплоя
BACKUP.md Политика бэкапов
CODE_DATA_SEPARATION.md Разделение код/данные
SECURITY_CREDENTIALS.md Безопасность credentials

ПРАВИЛО ПРИМЕНЕНИЯ

Этот документ — ФУНДАМЕНТ.

При начале работы с проектом:
1. Прочитать IT_PROJECTS.md (этот файл)
2. Загрузить нужный детальный документ (INIT/DEV/OPS)
3. Применить к конкретной задаче

Не загружай всё в контекст сразу. Загружай только то, что нужно СЕЙЧАС.

Версия: 2.0.0
История:
- v1.0.0-1.3.0: Монолитный PROJECT_WORKFLOW.md (1982 строки)
- v2.0.0: Разделение на 4 файла (мастер + 3 детальных)