Сможет ли EDT решить проблемы коллективной разработки в 1с?
Много видел безпочвенных надежд на EDT и мечты об коллективной разработке в 1с.
Попробуем озвучить проблемы или сценарии использования и понять в силах ли это EDT.
Контекст
- версионный контроль с помощью git (можно hg)
- сервер для git, допустим github, закрытый репозитарий
- конфигурацию для доработки возьмем ERP 2.1 , конфигурация находиться на поддержке с возможностью изменения
- у каждого разработчика есть база клиент-сервер для разработки, для упрощения предположим, что скопированна с рабочей.
- есть одна рабочая база, где работают пользователи, назовем ее prod (размер не больше 200 гиг)
- есть testing, т.е. предрелизная на которой конечный заказчик тестирует реализованый функционал.
- все что попало в testing - в дальнейшем будет обновленно в prod, после обновления база из prod скопируется в testing (testing может выступать база для разработки пэма)
Выгрузка и организация проекта
Инициализация
- Руководитель создает проект в EDT указывает подключение к своей базе, ждем выгрузки из 1с и импортирования в edt.
- После продолжительного ожидания добавляем все файлы в индекс, коммитем и отправляем на сервер github
тут ждет нас первое разочерование, github не поддерживает хранение бинарных данных больше чем в 100 метров, и откажет помещать конфигурацию поставщика.
Локальные варианты серверов для git (gitlab, scm-manager, gogs) чувствительны к таким файлам и им надо много оперативной памяти, на мусоре не поднять.
- Каковы теперь действия разработчика? Клонирует репозитарий, открывает его в EDT, привязывает его базе данных и запускает полную выгрузку конфигурации из EDT в конфигуратор. Ждем
- Разработчик 2 выполняет аналогичные действия у себя. Ждет
Одновременная доработка общего модуля несколькими разработчиками
Тут действует стандартная схема ветвлением из мира git, с merge и разрешение конфликтов, проблем не должно возникать.
Доработка метаданных
В отличии от хранилища, в git не возможно (без доп. усилиий) отказать от изменений конкретных файлов, в результате, когда один разработчик поменял метаданные EDT заставит нас опять запустить полную синхронизацию Ждем
меняем привычку с утра получать все последние изменения из хранилища, на pull из git вечером, для запуска синхронизации на ночь.
Обновление конфигурации поставщика.
- Тут оказываеться, что не правильно инициализировали проект, надо было:
- сначала создать пустую базу на основании конфигурации поставщика (назовем ее origin)
- создать на основании данной базы edt проект отправить данные на сервер, назвав ветку назвать ветку origin
- создать ветку prod на основании origin, указать новую базу для синхронизации и запустить синхронизацию
- закоммитеть наши доработки по отношению к конфигурации поставщика и отправить git сервер.
- Переинициализировали проекты у разработчиков.
- Обновляем базу origin новой поставкой, получаем базу с обновленной конфигурацией поставщика
- В edt переключаемся на ветку origin, указываем новое соеденение к базе (тут возможно, создадим еще один проект, на основании того же git, что-бы каждый раз не указывать новые параметры подключения)
- Импортируем из базы последние изменения. Ждем. Коммитим изменения в ветку origin и отправляем на сервер.
- Переключаемся на ветку dev (ту куда гадят все разработчики, можно и prod это желанию пиэма) и делаем merge с веткой origin
- Решаем все возникшие конфликты
- Запускаем принятие изменений в базу данных после решения. Ждем решаем проблемы с потерянными ссылками в xdto пакетах, формах, предопределнных данных, снова загружаем из edt в конфигурацию и надеямся, что ошибок нет.
- После удачной загрузки, открываем конфигуратор и сохраняем cf файл с разрешенными конфликтами.
- Откатываемся к конфигурации базы данных и в конфигураторе запускаем стандартный диалог обновления конфигурации поставщика.
- Выбираем только обновление конфигурации поставщика и новых объектов метаданных(или удаление). Ждем.
- Запускаем сравнение/объединение с файлом cf ранее сохраненным.
- EDT запускаем загрузку конфигурации, дабы теперь правильно обновился файл привязки метаданных к конфигурации поставщика.
- Коммитим и понимаем, что надо было созадавть ветку pre-merge, т.к. появилось 2 коммита вместо одного.
Доработка внешних обработок.
Пока нечего сказать, не знаю как организована работа с внешними обработками в новой edt.
Но, сейчас, в текущей структуре проекта не предусмотренно место для них. Т.е. необходимо создать еще один git репозиторий, где будут хранитья доработки внешних обработок.
Дополнительно необходимо продумать их рекурсивную сборку, мы ведь с исходниками работаем, а в базу надо подключить именно epf. В текущей реализации для параллельной сборки необходимо базу testing синхронизироват с git и только потом запускать сборку, т.к. могут потерятся внешние ссылки.
Обновление
Переключаемся на ветку prod, делаем merge с веткой dev с признаком --no-ff , получаем список изменений и коммитов и красивое дерево с пониманием что же изменилось. Вариантов обновления несколько:
- В edt указываем базу для сборки prod, запускаем синхронизацию и ждем.
- Второй вариант из базы testing выгружаем cf файл и загружаем его в базу prod (но тут нас ждет сюрприз, необходимо разрешить редактирование конфигурации или быстро снять с поддержки, потому как по другом не загрузиться)
Отключаем пользователей, запускаем обновление конфигурации базы данных.
Запускаем сборку внешних обработок и ручками переподключаем их в базе
В сухом остатке:
Необходимо конфигурацию снимать с поддержки и вести все в отдельных ветках, т.е. с современным развитием рядовых 1с-ников, не оставляйте свои контакты в коде.