Системы контроля версий Git в 1C:Enterprise Development tools

О чем эта статья

В статье рассмотрены терминология системы контроля версий Git (СКВ), которая используется для механизма групповой разработки конфигурации среды разработки нового поколения 1C:Enterprise Development Tools (EDT). Логически данный материал продолжает тему затронутую в предыдущей статье и показывает какие преимущества дает новая среда разработки при использовании указанной СКВ.

Применимость

Весь материал актуален.

С выходом EDT под Eclipse появилась одна очень интересная и достаточно важная функция, которая, по сути, заменяет стандартное хранилище конфигураций.

Наверняка Вам знакомы основные проблемы данного решения от 1С. В частности, не слишком удобно:

• Работать по сети (сложности возникают с выделением отдельной машины и поднятием веб-сервера);
• Просматривать историю, ввиду очень длительного процесса реализации данного действия;
• Не иметь возможность регистрировать ошибки, вследствие чего программисты просто не фиксируют причины вносимых ими изменений;
• И многое другое.

С другой стороны – в современном IT мире начали активно применять облачные хранилища для совместной разработки. Суть их в следующем:

1. Создается некий проект, например, обработка «выгрузка в xml»;
2. Все исходные коды этого проекта сохраняются в облаке;
3. Эти исходники Вы копируете на свой компьютер и работаете с ними;
4. После того как Вы внесли какой-либо новый функционал, эти изменения Вы переносите обратно в облако.

Действуя по данной схеме, Вы получаете ряд преимуществ:

1. Храните всех данных в облаке. В случае неудачного сохранения или сбоя диска – будут потеряны только последние изменения.
2. Предоставляете доступ для изменения обработки разным людям.
3. Меняете данные в одном модуле одновременно с коллегами. Например, Вам потребовалось изменить в обработке модуль формы документа и добавить новые процедуры, коллеге это тоже понадобилось сделать. В случае конфигуратора Вы бы захватили эту форму, закрыв к ней доступ всем. В нашем случае – это легко реализуется, а при слиянии данных в основные исходники просто добавятся две процедуры.
4. Редактируете исходники непосредственно в браузере. Так, если у вашего коллеги возникла проблема и он не может ее решить, он просто присылает Вам ссылку на этот модуль, и Вы в браузере исправляете код. Коллега затем импортирует изменения.
5. И много всего другого.

Все это следствие того, что хранилище данных в 1С – это централизованная система хранения SVN, в которой есть одно место, где помещены все данные. Модель работы с ней сводилась к блокировке, изменению и разблокировке содержимого. В этом ее отличие от такой распределенной системы хранения данных, как Git.

Обратите внимание на то, что технология Git – это именно технология контроля версий. А вот ресурсы, такие как http://github.com, https://bitbucket.org, – это просто облачные хранилища, а значит, такую технологию можно внедрить и на локальных хранилищах, т.е. поднять сервер у себя в офисе и работать с ним.

Для понимания ознакомьтесь с основными терминами:

Репозиторий – это хранилище файлов в системе контроля версий. Вместе с исходными файлами хранятся и все изменения, происходившие с этими файлами. Т.е. это аналог папки в 1С, где находится хранилище конфигураций. Отличие в том, что эти данные хранятся в облаке.

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

Пуш (push) – эта команда переносит ваши данные из локального хранилища в облачное. Это аналог «Поместить в хранилище». Пока этого не будет сделано, все изменения будут сохранены только локально у Вас на компьютере.

Отслеживаемые файлы и неотслеживаемые файлы – иногда надо подключить какие-то модули для теста, и они не понадобятся в конечном решении. И вот тут происходит разделение всех данных на те, которые система отслеживает и в случае их изменений скорректирует их в облаке, и те, которые не отслеживаются, например, тестовый модуль или дополнительная форма – любой файл, который Вы создали или добавили локально. То же самое касается файлов, которые Вы заменили в самом проекте, например, методом копирования.

