architect/standards/arh/lifecycle-project.md

type: standard
aspect: lifecycle
title: "Полный стандарт ведения IT проекта"
version: 1.0.0
date: 2026-02-19
status: active


Полный стандарт ведения IT проекта

Версия: 1.0.0
Дата: 2026-02-13
Применение: Любой IT проект от инициализации до поддержки


Содержание

  1. Инициализация проекта
  2. Структура проекта
  3. Git и версионирование
  4. Разработка
  5. Тестирование
  6. Деплой
  7. Поддержка
  8. Документация

Инициализация проекта

Шаг 1: Создание структуры

# Создать проект
mkdir -p projects/org/PROJECT_NAME
cd projects/org/PROJECT_NAME

# Базовая структура
mkdir -p app arh dev tst prd deploy docs

# Git
git init

Шаг 2: Базовые файлы

# README
cat > README.md << 'EOF'
# PROJECT_NAME

Краткое описание проекта.

## Структура

- `app/` - штатное (дистрибутивы)
- `dev/` - разработка
- `tst/` - тест
- `prd/` - продакшн
- `arh/` - архив

## Запуск

...
EOF

# .gitignore
cat > .gitignore << 'EOF'
# Штатное
/app/vendor/
/app/node_modules/
/app/core/

# Архив
/arh/

# Временное
*.log
.DS_Store
*.tmp
EOF

# Документация проекта
cat > PROJECT.md << 'EOF'
# Проект PROJECT_NAME

**Тип:** [drupal/python/nodejs/...]
**Статус:** development
**Версия:** 0.1.0

## Описание

...

## Зависимости

...

## Серверы

- **Dev:** локально
- **Test:** ...
- **Prod:** ...
EOF

Шаг 3: Git коммит

git add .
git commit -m "init: project structure"
git branch -M master

Структура проекта

Обязательные папки

project/
├── app/          ← Штатное (обязательно)
├── arh/          ← Архив (обязательно)
├── dev/          ← Разработка (обязательно)
├── tst/          ← Тест (опционально*)
├── prd/          ← Продакшн (обязательно)
├── deploy/       ← Деплой скрипты (обязательно)
└── docs/         ← Документация (рекомендуется)

* tst/ опционально если:
- Быстрое тестирование (<1 дня)
- Маленький проект (1 разработчик)
- Можно сразу dev → prd

app/ - Штатное

Назначение: То что НЕ мы написали

Содержимое по типам проектов:

Drupal

app/
├── drupal-VERSION/       Drupal core
├── vendor/               Composer deps
└── contrib/              Contrib modules

Python

app/
├── python-VERSION/       Python runtime
└── venv/                 Virtual environment

Node.js

app/
├── node-VERSION/         Node runtime
└── node_modules/         NPM packages

WordPress

app/
├── wordpress-VERSION/    WordPress core
└── plugins/              Plugins (не наши)

dev/ - Разработка

Структура по типам:

Drupal modules

dev/
└── modules/
    ├── custom_module_1/
    ├── custom_module_2/
    └── ...

Python scripts

dev/
└── scripts/
    ├── import.py
    ├── export.py
    └── ...

Node.js app

dev/
└── src/
    ├── components/
    ├── pages/
    └── ...

tst/ и prd/

Структура: Зеркало dev/

tst/
└── [та же структура что в dev/]

prd/
└── [та же структура что в dev/]

deploy/

deploy/
├── servers.conf          Конфигурация серверов
├── push.sh               Деплой на серверы
├── pull.sh               Скачать с серверов
└── status.sh             Статус деплоев

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

Ветки

Минимум (простой проект):

master  - основная ветка

Средний проект:

master      - основная
develop     - разработка

Большой проект:

