Основные принципы
1. Конфигурация поставщика ведется в отдельной ветке (vanilla).
2. Процесс обновления на новый релиз поставщика сводится к тому, чтобы загрузить новый релиз в ветку vanilla, затем слить vanilla в основную ветку разработки (develop, master).
3. Слияние ветки vanilla в основную ветку выполняется через трехстороннее сравнение: vanilla, основная ветка, их общий предок.
Подготовка
Для демонстрации подготовим пример с проектом на ЗУП КОРП. Проект создадим с нуля.
Последовательность шагов
1. В промежуточную базу загружаем .dt из поставки типового релиза. Снимаем конфигурацию с поддержки.
2. Создаем рабочую область EDT. Добавляем проект конфигурации импортом конфигурации из промежуточной базы.
3. Настраиваем групповую разработку из EDT: создаем репозиторий, делаем первый коммит.
4. Выполняем оптимизацию формата хранения файлов проекта.
5. Создаем новую ветку: vanilla.
Промежуточный итог. Ветки master и vanilla на одном коммите и соответствуют типовой конфигурации, наших доработок в проекте еще нет. История репозитория на данном этапе:
6. Внесем в master несколько доработок. Добавим:
- новые объекты (справочник, регистр сведений и пр.)
- новое значение в типовое перечисление
- новые типы в определяемые типы
- новые методы в типовой общий модуль
- свой код в типовые методы общего модуля
В дальнейшем посмотрим, как эти изменения отразятся на процессе обновления на новый релиз поставщика.
Итог. Ветки master и vanilla разошлись. В ветке master теперь типовая конфигурация с нашими доработками, в vanilla - и сейчас и в дальнейшем - только типовая конфигурация. История репозитория:
Далее выполним первое обновление на новый релиз поставщика.
Обновление на новый релиз поставщика
Последовательность шагов
1. Подготовка промежуточной информационной базы.
1.1. Откройте информационную базу в режиме конфигуратора.
1.2. Загрузите информационную базу из файла .dt, входящего в поставку загружаемого релиза поставщика.
1.3. Снимите конфигурацию с поддержки.
2. Подготовка рабочей области EDT для работы с vanilla.
2.1. Создайте отдельную рабочую область для работы с vanilla (если не сделали этого ранее).
2.2. Откройте рабочую область.
2.3. Убедитесь, что репозиторий на ветке vanilla.
2.4. Запомните имя проекта и его версию платформы.
2.5. Удалите проект с очисткой содержимого на диске.
3. Импорт конфигурации нового релиза
3.1. Восстановите проект конфигурации в рабочей области импортом конфигурации из промежуточной базы, в которую ранее загрузили новый релиз. В форме настроек импорта повторите имя проекта и версию платформы.
4. Проект конфигурации и репозиторий.
4.1. Добавьте вновь созданный проект обратно в репозиторий.
5. Работа с изменениями.
5.1. Отмените удаление файлов настроек проекта, расположенных в каталоге <имя_проекта>/.settings (если есть).
5.2. Выполните оптимизацию формата хранения файлов проекта.
5.3. Зафиксируйте изменения. Отправьте коммит в удаленный репозиторий. На этом работа с веткой vanilla завершена.
6. Загрузка обновления в master.
6.1. Откройте рабочую область EDT.
6.2. Убедитесь, что репозиторий на ветке master.
6.3. Актуализируйте состояние отслеживаемых удаленных веток (Получить из origin).
6.4. Запустите слияние с удаленной веткой vanilla.
7. Работа в редакторе сравнения/объединения.
7.1. Отметьте к слиянию объекты, ошибочно пропущенные механизмом слияния.
7.2. Разрешите конфликты слияния (если есть).
7.3. Убедитесь, что механизм слияния не отметил к перезаписи нетиповые доработки.
7.4. Завершите слияние.
7.5. Отправьте в удаленный репозиторий созданный коммит слияния.
8. Проверка слияния (рекомендуется).
8.1. Сравните состояние master и vanilla. Если слияние прошло успешно, в окне сравнения с фильтром трехстороннего сравнения будут только наши доработки.
Итог. В ветке vanilla актуальный релиз поставщика. В ветке master актуальный релиз поставщика с нашими доработками. Дальнейшие обновления на релизы поставщика выполняются по тому же сценарию.
История репозитория:
Дополнительно
1. В примере изменения вносятся в master напрямую. Это упрощение. На практике, как правило, используются feature-ветки, в т.ч. для слияния с vanilla. Плюс, ваше flow может содержать и другие ветки - например, develop.
2. В примере перед загрузкой в vanilla нового релиза проект предварительно очищается. Можно сказать, что мы полностью подменяем состояние проекта в vanilla новым состоянием. Но для загрузки нового релиза в vanilla можно пойти другим путем - импортировать изменения из конфигурации в текущее состояние проекта без его очистки. Тогда запустится процесс слияния конфигурации базы с проектом.
Я рекомендую использовать вариант, описанный в этой статье (с очисткой проекта). Практика показывает, что механизм слияния конфигурации базы с проектом нельзя назвать надежным - некоторые изменения из нового релиза могут "потеряться". Вариант с полной заменой состояния является более "чистым", а также хорошо ложится на автоматизацию через скрипт.
3. В примере новый релиз загружается в промежуточную базу из .dt. Это не обязательно. Если демо-данные в промежуточной базе не нужны, можно использовать загрузку конфигурации из .cf.
4. В примере выполняется оптимизация формата хранения файлов проекта. Это необязательно, но рекомендуется. Оптимизация в данном случае выполняет функцию нормализации файлов. Это имеет смысл, т.к. работа с проектом из EDT и работа через импорт конфигурации из базы всегда будут иметь разный результат на уровне файлов. Оптимизация же во многом приводит файлы проекта к одному "формату". Это позволяет убрать из коммитов фантомные изменения, вызванные импортом конфигурации из базы.
5. В некоторых больших проектах может потребоваться несколько итераций оптимизации формата хранения файлов. Проверить это просто: запустите оптимизацию формата хранения второй раз - если в Git снова есть изменения - это ваш случай. Вероятно, проблема на стороне EDT. Следует учитывать в работе.
Вступайте в нашу телеграмм-группу Инфостарт