Ветка (branch) – это одна из копий вышестоящей ветки, с которой Вы работаете. В свою очередь все начинается с одной главной ветки, которую можно назвать «стволом». У Вас есть основное хранилище, где содержится, скажем так, релиз. Однако все изменения в релиз Вы вносить не будете, поэтому создадите ветку или несколько веток, с которыми будете работать в режиме теста. Туда Вы фиксируете изменения, и только потом эти изменения администратор переносит в master-ветку.

После переноса все участники других веток могут импортировать эти изменения себе. Таких веток и под-веток может быть несколько. Это удобно, если у Вас к примеру 20 участников. Участники разбиваются на подгруппы по 5 человек. Главный администратор переносит изменения из остальных под-веток в основную. При этом у каждой команды есть свои под-ветки третьего уровня, с которыми они работают, и локальный администратор вносит изменения в эти ветки. Таким образом, команды не мешают друг другу, а администратор эффективно отслеживает изменения в каждой подгруппе.

Схематично это выглядит так:

В данном случае объединением веток:

1-2 – занимается главный админ

2-3 – локальный админ (тимлид, руководитель команды)

3-4 – каждый программист отдельно.

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

Кроме этого, если Вы опытный программист, можете пропустить третий уровень. Тогда вносить изменения Вы будете сразу на второй уровень. Обычно об этом команды договариваются заранее.

Форк (fork) – это процесс создания новой ветки путем копирования другой ветки. После создания первой ветки master, ее начинают «форкать» на другие ветки, в свою очередь те ветки «форкают» дальше. Суть форка заключается в том, что Вы копируете одну ветку на основании другой, сохраняя связь с предыдущей в виде логического древа. Если же Вы просто скопируете проект и подключите, тогда останется неясным: откуда он взялся.

Пул (pull) – команда, которая позволяет получить данные из ветки в облаке. Когда Вы «форкнули» какую-то ветку, Вы должны ее скачать к себе в локальное хранилище. Если кто-то сделал в ней изменения, то Вы таким же путем переносите эти изменения к себе.

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

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

Метки (теги) – это аналог бэкапа конфигурации. По сути, метка – это полный снимок всего проекта на конкретный момент времени, который никто никогда не мержит. Т.е. он является эталоном, который изменить не получится. Обычно метки – это предыдущие релизы или же значительные изменения в других ветвях развития.

Теперь попробуем представить некоторые варианты развития и жизни всей разработки. На эту тему есть статья (и ее перевод), картинка оттуда:

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

Develop делится на несколько веток, которые нацелены на расширение функционала. Когда команда решает, что нового функционала достаточно, делается слияние его в ветку разработок (develop) и образуется новая ветка, на основании которой создают ночной билд, т.е. тестовый релиз.

С этого момента ветка с ночным релизом и ветка девелоп начинают жить параллельно, до тех пор, пока на основании ночного билда не получится выпустить релиз. И из ветки ночных билдов мы переносим в девелоп только исправленные баги.

И дальше выпускаем релиз. Потом все по циклу.

Это пример того, как люди ведут разработку с помощью новых (для нас) механизмов. Безусловно, в каждой команде существуют свои варианты и правила ведения разработок. Мы показали одну из возможных направлений работы с версиями.

Итак, пора опробовать реализацию на практике. К примеру, организуйте работу двух людей, имеющих доступ к одной главной ветке и одной под-ветке. Изначально изменения будут вноситься в эти под-ветки, а потом переноситься в центральную. Ваша задача – написать обработку, которая будет иметь три простые формы. Одна из форм станет главной и будет находится в мастер-ветке.

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

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

Также следует отметить, что если Вы по какой-либо причине работаете на старой версии платформы, то лучше использовать платформу версии 8.3.8+, т.к. начиная с нее существенно увеличена скорость загрузки/выгрузки в файлы XML.

Шерстобитов Дмитрий