Git и 1с как работать

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

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

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

Да ничего особенного: выбираете каталог с исходниками ПО или просто файлами и «говорите» Git, что для этого

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

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

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

К сожалению, у хранилища конфигурации 1С есть определенные недостатки:

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

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

Code review

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

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

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

GitLab

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

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

Итак, мы определились, что будем использовать, как и зачем. Теперь осталось последнее — собрать все воедино:
1) Скачать и установить Git для Windows . После установки не забыть прописать в переменную PATH путь к git. exe, если этого не произойдет при установке.
2) Ознакомиться с содержанием статьи на Infostart , потом скачать OneScript c ресурса и установить движок и скрипты.

3) Развернуть виртуальную машину с GitLab [5], создать пользователей и проект. При создании проекта GitLab напишет вам путь к репозиторию. SSL не нужен внутри, скорее всего выберете доступ по HTTP.

4) Чуть настроим репозиторий. Желательно бы убрать оттуда все, что не содержит код, а именно вносим в файл .git/ info/exclude следующие строки:

Публикация конфигурации 1С на GitHub

Статья показывает, как можно подготовить конфигурацию 1С к публикации в системах версионирования, отличных от хранилища конфигурации 1C. В операции задействован .Net framework и C#, позволяющий аккуратно распределить проект 1С по папкам.

Пример публикации конфигурации на основе старых обновлений БСП четырехлетней давности (с 1.0.7.5 по 1.1.3.1) можно посмотреть по адресу https://github.com/elisy/ssl. Таким же образом теоретически можно публиковать конфигурации в другие системы версионирования. Но, опыт публикации в SVN большого числа измененных файлов был неудачным: SVN-клиент зависал при просмотре лога через Tortoise SVN.

Этап 1: выгрузка конфигурации 1С 8.3 в файлы XML

Начиная с версии 8.3, 1С может выгружать конфигурацию в виде XML-файлов.

Делается это через Конфигурация – Выгрузить конфигурацию в файлы… Нужно указать каталог и нажать ОК. Конфигурация будет выгружена в набор файлов xml, txt, html.

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

На этом можно было бы закончить подготовку конфигурации к публикации, но возникает одна проблема. Все файлы конфигурации будут находиться в одном каталоге. Например, для УТ 11.0.7 файлов будет около 10000 (десяти тысяч) размером примерно 430 Мбайт. Удобней было бы иметь эти файлы разложенными по каталогам, где каждая папка отвечает за файлы одного типа.

Разложить файлы по каталогам поможет специально написанная программа. В данном случае на C#.

Этап 2: распределение файлов XML по папкам

Суть помещения файлов по каталогам сводится к следующему: на основании имени файла, разложенного с разделителем «точка», получается его полный путь с тем же расширением. Так первое слово до точки определяет каталог типа объекта, следующее слово определяет каталог названия объекта внутри типа. И так далее – каждое слово за точкой – новый каталог.

Есть исключения: формы, макеты и помощь. К ним дополнительно в каталог переносится xml с определением формы/макета или помощи из родительского каталога. Подсистемы отличаются тем, что внутри подсистем есть определения подчиненных подсистем. Файлы, начинающиеся на «Configuration.» помещаются в корень.

Код по получению относительного пути будет следующим:

Копирование файла сопровождается проверкой на наличие каталога, куда он копируется (если каталога нет — создается) и проверкой наличия конечного файла (если файл есть – перед копированием удаляется).

Этап 3: публикация на GitHub

После регистрации на GitHub нужно создать репозитарий. В данном случае репозитарий называется ssl.

Для синхронизации локального каталога с сайтом GitHub нужно скачать Windows-клиент с веб-сайта github.com. После установки приложения запускается файл GitHub.exe.

Через настройки (плюс сверху слева приложения) локальный каталог необходимо связать с репозитарием. После этого запущенный клиент GitHub.exe начнет отслеживать изменения каталога автоматически. Выдаст добавленные или измененные файлы.

Отсылка изменений на сервер или получение измененных файлов выполняется через команду Sync – кнопка справа сверху приложения.

Выводы

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

