Классификация стадий разработки версий ПО (1С)

Исчерпывающее руководство по стадиям разработки, веткам и их соответствиям для конфигураций 1С с расширенным workflow

Введение

Данная классификация описывает полный цикл разработки версий программного обеспечения для конфигураций 1С, включая все стадии разработки, соответствующие им ветки системы контроля версий и правила взаимодействия между ними.

Расширенный workflow включает процессы ежедневной синхронизации, тестирования и возврата на доработку, что отражает реальные процессы в командах разработки.

Основы версионирования в 1С

Формат версии 1С: Редакция.Подредакция.Версия.Сборка

В контексте 1С используется специфическая система версионирования:

  • Редакция (Major) - крупные изменения функциональности, часто с обратной несовместимостью
  • Подредакция (Minor) - значительные новые возможности, сохраняющие обратную совместимость
  • Версия (Patch) - исправления ошибок и небольшие улучшения
  • Сборка (Build) - технический номер, автоматически увеличивающийся при каждом изменении

Релиз - это стабильная версия, готовая для поставки пользователям, которая может соответствовать одной или нескольким сборкам.

Основные (долгоживущие) ветки

Эти ветки являются основой всего процесса разработки и существуют на протяжении всего жизненного цикла проекта.

Ветка Назначение Критерий готовности / "Стабильности"
main (или master, releases) Основная ветка стабильных релизов. Содержит только код, соответствующий публичным релизам, которые работают у пользователей. Соответствует состоянию Публичного Релиза. Каждый коммит в main — это новая редакция, подредакция или версия, которая поставляется пользователям.
develop (или dev, trunk) Ветка разработки для следующего крупного релиза. Сюда сливается весь новый функционал для интеграционного тестирования и стабилизации. Соответствует состоянию Стабильной версии для разработки. Проходит все автоматические тесты и готова к созданию релиз-кандидата.

Вспомогательные (короткоживущие) функциональные ветки

Эти ветки создаются от develop и вливаются обратно в develop после завершения работы.

Тип ветки Создается от Вливается в Назначение и описание
feature/...
(например, feature/integration-with-bank-client)		 develop develop Функциональная ветка для разработки нового модуля. Содержит одну логическую особенность или улучшение. Разработчики ежедневно выполняют синхронизационные слияния с develop для минимизации конфликтов.
bugfix/...
(например, bugfix/order-sum-calculation)		 develop develop Исправление ошибки, найденной в ветке разработки. Используется для срочных правок, не дожидаясь создания релизной ветки.
experiment/... develop (часто никуда) Ветка для исследований и экспериментов. Код из нее может никогда не попасть в develop. Создается, чтобы не засорять основную ветку разработки.

Ветки и стадии подготовки релиза

Этот процесс начинается, когда ветка разработки накопила достаточно функционала для нового релиза.

Стадия / Ветка Создается от Вливается в Назначение и описание
release/...
(например, release/v2.1.0)		 develop develop и main Релизная ветка для стабилизации. На этом этапе запрещено добавлять новый функционал. Допускаются только исправления критических багов, доработки документации и другие действия по подготовке к выпуску. Это соответствует стадии стабилизации.
Релиз-Кандидат (Release Candidate - RC) - - Сборка, создаваемая из релизной ветки. Это версия, которая передается на приемочное тестирование (UAT). Если в RC находят критические ошибки, их исправляют в релизной ветке и собирают новый RC (например, v2.1.0-rc1, v2.1.0-rc2).
Публичный Релиз (Public Release) - - Финальная стадия. Когда релизная ветка стабилизирована и последний релиз-кандидат успешно прошел все проверки, ее финальное состояние сливается в main и помечается тегом (например, v2.1.0). Эта же версия сливается обратно в develop через синхронизационное слияние.

Ветки экстренного обслуживания (Hotfix)

Используются для оперативного исправления критических багов в Публичном Релизе (т.е. в main), когда нельзя ждать следующего запланированного релиза.

Тип ветки Создается от Вливается в Назначение и описание
hotfix/...
(например, hotfix/critical-calculation-error)		 main main и develop Ветка исправлений для экстренного патча. Содержит минимально необходимые изменения для устранения критической проблемы. После завершения исправления ветка сливается как в main (формируя новый патч-релиз), так и в develop (чтобы исправление не было потеряно в следующих релизах).

Сводная таблица соответствия "Стадия → Ветка"

