Git на службе у разработчика 1С

Рассмотрим практику применения системы контроля версий Git при коллективной разработке решений на платформе 1Сn

Что такое Git?

Git — сейчас одна из самых популярных распределенных систем версий (Version Control System). Если вы знаете данный продукт, то можно сразу перейти к следующей части статьи. Но среди 1С-ников, как показывает практика, очень немногие представляют, что такое Git и зачем он нужен. А те, кто знает, воспринимают данный программный продукт как «что-то такое консольное, старое, линуксовое», и они правы. Интерфейсом Git, мягко говоря, не блещет. Но не за это Git так полюбился разработчикам. Собственно говоря, это одна из самых первых и проверенных временем VCS, используется, в частности, при разработке ядра ОС Linux.nВ настоящее время широкую популярность Git приобрел благодаря развитию проекта GitHub. Что такое GitHub и зачем он нужен, в современном мире знает практически каждый разработчик ПО, который так или иначе связан с языками программирования общего назначения (С++, Java, PHP и т.п.). Да и многим людям, не связанным с разработкой ПО GitHub, бывает знаком, потому как оттуда всегда можно скачать последнюю версию этого самого свободного ПО, в случае если в качестве площадки для коллективной его разработки используется именно GitHub.nОсновной альтернативой данному ресурсу является не менее известный Bitbucket. Но Bitbucket использует стек JIRA для организации локальных депозитариев разработчиков. Какой из них выбирать — каждому на свой вкус. В интернете можно встретить множество дискуссий на эту тему, но основная цель данной статьи не в этом.nМне просто Git оказался более знаком и привычен еще «со школьной скамьи». Кроме того, проекты 1С чаще всего имеют конкретное внутреннее назначение, поэтому размещать их код в публичном репозитории бессмысленно, если не сказать «неправильно» по отношению к заказчику. Поэтому коммерческое ПО должно разрабатываться на внутренних закрытых репозиториях.n

Как Git работает?

Да ничего особенного: выбираете каталог с исходниками ПО или просто файлами и «говорите» Git, что для этогоnnкаталога нужно создать репозиторий (локальный и удаленный — поэтому Git является распределенной системой контроля версий).nДалее работаете с файлами исходников в каталоге, для которого создали репозиторий. Как только вы закончили вносить определенные изменения, которые можно бы сохранить как версию (скомпилировали, запустили, проверили, что в каком-то виде это работает, к примеру), вы «говорите» git commit и сохраняете изменения в репозитории. Чтобы передать изменения в удаленный репозиторий, «говорите» git push.nСобственно, логично, что должна быть и возможность получить в локальном репозитории изменения, сделанные другими разработчиками. Для этого существуют такие операции, как git pull — для получения полного репозитория и git fetch — для получения изменений.nПри получении обновлений может происходить так называемый процесс «слияния» — когда один и тот же файл с кодом исправляли несколько разработчиков. Конфликты слияния появляются и в случае если разные разработчики исправляли одну и ту же строчку в файле с исходными текстами. В связи с этим могут появляться разные ветки разработки. Но это уже более сложные процессы использования систем контроля версий. В 1С есть определенная специфика, которая данный функционал Git делает ненужным.nДа и для общего понимания того, как работает Git и большинство подобных систем контроля версий, разбираться во всех тонкостях нет необходимости. Главное — понимать, что есть локальный и удаленный репозитории. Репозиторий хранит всю историю изменений отслеживаемых файлов. Изменения фиксируются в репозитории командой commit. Локальный репозиторий синхронизируется с удаленным командами push и pull/fetch. Таким образом, у вас есть вся история изменения файлов исходных модулей, включая изменения, сделанные другими разработчиками.n

Для чего он нам нужен?

«Продвинутые» разработчики 1С уже, наверное, задумались: зачем 1С-нику нужен Git, если есть собственная VCS,  встроенная в платформу «Хранилище конфигурации»? На самом деле огромное спасибо компании 1С за данный функционал. Стоит также отметить, что собственная VCS есть далеко не во всех даже более «продвинутых» современных ERP-системах и платформах для разработки бизнес-систем.nnК сожалению, у хранилища конфигурации 1С есть определенные недостатки:n

• Крайне низкая скорость сравнения (сравнение двух версий в хранилище может занять от 1 до 15 минут), что делает данный функционал практически бесполезным.
• Отсутствие ветвлений — весь процесс разработки в 1С строго линейный.
• Отсутствие детальной исторической информации по объектам. По сути дела, для получения такой информации нужно выполнить сравнение версий столько раз, сколько объект изменялся, но и тогда получить обобщенную информацию не удастся.
• Отсутствие многих «плюшек» современных VCS, вроде статистики активности, встроенного багтрекера и т.п.
• Жуткий интерфейс.