master      - prod
develop     - dev
staging     - test
feature/*   - фичи
hotfix/*    - срочные фиксы

Коммиты

Формат:

type(scope): subject

body (опционально)

footer (опционально)

Типы:
- feat - новая функция
- fix - исправление бага
- docs - документация
- refactor - рефакторинг
- test - тесты
- chore - рутина

Примеры:

git commit -m "feat(catalog): add smart slots"
git commit -m "fix(import): handle empty prices"
git commit -m "docs: update deployment guide"

Теги

При деплое на prod:

git tag v1.0.0
git tag v1.0.0-catalog  # для конкретного модуля
git push --tags

Формат версий: MAJOR.MINOR.PATCH
- MAJOR - Breaking changes
- MINOR - Новые фичи (обратно совместимо)
- PATCH - Баг-фиксы


Разработка

Цикл разработки

1. Создание задачи
   
2. Разработка в dev/
   
3. Локальное тестирование
   
4. Git коммит
   
5. Готово  dev  tst

Рабочий процесс

День N: Начало работы

# 1. Обновить код
git pull

# 2. Проверить статус
./deploy/status.sh

# 3. Начать работу
cd dev/modules/new_feature/
vim src/Feature.php

Во время работы

# Локальные тесты
./test.sh

# Проверка кода
phpcs src/
eslint src/

# Коммит по мере готовности
git add .
git commit -m "feat(feature): add X"

Конец дня

# Убедиться что всё закоммичено
git status

# Запушить
git push

# Обновить TODO если есть
vim TODO.md

Тестирование

Уровни тестирования

1. Локальное (в dev/)

Что тестируем:
- Unit тесты
- Интеграционные тесты
- Линтеры (phpcs, eslint)

Команды:

# PHP
phpunit tests/
phpcs --standard=PSR12 src/

# JavaScript
npm test
npm run lint

# Python
pytest tests/
flake8 src/

2. Test сервер (в tst/)

Что тестируем:
- Функциональные тесты
- UI тесты
- Интеграция с другими модулями

Процесс:

# 1. Деплой на test
cp -r dev/module tst/
./deploy/push.sh module test

# 2. Тестирование
open http://test-server.com
# Проверяем функционал вручную

# 3. Фиксируем результат
echo "✅ Tested OK" > tst/module/TESTED.md
# или
echo "❌ Bug found: ..." > tst/module/TESTED.md

3. Prod (в prd/)

Smoke tests после деплоя:

# Проверить что сайт открывается
curl -s http://prod-server.com | grep "OK"

# Проверить основные функции
curl -s http://prod-server.com/catalog | grep "products"

# Проверить логи
ssh server "tail -100 /var/log/app.log"

Чек-лист перед деплоем

Dev → Test

✓ Unit тесты пройдены
✓ Линтеры OK
✓ Нет TODO/FIXME в коде
✓ Git коммит создан
✓ README обновлён (если нужно)

Test → Prod

✓ Функциональные тесты OK
✓ UI тесты OK
✓ Нет ошибок в логах test сервера
✓ Бэкап текущей prod создан
✓ План отката готов
✓ Время деплоя согласовано (низкая нагрузка)

Деплой

Процесс деплоя

┌─────────────────────────────────────────────────────────────┐
│ ПОДГОТОВКА                                                  │
│ - Проверить тесты                                           │
│ - Создать бэкап                                             │
│ - Уведомить команду                                         │
└─────────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────────┐
│ ДЕПЛОЙ                                                      │
│ - Копировать код (tst/ → prd/)                              │
│ - Загрузить на сервер (rsync/ftp)                           │
│ - Запустить миграции (если есть)                            │
│ - Перезапустить сервисы (если нужно)                        │
└─────────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────────┐
│ ПРОВЕРКА                                                    │
│ - Smoke tests                                               │
│ - Проверка логов                                            │
│ - Мониторинг ошибок (15 минут)                              │
└─────────────────────────────────────────────────────────────┘
                           ↓
┌─────────────────────────────────────────────────────────────┐
│ ЗАВЕРШЕНИЕ                                                  │
│ - Git тег (v1.0.0)                                          │
│ - Обновить документацию                                     │
│ - Уведомить команду                                         │
└─────────────────────────────────────────────────────────────┘

Команды деплоя

Dev → Test

#!/bin/bash
# deploy/push.sh MODULE test

MODULE=$1

# 1. Копировать dev → tst
cp -r dev/modules/$MODULE tst/modules/

# 2. Деплой на test сервер
rsync -av --delete \
  tst/modules/$MODULE/ \
  user@test-server:~/modules/$MODULE/

# 3. Метка
echo "$(date) | deployed to test" > tst/modules/$MODULE/.deployed

# 4. Уведомление
echo "✅ $MODULE deployed to TEST"

Test → Prod

#!/bin/bash
# deploy/push.sh MODULE prod

MODULE=$1

# 0. Подтверждение
read -p "Deploy $MODULE to PROD? (yes): " confirm
if [ "$confirm" != "yes" ]; then
  echo "❌ Cancelled"
  exit 1
fi

# 1. Бэкап текущей prod
mkdir -p arh/$(date +%Y-%m-%d)_pre-deploy/
cp -r prd/modules/$MODULE arh/$(date +%Y-%m-%d)_pre-deploy/ 2>/dev/null || true

# 2. Копировать tst → prd
cp -r tst/modules/$MODULE prd/modules/

# 3. Деплой на prod сервер
rsync -av --delete \
  prd/modules/$MODULE/ \
  user@prod-server:~/modules/$MODULE/

# 4. Метка
echo "$(date) | deployed to prod" > prd/modules/$MODULE/.deployed

# 5. Git тег
VERSION=$(cat prd/modules/$MODULE/VERSION 2>/dev/null || echo "1.0.0")
git tag v${VERSION}-${MODULE}
git push --tags

# 6. Уведомление
echo "✅ $MODULE deployed to PROD"

Откат

#!/bin/bash
# deploy/rollback.sh MODULE

MODULE=$1
BACKUP=$(ls -1t arh/ | grep "pre-deploy" | head -1)

if [ -z "$BACKUP" ]; then
  echo "❌ No backup found"
  exit 1
fi

# 1. Восстановить из бэкапа
cp -r arh/$BACKUP/modules/$MODULE prd/modules/

# 2. Деплой старой версии
rsync -av --delete \
  prd/modules/$MODULE/ \
  user@prod-server:~/modules/$MODULE/

echo "✅ Rolled back $MODULE to $BACKUP"

Поддержка

Мониторинг

Проверки после деплоя

# 1. Сайт доступен
curl -s -o /dev/null -w "%{http_code}" http://prod-server.com
# 200 = OK

# 2. Нет ошибок в логах
ssh server "grep ERROR /var/log/app.log | tail -20"

# 3. Основной функционал работает
curl -s http://prod-server.com/catalog | grep "products"

Регулярные проверки

# Ежедневно
./deploy/status.sh           # Статус деплоев
ssh server "df -h"           # Место на диске
ssh server "free -h"         # Память

# Еженедельно
git log --since="1 week"     # Что изменилось
ls -lh arh/                  # Размер архивов

Обновления

Штатное (app/)

# Drupal
composer update drupal/core
drush updatedb
drush cr

# WordPress
wp core update
wp plugin update --all

# Python
pip install --upgrade -r requirements.txt

# Node.js
npm update

Наше (dev/)

# Обычный процесс
# dev/ → tst/ → prd/

Бэкапы

Что бэкапить

✅ Бэкапим:
- prd/ (перед каждым деплоем)
- База данных (ежедневно)
- Конфиги (при изменении)

❌ НЕ бэкапим:
- app/ (можно переустановить)
- dev/ (есть в git)
- tst/ (можно пересоздать из dev/)

Частота

Ежедневно:   БД
Еженедельно: prd/ целиком
Перед деплоем: текущая prd/

Команды

# Бэкап prd/
tar -czf arh/prd-$(date +%Y-%m-%d).tar.gz prd/

# Бэкап БД
mysqldump -u user -p database > arh/db-$(date +%Y-%m-%d).sql

# Очистка старых (>3 месяцев)
find arh/ -type f -mtime +90 -delete

Документация

Обязательные файлы

project/
├── README.md             Что это, как запустить
├── PROJECT.md            Описание проекта, зависимости
├── STRUCTURE.md          Структура папок
├── CHANGELOG.md          История изменений
└── docs/
    ├── DEPLOYMENT.md     Процесс деплоя
    ├── DEVELOPMENT.md    Процесс разработки
    └── API.md            API документация (если есть)

README.md

# Название проекта

Краткое описание (1-2 предложения).

## Требования

- PHP 8.1+
- MySQL 8.0+
- ...

## Установка

\`\`\`bash
git clone ...
cd project
composer install
\`\`\`

## Запуск

\`\`\`bash
./start.sh
\`\`\`

## Структура

- `app/` - штатное
- `dev/` - разработка
- ...

## Документация

См. [docs/](docs/)

CHANGELOG.md

# Changelog

## [1.1.0] - 2026-02-13

### Added
- Модуль каталога с умной маршрутизацией

### Fixed
- Исправлена ошибка с breadcrumbs

## [1.0.0] - 2026-02-01

### Added
- Начальная версия

Комментарии в коде

/**
 * Парсит URL в контекст для фильтрации.
 *
 * @param string $brand Марка (volvo, scania)
 * @param string $model Модель (fh4, r-6)
 * @return array Контекст для фильтров
 */
