Сможет ли edt решить проблемы коллективной разработки в 1с?

Сможет ли EDT решить проблемы коллективной разработки в 1с?

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

Контекст

  • версионный контроль с помощью git (можно hg)
  • сервер для git, допустим github, закрытый репозитарий
  • конфигурацию для доработки возьмем ERP 2.1 , конфигурация находиться на поддержке с возможностью изменения
  • у каждого разработчика есть база клиент-сервер для разработки, для упрощения предположим, что скопированна с рабочей.
  • есть одна рабочая база, где работают пользователи, назовем ее prod (размер не больше 200 гиг)
  • есть testing, т.е. предрелизная на которой конечный заказчик тестирует реализованый функционал.
  • все что попало в testing - в дальнейшем будет обновленно в prod, после обновления база из prod скопируется в testing (testing может выступать база для разработки пэма)

Выгрузка и организация проекта

Инициализация

  1. Руководитель создает проект в EDT указывает подключение к своей базе, ждем выгрузки из 1с и импортирования в edt.
  2. После продолжительного ожидания добавляем все файлы в индекс, коммитем и отправляем на сервер github

тут ждет нас первое разочерование, github не поддерживает хранение бинарных данных больше чем в 100 метров, и откажет помещать конфигурацию поставщика.
Локальные варианты серверов для git (gitlab, scm-manager, gogs) чувствительны к таким файлам и им надо много оперативной памяти, на мусоре не поднять.

  1. Каковы теперь действия разработчика? Клонирует репозитарий, открывает его в EDT, привязывает его базе данных и запускает полную выгрузку конфигурации из EDT в конфигуратор. Ждем
  2. Разработчик 2 выполняет аналогичные действия у себя. Ждет

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

Тут действует стандартная схема ветвлением из мира git, с merge и разрешение конфликтов, проблем не должно возникать.

Доработка метаданных

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

меняем привычку с утра получать все последние изменения из хранилища, на pull из git вечером, для запуска синхронизации на ночь.

Обновление конфигурации поставщика.

  1. Тут оказываеться, что не правильно инициализировали проект, надо было:
  2. сначала создать пустую базу на основании конфигурации поставщика (назовем ее origin)
  3. создать на основании данной базы edt проект отправить данные на сервер, назвав ветку назвать ветку origin
  4. создать ветку prod на основании origin, указать новую базу для синхронизации и запустить синхронизацию
  5. закоммитеть наши доработки по отношению к конфигурации поставщика и отправить git сервер.
  6. Переинициализировали проекты у разработчиков.
  7. Обновляем базу origin новой поставкой, получаем базу с обновленной конфигурацией поставщика
  8. В edt переключаемся на ветку origin, указываем новое соеденение к базе (тут возможно, создадим еще один проект, на основании того же git, что-бы каждый раз не указывать новые параметры подключения)
  9. Импортируем из базы последние изменения. Ждем. Коммитим изменения в ветку origin и отправляем на сервер.
  10. Переключаемся на ветку dev (ту куда гадят все разработчики, можно и prod это желанию пиэма) и делаем merge с веткой origin
  11. Решаем все возникшие конфликты
  12. Запускаем принятие изменений в базу данных после решения. Ждем решаем проблемы с потерянными ссылками в xdto пакетах, формах, предопределнных данных, снова загружаем из edt в конфигурацию и надеямся, что ошибок нет.
  13. После удачной загрузки, открываем конфигуратор и сохраняем cf файл с разрешенными конфликтами.
  14. Откатываемся к конфигурации базы данных и в конфигураторе запускаем стандартный диалог обновления конфигурации поставщика.
  15. Выбираем только обновление конфигурации поставщика и новых объектов метаданных(или удаление). Ждем.
  16. Запускаем сравнение/объединение с файлом cf ранее сохраненным.
  17. EDT запускаем загрузку конфигурации, дабы теперь правильно обновился файл привязки метаданных к конфигурации поставщика.
  18. Коммитим и понимаем, что надо было созадавть ветку pre-merge, т.к. появилось 2 коммита вместо одного.

Доработка внешних обработок.

Пока нечего сказать, не знаю как организована работа с внешними обработками в новой edt.
Но, сейчас, в текущей структуре проекта не предусмотренно место для них. Т.е. необходимо создать еще один git репозиторий, где будут хранитья доработки внешних обработок.
Дополнительно необходимо продумать их рекурсивную сборку, мы ведь с исходниками работаем, а в базу надо подключить именно epf. В текущей реализации для параллельной сборки необходимо базу testing синхронизироват с git и только потом запускать сборку, т.к. могут потерятся внешние ссылки.

Обновление

Переключаемся на ветку prod, делаем merge с веткой dev с признаком --no-ff , получаем список изменений и коммитов и красивое дерево с пониманием что же изменилось. Вариантов обновления несколько:

  1. В edt указываем базу для сборки prod, запускаем синхронизацию и ждем.
  2. Второй вариант из базы testing выгружаем cf файл и загружаем его в базу prod (но тут нас ждет сюрприз, необходимо разрешить редактирование конфигурации или быстро снять с поддержки, потому как по другом не загрузиться)
    Отключаем пользователей, запускаем обновление конфигурации базы данных.
    Запускаем сборку внешних обработок и ручками переподключаем их в базе

В сухом остатке:

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

8 Симпатий