Технология разветвленной разработки конфигураций

На ИТС появилась статья
http://its.1c.ru/db/v8std#content:2149184358:1

Технология разветвленной разработки конфигураций

Цели внедрения технологии:

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

Плановая версия конфигурации – версия, содержащая существенное развитие функционала, срок выпуска которой назначается заранее.

Исправительная версия – версия, которая выпускается при необходимости срочной публикации исправлений критичных ошибок. В исключительных случаях исправительная версия может содержать какой-то новый функционал (например, доработки, связанные с поддержкой изменения законодательства). Срок выпуска определяется при анализе количества и критичности обнаруженных ошибок плановой версии.

Технический проект – задание на доработку конфигурации. Каждый технический проект имеет четко сформулированную цель и конечный список изменений, которые нужно выполнить, чтобы достигнуть этой цели.

2. Разработка исправительных версий

2.1. Для выпуска каждой исправительной версии создается новое хранилище на основе конфигурации последней выпущенной версии.

Важно – нужно создавать новое хранилище, а не копировать основное!
2.2. В исправительной версии не должно быть объемных доработок конфигурации, в противном случае нужно пересматривать сроки выпуска плановой версии.

2.3. Все закладки в хранилище исправительной версии должны содержать комментарий.

Требования к содержанию комментариев аналогичны требованиям к закладкам в хранилище плановой версии (см. п.3.4).

2.4. Все изменения, которые выполняются в исправительном релизе, должны синхронно повторяться в основном хранилище. Если в исправительном релизе добавляются новые объекты (реквизиты объектов), то переносить изменения нужно исключительно с помощью сравнения/объединения конфигураций, для того чтобы не различались внутренние идентификаторы объектов конфигурации.

2.5. При сборке исправительной версии рекомендуется устанавливать метку с информацией о номере сборки на закладке той версии хранилища, конфигурация которой идет в сборку. Обычно это последняя на момент сборки закладка.

3. Разработка плановой версии

3.1. Разработка плановых версий ведется в основном хранилище конфигурации.

3.2. Закладки в основное хранилище должны осуществляться таким образом, чтобы каждая закладка переводила конфигурацию хранилища из одного рабочего (готового к выпуску) состояния в другое.
Не допускается закладка не полностью отлаженного функционала! Основное хранилище всегда должно находиться в «неразваленном» состоянии, чтобы в любой момент можно быть начать сборку плановой версии.

3.3. В основном хранилище разрешается выполнять следующие работы:

исправление ошибок, не требующих перепроектирования, объемного кодирования и тестирования. Если ошибка требует больших переработок и/или пересмотра проектных решений, то исправление такой ошибки должно вестись в рамках технического проекта. Порядок работы с основным хранилищем должен быть таким же, как и по другим техническим проектам;
встраивание новых версий библиотек;
встраивание полностью отлаженных, прошедших отладочное тестирование проектов;
в исключительных случаях в основном хранилище может вестись разработка некоторых проектов, (например, проектов по массовому рефакторингу).
3.4. Все закладки в основное хранилище должны содержать комментарий.

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

при исправлении ошибки обязательно должен быть указан номер и краткое наименование ошибки в системе баг-трекинга;
при встраивании новой версии библиотеки должно быть указано название библиотеки и точный номер версии библиотеки;
при встраивании технических проектов – номер проекта в системе ведения проектной документации, а также краткое наименование;
при выполнении работ по техническому проекту в основном хранилище комментарий, помимо номера и краткого наименования проекта, должен содержать краткое описание сделанных в этой закладке изменений.
3.5. Все изменения по техническому проекту должны переноситься в основное хранилище за одну закладку. Если необходимо переносить изменения несколько раз, то нужно открывать несколько проектов.

3.6. После переноса изменений в основном хранилище можно исправлять ошибки, наведенные техническим проектом. Для пересмотра проектных решений нужно открывать новый проект.

3.7. При сборке плановой версии рекомендуется устанавливать метку с информацией о номере сборки на закладке той версии хранилища, конфигурация которой идет в сборку. Обычно это последняя на момент сборки закладка.

4. Разработка технических проектов