Опыт публикации конфигурации на GitHub добавил в арсенал средств 1С еще один мощный инструмент. Преимущества GitHub по сравнению с хранилищем конфигураций 1С очевидны: ветвления, встроенный багтрэккер, возможность ревизии и обсуждения кода, исправление кода в браузере, отчеты и графики, открытый API.

Не смотря на кажущуюся привлекательность, только практика работы сможет доказать жизнеспособность методики. Хранилище 1С, не смотря на критику, худо-бедно работает годами. Какие сложности скрывает переход на другие системы версионирования можно только догадываться. Возможно, в версиях может быть неудобно отслеживать изменения XML файлов из-за специфики этого формата (см. макет).

1С:EDT и Git: новые возможности командной разработки

Мы уже рассказывали о том, что используем фреймворк Scrum в разработке программных продуктов. Описывали инструменты и технологии, которые применяют Scrum-команды «Компании КомЛайн». В этой статье мы рассмотрим возможности совместной работы в 1С:EDT и Git.

1С:EDT – современная среда разработки, созданная на основе Eclipse, одним из главных достоинств которой является работа с распределенной системой контроля версий Git. Это самостоятельное приложение, которое устанавливается отдельно от платформы.

У 1C:EDT, по сравнению с привычным для разработчиков на языке 1С конфигуратором, есть ряд преимуществ. Отметим только некоторые из них.

1. Несколько проектов — одно рабочее пространство. Представим ситуацию: вы разрабатываете мобильное приложение (это первый проект) и веб-сервис для него в основной базе (второй проект) или же реализуете обмен между двумя конфигурациями. При использовании конфигуратора для работы с каждым проектом вам пришлось бы запустить свой конфигуратор. Это неудобно, одновременно открыто несколько окон, и нужно выполнять дополнительные действия, например, идентифицировать базу, конфигуратор которой открыт. В случае с 1С:EDT, у вас открыто единственное окно, в котором импортированные проекты отображаются в одном дереве метаданных.

2. Встроенные инструменты, например, сервер Apache. В конфигураторе для использования веб-сервисов его необходимо устанавливать отдельно, что требует времени. В 1С:EDT вы видите опубликованные веб-сервисы в самой среде разработки, а не в отдельном окне администрирования веб-сервера.

3. Работа с ошибками и предупреждениями. Каждый раз, меняя конфигурацию или получая из репозитория чьи-то доработки, вы видите ошибки и возможные неполадки.

В модулях и дереве метаданных ошибки и предупреждения визуально подсвечиваются.

В конфигураторе же это реализовано в весьма ограниченном виде и контролируется только при попытке обновить конфигурацию.

4. Контекст рабочего пространства. При закрытии окна 1С:EDT весь контекст сохраняется. Так что при следующем запуске приложения открываются те же самые вкладки, которыми вы пользовались до закрытия.

Но главное преимущество 1C:EDT — это возможность групповой разработки с помощью децентрализованной системы контроля версий Git.

Работа с хранилищем в случае конфигуратора понятна и проста. Но она накладывает ряд ограничений, таких как, например, невозможность редактировать один и тот же модуль одновременно двумя разработчиками. Git, напротив, заточен для командной работы. Тот же самый модуль в 1С:EDT могут разрабатывать сразу несколько программистов: каждый — например, отдельную функцию, а затем автоматически объединить результаты.

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

1С:EDT есть возможность организовать совместную разработку вместе с теми программистами, которые работают в конфигураторе. Для этого им достаточно зайти в 1С:EDT и импортировать изменения из базы, которая используется для разработки — среда сама предложит это сделать. Это важно, учитывая, что часто переход на новую среду разработки в компаниях происходит постепенно.

В случае если у разработчиков возникают проблемы с новой средой, которые не позволяют двигаться дальше, можно закрыть 1С:EDT и открыть базу в обычном конфигураторе. Исключив проблему, вернуться в 1С:EDT и импортировать изменения.

Жизненный цикл разработки в Git в простейшем виде, когда задачу решают 2-3 человека, выглядит так.

Есть master-ветка — основная ветка. Именно здесь хранится версия конфигурации, готовая к производственной эксплуатации. Все, что находится в этой ветке, должно работать точно и быть протестированным.