public function resolve($brand, $model) {
  // ...
}

Чек-листы

Инициализация проекта

✓ Создать структуру app/arh/dev/tst/prd
✓ Инициализировать git
✓ Создать README.md
✓ Создать PROJECT.md
✓ Создать .gitignore
✓ Первый коммит

Перед разработкой

✓ git pull
✓ Проверить статус (./deploy/status.sh)
✓ Прочитать TODO

Перед коммитом

✓ Тесты пройдены
✓ Линтеры OK
✓ Нет TODO/FIXME
✓ Файлы добавлены (git add)

Перед деплоем на test

✓ Локальные тесты OK
✓ Git коммит создан
✓ README обновлён

Перед деплоем на prod

✓ Тесты на test OK
✓ Бэкап создан
✓ Команда уведомлена
✓ План отката готов

Частые вопросы

Когда создавать tst/?

Создавать если:
- Тестирование >1 дня
- Нужна параллельная разработка
- Требуется история тестирования

Не создавать если:
- Быстрое тестирование (<1 часа)
- Маленький проект
- Можно сразу dev → prd

Как часто деплоить на prod?

Зависит от проекта:
- Критичный: 1 раз в неделю (пятница вечер)
- Средний: 2-3 раза в неделю
- Некритичный: по готовности

Что делать если prod сломался?

1. Откат на предыдущую версию (./deploy/rollback.sh)
2. Проверить что работает
3. Разобраться в чём проблема
4. Фиксить в dev/
5. Тестировать на tst/
6. Деплоить исправление на prd/

Когда чистить arh/?


Применение к разным типам проектов

Drupal

app/core/              Drupal core
app/vendor/            Composer
app/contrib/           Contrib modules
dev/modules/           Custom modules

WordPress

app/wordpress/         WP core
app/plugins/           Plugins
dev/themes/            Custom themes
dev/plugins/           Custom plugins

Python

app/venv/              Virtual env
dev/scripts/           Scripts
dev/modules/           Modules

Node.js

app/node_modules/      NPM
dev/src/               Source
tst/dist/              Build for test
prd/dist/              Build for prod

См. также