4.1. Разработка каждого технического проекта ведется в отдельном хранилище.

Порядок создания хранилища проекта описан в приложении 1.

4.2. При постановке хранилища технического проекта на поддержку от основного хранилища, платформа для всех объектов устанавливает правило «Объект поставщика, не редактируется». Для работы над техническим проектом нужно изменить это правило на «Объект поставщика редактируется с сохранением поддержки».

Правило «Объект поставщика редактируется с сохранением поддержки» нужно устанавливать только для тех объектов, которые изменяются при выполнении технического проекта. Правило нужно менять как можно более точечно – например, если изменения в проекте будут затрагивать только форму, то нужно изменить правило только для этой формы, а для объекта, которому эта форма принадлежит, нужно оставить правило «Объект поставщика, не редактируется».

Для изменения правил поддержки нужно захватить только корень конфигурации, захватывать сами объекты не нужно.

Выполнение этих рекомендаций позволит упростить процесс переноса изменений между основным хранилищем и хранилищем тех. проекта.

4.3. Ответственный за технический проект может периодически обновлять конфигурацию хранилища проекта. Периодичность обновления разработчик определяет самостоятельно.

На частоту обновления могут влиять следующие факторы:

затрагивает ли технический проект объекты других ответственных;
проводится ли в данное время рефакторинг общих механизмов;
ведется ли сейчас в основном хранилище массовое исправление ошибок.
Порядок обновления хранилища технического проекта описан в приложении 2.

4.4. После окончания разработки ответственный согласует сроки завершения отладочного тестирования и сроки внесения технического проекта в основное хранилище. Проекты, затрагивающие большое количество объектов рекомендуется вноситься в основное хранилище ближе к сроку окончания разработки, чтобы уменьшить влияние на другие проекты.

Ответственные за другие технические проекты могут попросить перенести сроки внесения в основное хранилище.

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

4.6. Внесение наработок технического проекта в основное хранилище не должно проводить к длительному захвату объектов основного хранилища. Это достигается тем, что сначала хранилище техничесокго проекта обновляется до состояния основного хранилища (по методике, описанной в приложении 2. Если изменений много, то такое обновление может занять достаточно много времени (до нескольких дней) – за это время конфигурация основного хранилища может измениться. Поэтому процесс обновления может быть итеративным – на каждой итерации обновления отличия в конфигурациях будут становиться все ближе к величине изменений, внесенных техническим проектом.

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

Начинать перенос изменений в основное хранилище (захватывать объекты в основном хранилище) следует только тогда, когда конфигурация технического проекта будет отличаться от конфигурации основного хранилища практически только на изменения, вносимые проектом.

4.7. Ответственный за технический проект должен внимательно относиться к внесению изменений в основное хранилище. Нужно помнить, что основное хранилище должно в любой момент времени находиться в состоянии готовности к выпуску плановой версии.

После внесения изменений в основное хранилище разработчики технического проекта совместно с тестировщиками проводят быструю проверку того, что изменения перенесены корректно и не повлияли на работоспособность смежного функционала. Объем проверок и порядок их проведения определяет ответственный за проект.

4.8. После проверки переноса изменений и до закладки изменений в основное хранилище, ответственный обязательно должен запустить проверку конфигурации. Проверку нужно проводить с максимальными настройками.
Закладка изменений в основное хранилище допускается только после того, как будут исправлены все ошибки, выявленные проверкой конфигурацией, которые были привнесены проектом.

4.9. После переноса изменений в основное хранилище ответственный за технический проект удаляет хранилище проекта
--------------------------------------------------------------

Кто-нибудь ведет разработку по такой же технологии?
Чем разработка исправительной версии отличается от технического проекта, если всё равно надо создавать новое хранилище? Плюс к этому "2.4. Все изменения, которые выполняются в исправительном релизе, должны синхронно повторяться в основном хранилище".

Туда же:
2.2. В исправительной версии не должно быть объемных доработок конфигурации
3.3. В основном хранилище разрешается выполнять следующие работы:
исправление ошибок, не требующих перепроектирования, объемного кодирования и тестирования.

Расскажите, как у вас это происходит?