Инструкция для разработчика
Процесс работы над задачей
# 1. Получение задачи
git checkout develop
git pull origin develop
# 2. Создание ветки для задачи
git checkout -b feature/TP-123-новый-отчет
# 3. Разработка с регулярными коммитами
git add .
git commit -m "feat(TP-123): добавлен базовый функционал отчета"
git commit -m "fix(TP-123): исправлены ошибки в расчетах"
git commit -m "chore(TP-123): добавлен обработчик обновления ИБ"
# 4. Синхронизация с develop
git fetch origin
git merge origin/develop
# 5. Push и создание Pull Request
git push origin feature/TP-123-новый-отчет
Правила коммитов
Типы коммитов по стандарту:
feat: Новая функциональность (технический проект)fix: Исправление ошибкиrefactor: Рефакторинг без изменения функциональностиchore: Обновление обработчиков ИБ, версий библиотекdocs: Изменения в документацииtest: Добавление тестов
Формат: {тип}({ID задачи}): {описание}
Пример: feat(TP-123): реализован отчет по продажам за период
Работа с версиями
При добавлении обработчика обновления ИБ:
- Увеличить номер сборки в свойствах конфигурации
- Обновить версию в БСП (если используется)
- Закоммитить одним коммитом с версией и обработчиком
// Версия до: 1.7.0.1
// Версия после: 1.7.0.2
git commit -m "chore: обработчик обновления ИБ для TP-123, версия 1.7.0.2"
Code Review процесс
- Создать Pull Request из feature/* в develop
- Убедиться, что прошли все CI/CD проверки
- Запросить ревью у тимлида/коллег
- Исправить замечания
- После апрува - мерж в develop
Инструкция для тестировщика
graph LR
A[feature/*] --> B[Dev-окружение]
C[develop] --> D[Test-окружение]
E[release/*] --> F[Stage-окружение]
G[hotfix/*] --> H[Hotfix-окружение]
Чек-лист тестирования
Для feature-веток (Dev-окружение)
- Соответствие ТЗ
- Отсутствие regression ошибок
- Работа в различных сценариях
- Проверка граничных значений
- Совместимость с существующим функционалом
Для release-веток (Stage-окружение)
- Полное регрессионное тестирование
- Интеграционное тестирование
- Проверка миграций данных
- Тестирование производительности
- Проверка документации
Для hotfix-веток (Hotfix-окружение)
- Целевое исправление ошибки
- Минимальное регрессионное тестирование
- Проверка на аналогичных данных prod
Работа с системами
# Мониторинг развертываний
- CI/CD пайплайн: https://gitlab.example.com/pipelines
- Dev-окружение: http://dev-1c.example.com
- Test-окружение: http://test-1c.example.com
- Stage-окружение: http://stage-1c.example.com
# Проверка версии в тестовом окружении
- Открыть "О программе"
- Проверить соответствие версии ветке
- Пример: develop → 1.7.0.1, release/1.7.0.0 → 1.7.0.2
Эскалация проблем
При обнаружении бага:
- Критичный баг в release/hotfix → срочно тимлиду
- Баг в feature-ветке → комментарий в PR + задача разработчику
- Баг в develop → создание задачи с приоритетом "Высокий"
Формат описания бага:
- Ветка: feature/TP-123
- Версия: 1.7.0.1
- Шаги воспроизведения: ...
- Ожидаемый результат: ...
- Фактический результат: ...
- Скриншоты/логи: ...
Инструкция для тимлида
graph TB
A[Анализ задач] --> B[Планирование спринта]
B --> C[Распределение по разработчикам]
C --> D[Контроль Code Review]
D --> E[Управление релизами]
E --> F[Мониторинг качества]
Ежедневные обязанности
# 1. Мониторинг открытых PR
gitlab_ci_check:
- Проверить статус всех открытых PR
- Назначить ревьюверов
- Эскалировать заблокированные PR
# 2. Контроль ветки develop
git checkout develop
git log --oneline -10 # Последние коммиты
git status # Статус ветки
# 3. Планирование релизов
git tag -l "v1.7.*" # Последние теги
git log v1.7.0.1..develop --oneline # Изменения с последнего релиза
Процесс принятия решений
Создание release-ветки
Критерии:
- Все запланированные feature в develop
- Пройдено базовое тестирование
- Нет критичных багов
- Документация актуальна
Команда:
git checkout develop
git checkout -b release/1.7.0.0
git push origin release/1.7.0.0
Создание hotfix-ветки
Критерии:
- Подтвержден критичный баг в prod
- Оценено время исправления
- Уведомлены заинтересованные стороны
Команда:
git checkout main
git checkout -b hotfix/1.6.4.8
Инструкция для аналитика
graph LR
A[Сбор требований] --> B[Формулировка ТЗ]
B --> C[Создание задач]
C --> D[Приемка функциональности]
D --> E[Обновление документации]
Формат технического задания
# Технический проект TP-123
## Цель:
Реализация отчета по продажам
## Требования:
### Функциональные:
- [ ] Формирование отчета за произвольный период
- [ ] Группировка по контрагентам
- [ ] Экспорт в Excel
### Нефункциональные:
- Время формирования: < 30 сек
- Совместимость с версией платформы 8.3.18
## Критерии приемки:
- [ ] Отчет формируется за период 1 год без ошибок
- [ ] Группировка работает корректно
- [ ] Экспорт сохраняет форматирование
Работа с Git
# Мониторинг прогресса
# Просмотр всех активных feature-веток
git branch -r | grep feature
# Просмотр изменений в конкретном ТП
git log --oneline --grep="TP-123"
# Просмотр готовности к релизу
git log develop ^main --oneline
Участие в процессе приемки
Чек-лист приемки ТП:
- Функциональность соответствует ТЗ
- Интерфейс удобен для пользователя
- Документация актуальна
- Проведено тестирование
- Нет конфликтов с существующим функционалом
Процесс:
- Тестирование на stage-окружении
- Проверка по критериям приемки
- Подписание акта приемки
- Закрытие задачи в системе
Инструкция для руководителя проектов
graph TB
A[Портфель проектов] --> B[Планирование релизов]
B --> C[Распределение ресурсов]
C --> D[Контроль рисков]
D --> E[Отчетность стейкхолдерам]
Ключевые метрики для мониторинга
Метрики разработки
Качество и релизы
Процесс принятия решений о релизах
# Анализ готовности релиза
git checkout release/1.7.0.0
# Проверить:
# - Количество открытых багов
# - Статус тестирования
# - Результаты приемки
# Команда для выпуска релиза:
git checkout main
git merge release/1.7.0.0
git tag -a v1.7.0.0 -m "Релиз 1.7.0.0"
git push origin main --tags
Инструменты мониторинга
# Дашборды для руководителя:
- GitLab Insights: https://gitlab.example.com/insights
- CI/CD Analytics: https://gitlab.example.com/analytics
- Bug Tracking: https://jira.example.com/dashboard
- Release Calendar: https://calendar.example.com/releases
# Быстрые команды для статуса:
git log --since="1 week ago" --oneline | wc -l # Активность за неделю
git describe --tags --abbrev=0 # Последний релиз
git log v1.6.0.0..develop --oneline | wc -l # Изменения с последнего релиза
Обзор процессов
Общая схема ветвления
graph TB
subgraph A [Типы версий по std709]
A1[Плановая версия]
A2[Исправительная версия]
A3[Технический проект]
end
subgraph B [Ветки Git с версионированием std483]
B1[main/master\n1.6.4.7]
B2[develop\n1.7.0.0]
B3[release/1.7.0.0\n1.7.0.0→1.7.0.1]
B4[hotfix/1.6.4.8\n1.6.4.8]
B5[feature/TP-123\n1.7.0.0+tp]
end
A1 --> B2
A1 --> B3
A2 --> B4
A3 --> B5
B2 --> B3
B3 --> B1
B1 --> B4
B4 --> B1
B4 --> B2
B5 --> B2
Нумерация версий по std483
Формат версии: {Р|РР}.{П|ПП}.{В|ВВ}.{С|СС}
- Р - номер редакции (минимум 1 цифра)
- П - номер подредакции (минимум 1 цифра)
- В - номер версии (минимум 1 цифра)
- С - номер сборки (минимум 1 цифра)
Пример: 1.6.4.7 – 7-я сборка, 4-ой версии, редакции 1.6
timeline
title Жизненный цикл версии в Git по std483
section Редакция 1.7 (develop)
Версия 0 Сборка 0 : Начало разработки feature/TP-123
Версия 0 Сборка 0 : feature/TP-124
Версия 0 Сборка 1 : Добавление обработчика обновления ИБ
Версия 1 Сборка 1 : Релизный кандидат release/1.7.0.1
section Релиз 1.7.0.1 (main)
Версия 1 Сборка 1 : Продуктивный релиз
Версия 1 Сборка 2 : Исправительная версия hotfix/1.7.0.2
section Редакция 1.8 (develop)
Версия 0 Сборка 0 : Новая плановая версия
Общие правила для всех ролей
Коммуникация
- Экстренные вопросы: Telegram-чат "1С-Экстренные"
- Общие обсуждения: Slack #1c-development
- Задачи и баги: GitLab Issues
- Документация: Confluence
Регламент встреч
Ежедневно:
- 10:00 - Daily Standup (15 мин)
Еженедельно:
- Понедельник 11:00 - Планирование спринта
- Среда 15:00 - Обзор архитектуры
- Пятница 16:00 - Ретроспектива
По релизам:
- За 3 дня до релиза - GO/NO GO встреча
- После релиза - Post-Mortem анализ