Предположим, программисты работают над созданием мобильного приложения. Для того чтобы приложение не переставало работать при потере связи с интернетом, необходимо разработать специальную фичу. В этом случае создается копия master-ветки — feature-ветка, в которой будет вестись вся разработка.

Завершив разработку фичи и полностью ее протестировав, программисты сливают feature-ветку с master-веткой, то есть отправляют изменения кода в master.

При слиянии веток 1С:EDT сравнивает конфигурации. Если есть конфликты, которые система сама не может разрешить (например, разработчики написали противоречащий друг другу код, который система не может понять), 1C:EDT откроет редактор сравнения и объединения. В этом редакторе разработчик сам выбирает, какие доработки оставить, а какие — нет.

Подобный процесс разработки приемлем, когда в команде — 2-3 человека. Но когда она расширяется, появляется необходимость в правилах внесения изменений. Соблюдение этих правил позволит не допустить путаницы или возникновения ситуаций, когда один программист ломает наработки другого.

Подытоживая, можно сказать, что среда 1С:EDT благодаря интеграции с системой контроля версий Git предоставляет большие, по сравнению с конфигуратором, возможности. Командная разработка становится проще, время программистов используется эффективнее, хранение рабочих версий приложений и версий, в которых создаются отдельные функциональные возможности — удобнее.

Git и 1с как работать

Статья является переосмыслением и дополнением к предыдущим трудам «Управляем версиями в «1C:Предприятие 8» (Git)» и «Управляем версиями и тестированием «1C:Предприятие 8» (Git, часть 2)». Как оказалось, многие не понимают зачем такие сложности и почему? Попытаюсь ответить на эти вопросы и описать подход git-flow.

Разработка качественных продуктов для «1С:Предприятие 8» довольно большая проблема. Для начинающих программистов и специалистов средней руки вопрос не стоит так остро, они не отвечают за работу огромных, высоконагруженных, сложных и нестандартных механизмов, где иногда часы простоя стоят огромных денег. Естественно все это создается не одним человеком и не за один день, когда случается переход от простых задач к глобальным и цена ошибки велика, вот в этот момент возникают вопросы взаимозаменяемости специалистов, совместное владение кодом и даже просто владение, регистрация и учет изменений, сроки реализации функционала, тестирование, списки приемных тестов и т.д.

Что же мы имеем в «1С:Предприятие 8»

Хранилище конфигурации:

• довольно спорный инструмент (в моем опыте несколько раз хранилище становилось полностью не рабочим);
• совместное удобство работы сомнительное;
• выполнить привязку к трекеру задач нельзя;
• код ревью делать не удобно, да и отметить спорные изменения нельзя;
• нет понятий release, hotfix, feature;
• и многое-многое другое;
• хорошо описано здесь.

Чего же всё-таки хочется

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

Установка Git

Git берем отсюда http://git-scm.com/download. С установкой не должно возникнуть проблем. Как пользоваться Git можно прочесть здесь.

Что такое контроль версий, и зачем он вам нужен?
Система контроля версий (СКВ) — это система, регистрирующая изменения в одном или нескольких файлах с тем, чтобы в дальнейшем была возможность вернуться к определённым старым версиям этих файлов.

Выбираем BITBUCKET.ORG или GITHUB.COM

Регистрируемся в системе для бесплатного хостинга вашего кода. Выделить один из сервисов сложно, мы используем оба. Регистрация довольно простая, да и все вопросы настроек уже описаны сотни раз в интернете.

Что выбрать, и зачем это нужно?
Сервисы позволяют провести код ревью, выполнить объединение, синхронизацию, оповестить трекер задач об изменениях по определенной задаче, выслать извещение участникам проекта и т.д. В каждом сервисе есть свои плюсы и минусы — выбор остаётся за вами.

Необходимые вещи

Хранить в Git бинарные файлы можно, но практической пользы от этого мало, их нужно распаковать в текстовые файлы понятные простому обывателю. С конфигурацией сделать это просто с помощью команды «Выгрузить конфигурацию в файлы…». С внешними обработками и отчетами это сделать сложнее, на помощь приходит сообщество c инструментами V8Commit или precommit1C, последний умеет собирать внешние обработки и отчеты из файлов.

