gifts2017

Коллективная разработка на 1С версии 7.7 и Git

Опубликовал Александр (s.nek) в раздел Программирование - Инструментарий

В данной статье я не буду рассматривать работу с системой контроля версий Git, для этого есть специальные ресурсы, например http://git-scm.com/book/ru. Я только расскажу тем, кто привык и любит Git, подружить старую добрую 7-ку и систему контроля версий Git.

Коллективная разработка на 1С версии 7.7 и Git

В данной статье я не буду рассматривать работу с системой контроля версий Git, для этого есть специальные ресурсы, например http://git-scm.com/book/ru. Я только расскажу тем, кто привык и любит Git, подружить старую добрую 7-ку и систему контроля версий Git.

Ни для кого не секрет, что при совместной разработке на 7-ке программисты сталкиваются со множеством проблем:

  1. Диалоги. Если один разработчик работает за компьютером с Windows XP, а другой, например, за компьютером с Windows 7 со включенными темами, то при редактировании модулей документов, обработок и отчетов конфигуратор 1С автоматически сдвигает элементы управления на формах вверх (на 1-2 пикселя) и уменьшает высоту формы.
  2. Не видно удаленных объектов. Когда новые объекты добавляются в конфигурацию, их легко заметить, но когда они удаляются из конфигурации – для того чтобы это увидеть, приходится не старый файл объединять с новым, а новый объединять со старым и смотреть какие объекты были добавлены. 
  3. Хранение изменений. Мне всегда хотелось иметь список изменений, которые я вношу в конфигурацию, чтобы при необходимости сделать откат или посмотреть «как было». Раньше я хранил всю историю в виде MDшных файлов, но это решение не лишено недостатков: надо где-то еще хранить историю изменений в человеческом виде, лишний объем, трудно сравнивать несколько релизов.

Подготовительный этап

Установочный файл Git для Windows http://msysgit.github.io/

Для удобной работы с Git в среде Windows можно использовать надстройку TortoiseGit. https://code.google.com/p/tortoisegit/

Добавим путь к Git в переменную Path.

Сам файл конфигурации является запакованным, его можно декомпилировать в набор текстовых файлов с помощтю утилиты GComp http://1c.alterplast.ru/gcomp/

Нужная версия для работы с Git – 2.2.16 http://www.1cpp.ru/forumfiles/Attachments/gcomp_bin_2_2_16.zip.

Начало работы и немного bat'ников

Скопируем файл 1Cv7.md в папку с GComp.

Распакуем конфигурацию в папку SRC.

gcomp -d

Переименуем папку в Current и создадим там репозиторий Git.

cd Current
git init 

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

git add *.mdp
git add *.1s
git add *.frm
git add *.mxl
git add *.ord
git add *.txt
git add *\*.mdp
git add *\*.1s
git add *\*.frm
git add *\*.mxl
git add *\*.ord
git add *\*.txt

Поскольку такие действия надо будет делать при каждом обновлении конфигурации, то лучше эти команды поместить в bat файл addAllFiles.bat в папке Current

После этого делаем Commit. Так у нас появляется история.

Удаляем исходный MDшник.

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

Обновление локального репозитория

Когда изменения готовы – копируем измененный MDшник в папку с GComp.

Декомпилируем.

Удаляем все файлы из папки Current, которые имеют отношение к конфигурации. Чтобы решить проблему с удалением.

Копируем все файлы из папки SRC в папку Current.

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

Делаем commit. Файлы диалогов *.frm, которые мы не трогали, не меняем (делаем revert в TortoiseGit, чтобы вернуть состояние файлов рабочей копии к состоянию последнего коммита). Это решает проблему с диалогами.

В виде bat'ника это будет выглядеть так:

if not exist = "1Cv7.MD" goto doNothing
del /S .\Current\*.mdp
del /S .\Current\*.1s
del /S .\Current\*.frm
del /S .\Current\*.mxl
del /S .\Current\*.ord
del /S .\Current\*.txt
gcomp -d
del /Q 1Cv7.MD
xcopy .\SRC .\Current /E /I /Y
rmdir .\SRC /S /Q
cd Current
addAllFiles.bat
:doNothing

После этого можно делать push в удаленный общий репозиторий.

Сборка конфигурации

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

gcomp.exe -c -D Current

 

См. также