Не все эти недостатки можно легко исправить. В частности, добавить ветвления не получится скорее в силу специфики большинства проектов 1С. Но на текущем этапе своего развития хранилище конфигурации 1С позволяет вести коллективную разработку, предотвращая коллизии, при этом не предоставляя в руки руководителя разработки никаких дополнительных инструментов, которыми обычно пользуются разработчики проектов на языках общего назначения.n

Code review

Пожалуй, самым важным процессом, который из-за недостатка инструментария в командах разработчиков 1С практически никогда не практикуется, является так называемый Code review. На тему, для чего это нужно и как это правильнее делать, уже написаны тома литературы. Можно посмотреть, к примеру, перевод популярной провокационной статьи.nПо сути, Code review позволяет сделать лучше следующие моменты:n

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

nn nnЧто нам нужно для Code review? Сразу хочется ответить «только сам код и больше ничего». Но, к сожалению, это не так. Code review хорошо бы проводить только для недавно написанного кода. Кроме того, специфика разработки в 1С заключается в том, что в большинстве случаев решение не разрабатывается «с нуля». Есть достаточно большой объем начального кода, который, как правило, превышает в разы объем разработки, выполняемой проектной командой. Поэтому смотреть в чистом виде все модули не имеет никакого смысла.nТаким образом, нам нужна история изменения по всем модулям, с быстрым доступом и анализом ее. Вот тут как раз и напрашивается использование Git. Осталось только определиться со средством представления итоговой информации, чтобы с ним было удобно работать.n

GitLab

GitLab — открытый проект для развертывания среды, подобной GitHub, для собственной команды разработчиков. Аналогов, конечно, существует немало, но GitLab, пожалуй, является все-таки самым популярным проектом подобного назначения. Для коммерческого использования он, естественно, платный, но суммы вполне приемлемые, даже по скромному бюджету.nВ целом все очень напоминает интерфейс GitHub, поэтому разобраться с ним не составит труда. Скачать и установить GitLab можно с официального сайта [4]. К слову сказать, под Windows дистрибутивов не существует (что не удивительно). Зато существуют так называемые Omnibus Packages, которые делают процесс установки GitLab под ОС Linux делом двух команд в консоли.nЕсть еще более простой вариант установки — скачать готовую виртуальную машину с предустановленным GitLab [5] — на TurnKeyLinux такая есть, что еще раз подтверждает популярность программного продукта.n

Что нужно сделать?

Итак, мы определились, что будем использовать, как и зачем. Теперь осталось последнее — собрать все воедино:n1) Скачать и установить Git для Windows . После установки не забыть прописать в переменную PATH путь к git. exe, если этого не произойдет при установке.n2) Ознакомиться с содержанием статьи на Infostart , потом скачать OneScript c ресурса и установить движок и скрипты.nn3) Развернуть виртуальную машину с GitLab [5], создать пользователей и проект. При создании проекта GitLab напишет вам путь к репозиторию. SSL не нужен внутри, скорее всего выберете доступ по HTTP.nn4) Чуть настроим репозиторий. Желательно бы убрать оттуда все, что не содержит код, а именно вносим в файл .git/ info/exclude следующие строки:n

*.xmln*.htmn*.htmln*.Form

5) Далее пишите что-то вида (инициализируется начальный репозиторий GIT):n

oscript.exe gitsync.os init <каталог хранилища конфигурации> <локальный каталог GIT>

Потом команда:n

oscript.exe gitsync.os < каталог хранилища> <удаленный каталог Git в GITLab, включая логин и пароль> <Каталог репозитория Git>

запускает долгий и мучительный процесс синхронизации хранилища с Git. В течение этого процесса, по сути, будет извлечена и проанализирована каждая версия конфигурации из хранилища. Процесс очень не быстрый, у меня лично занимал несколько недель.nn6) После завершения этого нелегкого и долгого процесса можно зайти в GitLab и наслаждаться вновь открывшимися возможностями.nДля Code review возможности представлены на рис. 1. На рис. 2 представлен так называемый Blame View — возможность системы для определения авторства той или иной строчки кода. Собственно говоря, она делает любимый разработчиками 1С авторский комментарий попросту бессмысленным.nВ итоге, овладев этим инструментом, можно вывести разработку практически на новый уровень, пользуясь теми же возможностями, которые уже давно находятся в распоряжении коллег, ведущих разработку на языках программирования общего назначения.nnnnИсточник: Системный администратор №(158-159)n

Вам нужна установка и настройка git или перенос svn в git, обращайтесь в раздел Контакты