Что выбрать?
Сейчас precommit1C активно развивается и дорабатывается, по моему, выбор очевиден. V8Commit развивается «закрыто» и пока не ясно под какой лицензией будет распространяться в дальнейшем, так же нужно обязательно в commit включать бинарные файлы (*.epf, *.erf).

Когда осилены предыдущие пункты

Примерный результат будет таков (в данном примере bitbucket.org):

К каждой строчке можно оставить комментарий, этот текст придет участникам проекта на почту (можно перенастроить), если это pull-request, только тому кто запросил внести изменения. Красным цветом помечено, что удалено; зеленым цветом, что добавлено; ярко-зеленым, что добавлено новое в этой строке по сравнению с предыдущей версией.

Терминология Git-flow

• fork — использование кодовой базы проекта для старта нового или доработки с последующий объединением;
• pепозиторий — место, где хранятся и поддерживаются какие-либо данные;
• push — отправить\обновить новые или измененные объекты в удалённый репозиторий;
• pull — получить\обновить новые или измененные объекты из удалённого репозитория;
• pull request — запрос на объединение fork c кодовой базой стартового проекта;
• alias — используется для сокращение команд;
• branch — направление разработки, независимое от других;
• master — в данной статье стабильная\рабочая\используемая ветка;
• develop — в данной статье ветка которая разрабатывается и в будущем изменения будут перенесены в ветку master, после успешной демонстрации заказчикам;
• hotfix/number — ветка, которая предназначена для внесения правок напрямую в master, по сути это ветка быстрых исправлений критических ошибок, number — номер задачи трекера;
• feature/number — ветка, которая предназначена для реализации нового функционала, после того как задача предположительно готова — выполняется pull request в ветку develop. При удачном код ревью, выполняется объединение с веткой develop, иначе отсылается на доработку. number — номер задачи трекера;
• code review — проверка кода на оптимальность, соответствия техническому заданию и стандартам http://its.1c.ru/db/v8std.

Git process flow​

Перед тем как включить нового разработчика в команду, ему нужно дать право на чтение необходимого репозитория компании на bitbucket\github и сделать fork с которым ему придется работать в разрезе спринта\продуктового цикла разработки. Обязательно задать email в настройках git, который должен совпадать с email на bitbucket\github для однозначной идентификации при выполнении pull request и для получении обратной связи от черного мастера код ревью.

Если разработка идет по верному пути, нижний слайд понадобиться всего 1 раз.

Позитивные стороны

• Подход серьёзно уменьшает количество ошибок и недоделок;
• Только качественные продукты попадут в работающую систему;
• Такая разработка сводит с ума быдлокодеров;
• Основные процедуры по обновлению можно планировать;
• Всегда можно заглянуть в fork разработчика и вместе навалится на противную задачу;
• Не нужно никого ждать, что кто-то захватил объект в хранилище, каждый работает со своей конфигурацией;
• Всегда быть в курсе изменений используя интеграцию bitbucket\github с slack\hipchat.

Негативные стороны

• Сложность внедрения. Без сторонней помощи тяжеловато, как выход вливаться в тусовку https://github.com/xDrivenDevelopment или посещать тематические мероприятия;
• Как минимум должен быть выстроен правильный процесс разработки (мы используем agile);
• Придется потратится на SSD для каждого разработчика, «Выгрузить конфигурацию в файлы…» не столь быстро работает как бы хотелось;
• Конфликты объединения бывают, придется планировать разработку и разделение на task’s, например, форма\модуль объекта\модуль менеджера\модуль команды и т.д. (У нас задач много, последний конфликт был около 2-х месяцев назад)

Вначале упомянул Redmine, так вот, если при commit добавлять «#номер задачи» (из трекера) и настроить интеграцию с bitbucket\github — можно будет прямо из задачи (на трекере) видеть изменения, какие были сделаны для ее решения. Вот несколько скриншотов. К сожалению, все описать детальней нет времени и сил, но начало положено. Надеюсь после статьи в наших рядах (https://github.com/xDrivenDevelopment) появится больше новых людей с новыми идеями.