Подписаться Добавить вознаграждение
Комментарии
1. Евгений Сосна (pumbaE) 17.09.13 18:11
1. А где примеры решения конфликтов?
2. Вроде в openconf есть специальный скрипт для распаковки автоматом текущего md файла? Достаточно вызвать соответствующий макрос.
3. Каким образом обмениваетесь с коллективом?
2. Александр (s.nek) 17.09.13 21:16
1. Конфликты решаются как и в любом другом Git репозитории. У меня их почти не бывает, потому что разработчиков мало и делаем мы обычно разные вещи, которые друг с другом не пересекаются. Т.е. большинство коллизий разрешает сам Git.
2. Возможно. Пока не работал с ним.
3. Обмен может быть через любой удаленный репозиторий Git. Общая папка, веб-сервер, выделенный сервер, работающий по протоколу git. Самый простой вариант, когда разработчиков немного - облачное хранилище: Dropbox или Яндекс.Диск.
3. Алексей (alsoftik) 18.09.13 08:47
Прикольно, неужели 7-ка так еще популярна, не проще перейти уже на 8-ку, ведь там все уже в коробке. И все таки а как вы с md поступаете при одновременно разработке внутри конфы?
4. Александр (s.nek) 18.09.13 09:09
(3) alsoftik, 7ка еще более чем популярна. С точки зрения программиста 8-ка и логичнее, и удобнее во всех отношениях. Но переписывание фич, которыми успела обрасти 7-ка, и переучивание персонала - это непросто.
5. Алексей (alsoftik) 18.09.13 09:27
(4) Да я согласен, что если инструмент работает (конфа на 1С 7.7), всех устраивает и что если переходить на 1С 8 будет намного затратнее и не принесет реальных преимуществ, то лучше и не трогать, мне интересен про файл md, как с ним вопрос решается при желании одновременно с ним поработать нескольким программистам, что касается отдельных файлов (отчетов, обработок), то тут все понятно.
6. Александр (s.nek) 18.09.13 09:42
с md'шником все просто.
1. Делается fetch или pull запрос к общему репозиторию и получается его полная локальная копия. В случае с fetch если были ветки, то их надо еще вручную слить в локальную ветку master
2. Собирается новый md'шник на локальной машине. Потом с ним работает программист стандартными средствами конфигуратора.
3. Когда работа закончена - md'шник снова разбирается и делается commit в локальный репозиторий. Затем делается push в общий.
7. cdr (phsin) 18.09.13 10:07
Спасибо! Очень интересная статья
8. Belomor (Belomor) 18.09.13 11:18
(5) alsoftik, с CVS то же самое, у Александра Белова (abelov.com) эта технология давно работает
9. Alexey (zarius) 18.09.13 13:51
мне одному кажется что тема не раскрыта? затронута лишь верхушка айсберга :) хотя за поднятие темы +
вообще хотелось бы подробнее услышать о самой последовательности работы, сколько разработчиков, как решаются конфликтные ситуации (к примеру конфликт с ИД новых объектов при одновременной работе нескольких разработчиков), как автоматизируете этот процесс кроме bat-ников и т.д.
Gkmy; 1yh1; dour-dead; phsin; +4 Ответить
10. cdr (phsin) 26.04.14 14:18
больше понравился вариант от Satans Claws
God Member
http://www.1cpp.ru/forum/YaBB.pl?num=1310363717/7

батники предполагают использование следующей структуры каталогов:
В каталоге базы есть следующие каталоги:
_Модули - место хранения внешних классов (поддерживается иерархия этого каталога)
SRC - каталог, связанный с репозитарием
SRC\MD - каталог декомпиляции МДшника
SRC\_Модули - каталог декомпиляции внешних классов (иерархия этого каталога поддерживается в соответствии с иерархией каталога _Модули)
<аналогично SRC\_Модули можно сделать каталоги ExtForms|PrnForms для распаковки внешних отчетов/печатных форм>
<можно сделать, например, каталог SRC\Images - куда скидывать изображения>
Корнем репозитария явлется катало SRC

Запускаемые bat-файлы:
decompile.ert - декомпиляция всего
compile.ert - компиляция всего

decompile.bat сам запускает рекурсивный батник decompile_ert.bat; при необходимости, в него же (decompile.bat) дописать вызов батников для ExtForms, PrnForms, Images, etc...
decompile.bat кладется в каталог базы (рядом с МДшником); decompile_ert.bat - в каталог _Модули

compile.bat сам запускает рекурсивный батник compile_ert.bat; при необходимости, в него же (compile.bat) можно дописать вызов батников для ExtForms, PrnForms, Images, etc...
compile.bat кладется в каталог базы (рядом с МДшником); compile_ert.bat - в SRC\_Модули


compile_ert.bat имеет баг: если у внешнего ert-класса (или просто обработки) есть описание, то после компиляции создается пустой каталог с именем ert-шки и файлом описание.txt внутри.
Вероятно, это может иметь последствия при декомпиляции.
11. Cepгей (Gkmy) 17.03.15 14:04
Belomor, раз уж о WinCVS (8) вспомнили - добавлю: введение в коллективную разработку - Фёдор Езеев (один из) основоположников.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа