User Rating: 0 / 5

Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive
 

 Вводные слова о том, что это для тех кто совсем в танке 1С

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

 Основная проблема хранилища – оно не в бесплатном облаке. Для организации удаленной разработки надо создавать сервер с 1Сным программным обеспечением. Есть еще нарекания к производительности при анализе истории изменений. Тут надо отдать должное, что визуализация изменений в хранилище хорошая, т.к. заточена под метаданные конфигурации и выглядит как сравнение/объединение конфигураций. GIT нам не даст сравнения в привычном для 1С`ника виде, но он это сделает быстро и надежно.

 Из самой задачи хранения истории изменений вытекает, что это некая база данных. В GIT такую базу называют репозиторием. Мега плюсом GIT`а является то, что он может работать одновременно с несколькими репозиториями. Это удобно для разработки немного разных решений с общими кусками. Например из репозитория с БСП можно кинуть свежие изменения в репозиторий бухгалтерии и торговли, такие трюки в обычном хранилище не работают. Репозитории бывают как локальные, так и сетевые.

 Т.к. GIT умеет работать только с текстовыми файлами то cf файл нам не подходит. Для этого и появилась возможность выгрузки конфигурации в виде кучки текстовых XML файлов. Историю их изменений и будет отслеживать GIT. На самом деле GIT работает с любыми файлами, но сравнивать он может только тексты.

 

  



 Также хранилище обязывает нас захватывать объекты для начала разработки и вообще подключаться к хранилищу при каждом включении конфигуратора. Вы всегда должны быть на связи с хранилищем, а учитывая скорость его работы – это сложная задачка. Мой опыт говорит, что канал связи с хранилищем должен быть стабильным, т.к. из-за разрыва придется пере подключаться, а это означает открыть закрыть конфигуратор. GIT дает возможность вносить изменения находясь off-line и выкладывать изменения при наличии связи, т.е. сеансово. Вся разработка идет в локальном репозитории, а когда закончили выложили все в сетевой репозиторий. Захватывать объекты в GIT не нужно, при синхронном изменении одного и того же объекта разными разработчиками надо сращивать изменения. Ясное дело, что могут быть конфликты и их разгребать только вручную. Процесс слияния доработок в GIT называется «мержить» (merge – сравнивать). Т.е. по факту это как взять cf файлы со всех разработчиков и сравнением/объединением слить в одну конфу все доработки, но удобнее, т.к. сравнивается только то, что менялось. Это вообще основная прелесть GIT`а, что видим только то, что менялось и обмениваемся не cf файлами по гигабайту, а маленькими xml.

 Под GIT мы будем понимать GIT-клиента, т.е. программу, которая ставится на Вашу рабочую станцию. Программ много, все с разным интерфейсом, но все они сводятся к вызову консольных команд программы git.exe. В данной статье не будет команд, а только щелканье мышкой. Синтаксис команд есть на википедии и много где еще. Для примера мы установим git gui с официального сайта, т.е. это не чья-то поделка, а официальный релиз git от авторов под windows включающий в себя gui.

 Для удаленной работы создают репозиторий в облаке. Самый популярный и почти бесплатный сервис – github.com. Сервисов сейчас много, отличаются ценой и объемом места. На его примере мы и совершим наш учебный поход к взрослым программистам. Т.е. у нас будет локальный репозиторий и облачный.

 Никаких сторонних IDE мы не будем использовать, чтобы сразу не закакать мозги. Сначала только GIT. А в конце я выскажу своё особое мнение об удобстве и о том, когда и зачем этим можно пользоваться.

Устанвока GIT

 Тут все просто, надо зайти на http://git-scm.com/downloads и скачать клиента под Windows.

 установка git

 После установки он запустит консоль, но мы её закроем. В этой статье никаких команд. Мы новички и нам надо попроще. Главное понять принцип работы.

 после установки git для windows откроется консоль

Закрыли все и получили ярлычки на рабочем столе или в пуск. ВСЕ!

 Создание репозитория

 Заходим в нашу базу 1С, разработку в которой мы собираемся вести. Нам надо выгрузить её в файлы. Для этого меню конфигурация/выгрузить конфигурацию в файлы

 1с выгрузка конфигурации в файлы 

В итоге в папке получим кучку файлов. Каждый модуль и форма будут отдельным файлом.

 1С файлы конфигурации выглядят так

Теперь пора запускать то, что мы установили. Для новичков в составе GIT есть приложение с GUI (т.е. оконным интерфейсом). Оно так и называется GIT GUI. Запускаем его.

Ярлык на установленный git

 При старте оно спрашивает нас о местоположении репозитория. Укажем ту самую папку, куда выгрузили конфигурацию и жмем CREATE.

Запуск GIT GUI

 В папке репозитория появится подпапка .git – это и есть база данных с историей. На данный момент в базе нет ни одного файла, поэтому все файлы после создания выведены как измененные. В первый раз их все надо выложить в базу данных репозитория. Процесс выкладывания называется «комитить» (commit). При открытии GIT сканирует каталог и видит кучу новых файлов, которых нет в репозитории, все они для него как измененные. В меню commit выберем пункт «Stage Changed Files To Commit». И все файлы перебегут вниз. Это означает, что мы хотим поместить в репозиторий все обнаруженные GIT`ом изменения. На картинке ниже у меня только один измененый файл, но в первый раз у Вас их будет много (все).

 Еще на картинке я обвел сразу два пункта меню. Stage To Commit – переводит только выделенный в списке файл в состояние к комиту, а не все, как команда описанная выше. Полезно помечать файлы штучно, предварительно глазами оценив изменения. Связано это с отсутствием в конфигураторе блокировок на объекте. Т.е. вы начинаете, например, менять отчет, лезете м модуль отчета и что-то правите, потом предумали и перетащили код в форму, в модуле могут остаться пробелы или переносы – следы изменений. В родном хранилище можно было отменить захват и начать сначала, тут тоже так можно, но сильно дольше.

Поготовка файлов из 1С к комиту. 1C to commit

После того, как мы обозначили, что сейчас полетит в репозиторий мы должны наконец сделать это. Для этого жмем commit.

Файлы готовы к комиту в репозиторий 

В первый раз не надо, а при выкладывании дальнейших изменений GIT требует указания комментария к «комиту». Т.е. нельзя внести изменения без указания комментария. Это тоже крутое отличие от «нашего» хранилища, в котором нет комментариев к выложенным объектам. Теперь не надо писать комментарии в коде в стиле: по задаче №321 от Иванова Л.П. Всю эту лабуду с указанием «зачем и почему» пишем в GIT`е, а не в коде. Да здравствует чистый код.

На одном из своих проектов я устал смотреть на процедуру, в которой комментариев с датами и фамилиями больше чем кода, там всего-то строк 100 было. Но из-за большого числа задач на доработку этого механизма за год в этой процедуре побывала вся команда. Кому приятно смотреть на надпись на заборе «Тут был Вася!», вот я и решил покрасить забор – удалить все комментарии. Процедура стала помещаться на паре экранов, лесенка стала понятной, читабельность выросла. Но потом пришлось нести ответственность за чужие косяки, т.к. в процедуре осталась только моя фамилия. Был бы у нас тогда GIT и код был бы чистым, и автора каждой строки найти без проблем.

 Собственно локальный репозиторий создан – работайте!

 Принцип работы с локальным репозиторием

 Разработку ведем в конфигураторе, как обычно. Закончили, протестировали, все работает, надо комитить.

 Заходим в каталог репозитория и очищаем его, все кроме папки .git! Это важно, т.к. при переименовании объектов метаданных имена файлов становятся другими, а старые сами не удалятся.

 В конфигураторе выгружаем конфу в файлы в наш каталог.

 Открываем GIT. Он сам сканирует каталог и сравнивает все файлы с базой данных. Если он уже открыт, то жмем команду rescan.

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

Все реально измененные файлы ставим в статус к комиту.

Комитим! УРА! Нет не УРА! GIT ругается, что мы не указали комментарий к комиту, я же говорил, что комментарий обязателен! Не забываем про новую культуру работы: комментарии содержащие причины изменений, автора изменений, дату изменений и заказчика изменений пишем в GIT в коммите.

Кладем работу в интернет

Собственно, теперь поговорим о совместной работе нескольких программистов. Детали и нюансы опишу в следующей статье, а пока просто выложим все в сеть.

Для этого надо где-то зарегистрироваться, например, на github.com. Там все просто без sms и рекламы.

В результате у Вас будет адрес репозитория. Открываем GIT, меню Remote/Add.

Подключение git к репозиторию в облаке

В поле name – любое имя, а в поле location – путь как Вам скажут на сайте.

Указываем в какой удаленный репозиторий будем делать push

 Теперь выполним команду Push. Нас спросят в какой remote будем пушить и жмем Push.

Теперь выполним команду Push

 Пушить – выкладывать свои комиты в интернет. Т.е. мы комитим локально, а пушим в сеть. При первом пуше нас попросят ввести логин и пароль учетки от github`а.

 Теперь лезем на сайт и видим, что на нем есть куча файлов нашей конфигурации.

файлы конфигурации 1С выложены на github.com 

Ура! Мы выложили свою работу в общий доступ. Да здравствует Open Source!

 Далее я опустил сложности с тем, что другой разработчик пушнул что-то ранее и надо разгрести конфликты. Мы рассмотрели работу в «одно жало», но думаю это и так много информации для одной лекции.

Выводы, которые уже можно сделать, не забегая вперед

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

Первое – результат трудов лежит на почти бесплатном сервере и всем доступен. Это действительно круто, что есть много сервисов, бесплатно предоставляющие такую услугу. Развернуть свое удаленное хранилище даже на платном хостинге – задачка не простая, связанная с необходимостью установленного сервера хранилищ.

Второе – скорость анализа и отображения истории. Нажимая кнопку «история» в хранилище значений, можно пойти наливать кофе. GITотобразит все сразу. Связано это с тем, что GIT не собирает проект полностью, а потом сравнивает, он сравнивает только версии до и после, файлов участвовавших в комите. 1С так не умеет, она собирает полный cf на момент X и сравнивает его с полным cf файлом на момент Y, что сами понимаете сильно дольше, особенно если в руках ERP, где cf под гигабайт. И делает так 1С даже если между версиями поменялось две строчки в одном модуле.

 Третье – наличие комментариев к комиту. Комментарии к изменениям должны быть в изменениях, а не в коде. Разделение комментариев к коду и к изменениям – это сильно очищает код.

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

Пятое – нет захвата объектов. Правильно это назвать синхронной и асинхронной разработкой. Т.е. в хранилище мы один объект дорабатываем по очереди, а в GIT синхронно. Это не плюс! Это особенность, с которой надо жить и в зависимости от ситуации она может быть, как на руку, так и во вред. При синхронной доработке оба разработчика не протестируют совместный результат. Им нужен арбитр, который, во-первых, «смержит» доработки, а во-вторых, что важно, протестирует совместный результат. В случае с хранилищем, тот, кто последний, тот будет вести разработку с учетом доработок предыдущего и проверять все сразу. Часто люди пишут, что ради плюсов GIT`а выгружают конфу в файлы и комитят в репозитории, но базы при этом подключены к хранилищу, ради асинхронной разработки. Наличие арбитра – сильно удорожает разработку, что приводит к появлению гибридных методик работы.

Шестое – в конфигураторе нет средств работы с GIT`ом. Выгрузка в файлы и комиты в стороннем ПО – огромный минус. Это лишние тыканья мышкой и игра должна стоить свеч. Типовая конфа выгружается крайне долго, а доработав всего 1 объект её надо выгрузить всю. Хранилище, при выкладывании объекта, выкладывает только его. 1С нам дает EDT как инструмент, в котором есть плагины для GIT, но это пипец. Там еще больше танцев с бубнами. На данный момент конфигуратор – самое удобное место для разработки. Люди пишут скрипты для автоматизации этого безобразия, но время выгрузки всей конфы в файлы не исправить никак. В 1С не хватает частичной выгрузки в файлы, чтобы отметить галками что нужно и за секунду выгрузить.

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

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

 

  



Когда это полезно?

Попробую нафантазировать случаи, когда GIT полезнее хранилища.

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

 2.       Если вы задумали автоматизировать обновления. Вы имеете свои доработки и доработки вендора и их надо мержить. Типовые средства Вас всегда заставят много тыкать мышкой, а потом вручную мержить в конфигураторе. В теории можно написать батник (любой другой скрипт), который командами GIT`у сделает многое за 1 клик.

 3.       Если Вы автор open source решения, то тут нет альтернатив GIT`у. Правда, в 1С это не принято.

 4.       Вам надо как-то нормально вести учет задач на доработку, чтобы потом найти концы и составлять документацию. Т.е. вы работает по промышленным стандартам разработки ПО. У GIT`а есть куча синхронизаций со всякими task deskam`и. Многие облачные репозитории предоставляют такие сервисы и у Вас все в одном флаконе. Изменения в коде неразрывны от системы учета задач и документации к продукту. Это дорого, это долго, это сложно, но только так получают качественную разработку. Такой подход всегда требует тестирования на каждом этапе. Пока Ваш кусок кода дойдет до рабочей базы, его 100 раз посмотрят 100 людей и одобрят или отклонят. Это Вам не обновлять рабочую базу динамически с риском порушить базу. Если цена ошибки велика, то контроль и ответственность должны быть, а для этого нужен учет изменений – реальный учет изменений с привязкой изменений к задачам.

 1С лезет в крупный бизнес, а там актуален последний пункт. В мелком бизнесе за мороку с GIT`ом никто переплачивать не будет.

 

Авторизуйтесь пожалуйста