Стадия разработки Соответствующая ветка Версионирование в 1С Критерии завершения
Публичный Релиз main (с тегом версии) Изменение редакции, подредакции или версии Финальная версия развернута у пользователей
Релиз-Кандидат Сборка из release/... Сборка с суффиксом -rcX Успешное прохождение приемочного тестирования
Стадия стабилизации release/... Подготовка к изменению версии Все критические баги исправлены, проведено регрессионное тестирование
Стабильная версия для разработки develop Текущее состояние следующего релиза Прошли все автоматические тесты, готов к созданию релиз-кандидата
Разработка функциональности feature/... Увеличение номера сборки Завершена разработка, проведено код-ревью, пройдено модульное тестирование

Расширенный Workflow с тестированием и синхронизацией

Данный workflow отражает реальный процесс разработки с ежедневной синхронизацией, этапами тестирования и возможностью возврата на доработку.

gitGraph commit id: "v1.0.0" branch develop checkout develop branch feature/user-management checkout feature/user-management commit id: "Базовая структура модулей" commit id: "Формы пользователей" type: HIGHLIGHT checkout develop merge feature/user-management id: "Синхронизация UserManagement 1" tag: "sync-1" checkout feature/user-management commit id: "Логика ролей и прав" commit id: "Интеграция с AD" checkout develop merge feature/user-management id: "Синхронизация UserManagement 2" tag: "sync-2" branch feature/reporting checkout feature/reporting commit id: "Базовые отчеты" checkout develop merge feature/reporting id: "Синхронизация Reporting 1" tag: "sync-3" checkout feature/user-management commit id: "Модульное тестирование" commit id: "Исправление багов" type: HIGHLIGHT checkout develop merge feature/user-management id: "Завершение UserManagement" checkout feature/reporting commit id: "Расширенные отчеты" commit id: "Оптимизация запросов" checkout develop merge feature/reporting id: "Завершение Reporting" branch release/v1.1.0 checkout release/v1.1.0 commit id: "Сборка RC1" commit id: "Интеграционное тестирование" type: HIGHLIGHT commit id: "Исправление критических багов" commit id: "Сборка RC2" commit id: "Приемочное тестирование" type: HIGHLIGHT commit id: "Регрессионное тестирование пройдено ✓" checkout main merge release/v1.1.0 id: "Релиз v1.1.0" tag: "v1.1.0" checkout develop merge release/v1.1.0 id: "Синхронизация релиза v1.1.0" branch hotfix/security-patch checkout hotfix/security-patch commit id: "Исправление уязвимости" commit id: "Тестирование исправления" type: HIGHLIGHT checkout main merge hotfix/security-patch id: "Релиз v1.1.1" tag: "v1.1.1" checkout develop merge hotfix/security-patch id: "Синхронизация хотфикса v1.1.1"

Ключевые особенности расширенного workflow:

Ежедневная синхронизация

Разработчики регулярно выполняют синхронизационные слияния незавершенного функционала в ветку разработки. Это позволяет:

  • Синхронизировать код между разработчиками
  • Уменьшить объем и сложность будущих слияний
  • Раннее обнаружение конфликтов
  • Получать обратную связь от коллег через код-ревью
Многоуровневое тестирование

Каждая значимая сборка проходит через этапы тестирования:

  • Модульное тестирование - проверка отдельных компонентов
  • Интеграционное тестирование - проверка взаимодействия модулей
  • Исправление багов - возврат на доработку при обнаружении проблем
  • Регрессионное тестирование - проверка существующего функционала
  • Приемочное тестирование - успешное завершение тестирования

Релиз-кандидат проходит несколько итераций тестирования и исправления перед финальным релизом.

Гибкий процесс слияния

Процесс слияния включает несколько типов операций:

  • Синхронизационные слияния - перенос незавершенного кода без изменения редакции/подредакции
  • Финальные слияния - завершение функционала с обновлением версии
  • Релизные слияния - перенос стабильного кода в основную ветку
  • Слияния исправлений - экстренные исправления для продакшена

Особенности workflow для конфигураций 1С

Работа с хранилищем конфигурации

В 1С процесс ветвления имеет специфику, связанную с хранилищем конфигурации:

  • Выгрузка изменений - получение актуальной версии из хранилища
  • Загрузка изменений - отправка завершенных задач в хранилище
  • Монолитная конфигурация - большинство изменений вносятся напрямую в основную конфигурацию
  • Файлы конфигурации (.cf) - используются для распространения релизов
  • Файлы обновления (.cfu) - используются для поставки обновлений

Заключение

Представленная классификация охватывает все основные стадии разработки программного обеспечения для конфигураций 1С и устанавливает четкие правила работы с ветками системы контроля версий.

Расширенный workflow с ежедневной синхронизацией и итеративным тестированием позволяет: