Синхронизация хранилища 1С и git-репозитория с применением OneScript и Gitsync. Методика и пошаговая инструкция для создания скрипта и его регулярного запуска

— Настройка репозитория для работы с большими типовыми конфигурациями
— Алгоритм создания скрипта выгрузки и его исходный код
— Обработка исключительных ситуаций
— Рекомендации по дальнейшему развитию процесса 

 

 

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

Как по своей практике, так и из общения с коллегами знаю, что во многих компаниях есть разработчики 1С, которые хотели бы наладить процесс, подобный описанному в публикациях выше. Но главной сложностью является нехватка полных работающих пошаговых инструкций. Публикаций, описывающих возможности инструментов и преимущества работы с git или даже процесса gitflow много, но работающих инструкций крайне мало. Лучшей пошаговой инструкцией, которую я до сих пор видел является следующий документ  "Развертывание проекта разработки 1С с использованием системы контроля версий Git”   авторства Станислава Ганиева. К сожалению его содержимое было спрятано от индексации поисковиками форматом “docx”.  Рекомендую прочитать его, а также справку по возможностям основного применяемого здесь инструмента на Гитхабе: https://github.com/oscript-library/gitsync 

 

Здесь же хотелось бы дать более развернутую инструкцию, методические и технические советы на основе опыта применения git при работе с типовыми конфигурациями, в том числе 1С: ERP, связи коммитов с задачами в таск-трекере и проведения код-ревью.  

 

Постановка задачи

Нам необходимо

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

 

Выбор инструментов

 

Сейчас для выгрузки хранилища в git есть несколько вариантов:

  • Gitsync. Имеет пожалуй наибольшее количество примеров применения. Поставляется в составе одноименной библиотеки OneScript. Использует ряд других библиотек. Внутри имеет стройный код. Для работы с хранилищем требует доступ на чтение самих файлов хранилища, то есть не поддерживает доступ к хранилищу через tcp и http. Проблема не большая так как доступа на чтение через расшаренную папку будет достаточно. Gitsync будет использован для этой публикации.
  • 1С:ГитКонвертер. Привлекает то, что создается сотрудниками фирмы 1С. Но на данный момент с одной стороны крайне плохо документирован. С другой стороны разобраться в его коде и структурах данных самостоятельно достаточно сложно. Рекомендуется создание отдельной серверной базы для него, чтобы нормально отрабатывало регламентное задание. В данный момент показалось целесообразным разбираться с нем больше в целях обучения, нежели в применении на практике. Кроме того не ясно, будет ли развитию ГитКонвертера уделяться должное внимание с учетом грядущего EDT. И не создавался ли он изначально только для конвертации в формат EDT.
  • Gitter. И его изначальный вариант. Судя по репозиторию проекта и публикациям на Инфостарте разобраться с ним сложности не составит.
  • Самостоятельная выгрузка средствами платформы. Из преимуществ: свобода в оптимизации алгоритмов выгрузки. Например всегда выгружать в каталог репозитория не применяя промежуточный временный каталог как это делает gitsync (в режиме полной, а не инкрементальной выгрузки). Как при этом сопоставлять пользователей хранилища с их e-mail-ами (для последующего просмотра изменений в Gitlab/Fisheye/Bitbucket в привязке к пользователям) и как отслеживать последнюю выгруженную версию хранилища можно посмотреть в исходниках каждого из проектов, перечисленных выше. Разумеется в этом случае уже не обойтись простым скриптом.

 

OneScript — думаю в представлении не нуждается. Кроссплатформенный движок для запуска скриптов, написанных на языке 1С. При использовании VSC есть отладка, есть подсветка синтаксиса, контекстная подсказка. Конечно он лучше чем платформозависимые bat или sh скрипты. И более быстр в освоении для разработчика 1С, чем аналоги на других языках.

Планировщик Windows  — простейший инструмент запуска заданий по расписанию. Начинать лучше именно с него. Если есть необходимость только регулярной выгрузки хранилища без последующих действий, то можно на нем и остановиться. Если же цель поставить процесс сборки, тестирования, подготовки релизов, то нужно применять что-то более подходящее : Jenkins, Bamboo, TeamCity..

Upsource, Gitlab, Jira и Crucible  — это то, на что мы будем ориентироваться, чтобы не рассматривать выгрузку на локальный диск как самоцель. Эти инструменты позволяют организовать командную работу, код-ревью, связь задач с коммитами. Подробно рассматривать их настройку не будем, но затронем с точки зрения результатов выгрузки.

 

 

Ограничение Gitsync на  TCP, HTTP и что с этим делать

 

Gitsync до версии 2.4.3 (последней на данный момент) не позволяет подключаться к хранилищу по tcp и http. Если в качества пути к хранилищу ему указать что-то вроде tcp://host:port/storagename то он просто сообщит о некорректном пути. В качестве пути к хранилищу можно указывать только путь к локальному каталогу или общей папке. В версии 3.0 ожидается возможность подключения по TCP.

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

Также можно копировать/реплицировать хранилище с сетевого/исходного каталога  в специально предназначенный для обработки гитсинком локальный каталог. В этом случае мы получим возможность более свободно работать с этим хранилищем в дальнейшем.

 

 

Структура каталогов и репозиториев

 

Наш скрипт выгрузки будет независим от структуры каталогов. Пути будут передаваться в него как параметры. Но структура каталогов определяет насколько комфортно и правильно будет происходить работа с репозиторием впоследствии.

Определимся с тем, что нам вообще нужно/можно хранить:

  • Исходный код конфигурации
  • Документацию, связанную с конфигурацией
  • Внешние отчеты и обработки
  • Исходный код внешних отчетов и обработок (их выгрузка на исходники).
  • Файлы тестов, если используется тестирование.
  • Сами скрипты запуска выгрузки и скрипты сборок для CI, если он есть.

Теперь подумаем как это удобно и/или правильно хранить

 

Где разместим репозитории и хранилища

Для удобства разместим все хранилища 1C, передаваемые на вход gitsync,  и репозитории git в одном каталоге. Ведь фактически хранилища — это тоже репозитории кода 1С, просто по другому упакованные. Расположение же всех хранилищ 1С в одном каталоге удобно с точки зрения работы с хранилищем 1С через tcp или http. В этом случае их нахождение в одном каталоге — требование сервера хранилищ.

 

Где разместим скрипт выгрузки

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

Но наш скрипт для синхронизации будет универсальным и подходящим под любые репозитории. Фактически он является “библиотечной” сущностью для репозиториев конкретных конфигураций. Поэтому хранить его в репозитории конкретной конфигурации 1С было бы неправильно — пришлось бы копировать один и тот же файл в разные репозитории и менять его также. Представьте себе такую копипасту в репозиториях ERP, ЗУП, БП прочего зоопарка ))

Вообще при использовании git для таких ситуаций придуманы подмодули (submodules). Если кратко — создается отдельный репозиторий для “библиотеки”. Он подключается в другие репозитории как сабмодуль и его после этого можно автоматически обновлять во всех репозиториях, куда он подключен. Таким образом изменения скрипта можно выполнять в одном месте и перед действиями с другими репозиториями обновлять этот “общий код” специальной командой.

Сейчас же примем более простое решение — хранить скрипт выгрузки независимо от репозиториев. Меняется он редко и необходимость версионирования вообще под вопросом. Поместим его в тот же самый общий для хранилищ и репозиториев каталог.

 

Где разместим связанные с конфигурацией файлы

Этот вопрос  уводит нас в сторону коллективной работы непосредственно с репозиторием и сложен для тех, кто еще плотно не работал с git. Поскольку внешние файлы не хранятся в хранилище 1С возможно только независимое от хранилище их помещение в репозиторий разными разработчиками. Для этого вопроса выделен подраздел Хранение внешних обработок, тестов, документации в репозитории этой публикации.

Сейчас же просто примем следующий факт: внутри каждого репозитория будет создан каталог config  для исходников конфигурации и каталог external для внешних файлов.

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

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

 

 

 

Настройки хранилища

 

Работать далее будем только с одним хранилищем, со вторым работа будет идти аналогично (на скриншоте выше наше рабочее хранилище называется ut_storage)

Создадим пользователей Разработчик1 и Разработчик2 , они будут выполнять роль реальных разработчиков.

Gitsync позволяет выгружать версию хранилища средствами платформы и средствами Tool1CD. Tool1CD позволяет очень быстро разбирать сами файлы хранилища без необходимости авторизации в нем. 

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

  • Применение Tool1CD может создать дополнительные трудности при переходе например на Linux. Для OneScritp требуется только Mono, для Tool1CD потребуется еще и Wine.
  • Для использования выгрузки средствами платформы потребуется создать в хранилище служебного пользователя. Через него Gitsync будет получать доступ к истории хранилища. Этому пользователю в настройках прав можно снять все галочки — он необходим только для чтения хранилища, никаких изменений ему разрешать не нужно:

 

На момент публикации выгрузка средствами платформы работает некорректно, но поведение скоро должно быть исправлено: https://github.com/oscript-library/gitsync/issues/153 . Я бы предпочел пользоваться именно платформенной выгрузкой. Для этого во всех командах   gitsync export  нужно добавлять следующие параметры : -useVendorUnload —storage-user Пользователь —storage-pwd Пароль 

То есть вместо команды

gitsync export "C:data
eposut_storage" "C:data
eposut_gitconfig" -tempdir "C:data
epos emp"

использовать такую

gitsync export "C:data
eposut_storage" "C:data
eposut_gitconfig" -tempdir "C:data
epos emp" -useVendorUnload —storage-user deploy —storage-pwd deploy

Сейчас сделаем выбор в пользу выгрузки средствами Tool1CD.  Пользователя deploy удалять не будем. Посмотрим на что повлияет наличие служебного пользователя в дальнейшем.

 

 

Установка Git

 

При установке git рекомендую устанавливать следующие опции: 

Use git and optional unix tools from the Windows Command Prompt

Это позволит удобно использовать не только сам git, но и инструменты вроде grep. Даже если сейчас они не нужны, то потом пригодятся. В частности именно grep из этой поставки предлагается использовать при анализе технологического журнала с помощью регулярных выражений на Windows: Подготовка к 1С:Эксперту: анализ технологического журнала 1С с помощью регулярных выражений 

Checkout as-is, commit as-is 

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

Важно не снимать флаг Enable Git Credential Manager.

Это позволит один раз задать параметры авторизации на гит-сервере для пользователя Windows и затем использовать этого пользователя при автоматическом запуске процесса выгрузки хранилища для отправки изменений на гит-сервер. Ниже, в разделе про регулярный автоматический запуск выгрузки, будет приведен скриншот, как именно используется этот механизм. 

 

 

Настройка репозитория

 

 

Инициализация репозитория

 

Инициализацию репозитория для целей выгрузки хранилища через gitsync можно выполнить через команду gitsync init <ПутьКХранилищу>  <ПутьККаталогу выгрузки>

Однако у нас каталогом выгрузки является подкаталог ut_gitconfig  и если выполнить команду для этого подкаталога, то gitsync сообщит что репозиторий еще не создан и инициализирует репозиторий прямо в каталоге config.

Можно конечно после этого перенести каталог .git на уровень выше — в корневой каталог репозитория.

Но можно поступить и иначе. Сначала выполнить инициализацию репозитория просто средствами git выполнив команду git init  находясь в корне каталога , который мы хотим сделать репозиторием:

 

 

Затем выполнить команду  gitsync init <ПутьКХранилищу>  <ПутьККаталогу выгрузки> 

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

AUTHORS и VERSION :

Назначение этих файлов описано в документации к gitsync. VERSION хранит последнюю успешно выгруженную версию. Если между тегами <VERSION> и  </VERSION>  ничего нет, то при попытке выгрузки хранилища gitsync будет выдавать ошибку.

 

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

 

Если конфигурация крупная,  проект уже имеет большую историю, то имеет смысл не выгружать в git отдельно каждую закладку “с начала времен”. Можно или даже нужно начать с одной из последних версий,  например указав в файле VERSION версию 1213 

 

в репозиторий при запуске gitsync уйдет версия 1214 и коммит в git будет будет содержать все изменения до нее включительно. Это аналогично операции сокращения хранилища до этой версии, только результат этого “сокращения” хранилища будет выгружен в виде одного коммита в репозиторий git.  Дальше пойдет выгрузка версии 1215. И это уже будет полноценный процесс фиксации изменений. Изменения будут зафиксированы относительно версии 1214. Далее будут фиксироваться изменения версии хранилища 1216 относительно 1215.

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

Если будет происходить выгрузка в Gitlab , Github, Bitbucket или Fisheye то файл AUTHORS очень важно заполнить правильными e-mail-ами,. По этим адресам будет производиться сопоставление авторов коммитов и пользователей этих сервисов. В дальнейшем будет продемоснтрировано, что именно e-mail важен для установки этой связи.

 

 Созданный автоматически файл надо подправить:

Во первых, мы не удаляли пользователя deploy из хранилища. Сейчас нам не нужна строка с пользователем deploy — он служебный, и коммитов из под него не будет. Если есть другие служебные пользователи, то их также следует исключить из файла. Затем, используя флаг -check-authors при выгрузке через gitsync мы сможем убедиться, что не обрабатываем коммиты от служебных пользователей.

 Во вторых стоит прописать правильные имена и адреса пользователям:

 

 

 

 

Создание ветки develop

 

На случай последующего выделения ветки master для хранения только тех слепков конфигурации, которые уходят в продуктовую базу или на случай выделения отдельного хранилища для продуктовой базы рекомендую создавать как минимум две ветки: master и  develop (или dev). Конечно можно обойтись веткой master и переехать на develop потом, или наоборот создать только develop. Но мне нравится идея сразу создать задел на будущее развитие системы.

Про то, что такое ветки, для чего нужны и как с ними работать можно прочитать здесь: https://git-scm.com/book/ru/v1/Ветвление-в-Git-Основы-ветвления-и-слияния. Ближайшим аналогом работы с ветками в классическом процессе разработки на 1С является технология разветвленной разработки конфигураций

После инициализации репозитория у нас якобы уже появилась ветка master. Но это не так. Ветка появляется в репозитории git только после первого коммита в нее. Сейчас у git есть только намерение поместить в ветку под именем master какие-то изменения. Если мы переключимся на другую ветку с инструкцией по ее созданию (git checkout -b  имя_ветки) то попытка переключиться обратно на master приведет к ошибке — этой ветки нет :

 

Так как мы упрямо хотели создать ветку master, то выполним теперь команду создания этой ветки (checkout -b).  Выполним команду коммита наших первых изменений в ветку master , тем самым создав ее в репозитории и только затем создадим ветку develop :

 

 

Дальше всю работу будем вести с веткой develolp.  Если остались вопросы о целесообразности создания “метрвой” ветки master, то считайте, что мы ее создали для тренировки ))

 

Настройка .gitignore

 

Файл .gitignore определяет какие файлы не будут отслеживаться гитом, о каких изменениях он не будет сообщать и какие файлы не будут попадать в его историю. Настройку этого файла желательно делать до первой выгрузки конфигурации из хранилища. Потому что если будет произведен хотя бы один коммит с этими файлами, то всё….. они навсегда в истории гита. Они влияют на размер репозитория и есть в его логах. Их всегда можно восстановить из истории.

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

Но лучше сразу не допускать их хранения. Если репозиторий будет использоваться только для быстрого доступа к истории исходного кода и файлов проекта, для достижения публичности кода и/или проведения код-ревью, то рекомендую поместить в файл .gitignore как минимум следующие строки:

 

 

*.cf    — для того, чтобы не хранить в истории конфигурацию поставщика

config/ConfigDumpInfo.xml   —  для таких конфигураций как ERP файл огромен и нам не нужно каждый раз любоваться на его изменения

config/CommonTemplates/**/*.bin   — для того, чтобы не хранить в истории драйверы оборудования.

 

Остановимся на последней строке подробнее.

Почему нельзя написать просто *.bin ?  Потому что XDTO пакеты также выгружаются платформой в файлы с расширением bin. Сюрприз от разработчиков платформы.

В данном же случае исключаются только бинарные файлы из общих макетов, которые в основном являются драйверами оборудования.  Выражение **/*  в gitignore означает “в указанном каталоге и всех его подкаталогах”.

config/CommonTemplates/*.bin  — проигнорирует бин файлы только непосредственно в директории шаблонов,

config/CommonTemplates/**/*.bin — как в самой директории шаблонов, так и во всех ее подкаталогах.

 

Можно настроить более гибкие фильтры на файлы bin если воспользоваться документацией по формату файла .gitignore

Если выгрузка используется для последующей загрузки , то config/CommonTemplates/**/*.bin следует убрать. Возможно что и конфигурацию поставщика стоит оставить.

После создания и заполнения .gitignore необходимо применить изменения. Их нужно сделать как в ветке master, так и в ветке develop.

Первая выгрузка

 

Сделаем ее из консоли. Все по документации по gitsync (https://github.com/oscript-library/gitsync). Но сразу создадим временный каталог C:data
epos emp для выгрузки , чтобы увидеть одну важную особенность gitsync — он не удаляет временные файлы после выгрузки:

gitsync export "C:data
eposut_storage" "C:data
eposut_gitconfig" -tempdir "C:data
epos emp"

gitsync export  — команда выгрузки

"C:data
eposut_storage"
 — выгружаемое хранилище

"C:data
eposut_gitconfig"
  — куда выгружаем

-tempdir "C:data
epos emp"
  — указываем временный катало для выгрузки

 

Начинает работать выгрузка, которая использует временный каталог : 

 

Еще до завершения работы gitsync можно увидеть в мониторе производительности как после выгрузки git, получив от gitsync команду commit,  помещает файлы в свою историю:

 

Первый коммит выполняется очень долго. Десятки тысяч файлов для УТ и сотни тысяч для ERP каждый по отдельности помещается в историю git.  Последующие выгрузки будут происходить много быстрее.

В итоге получаем нашу “закомитченную” выгрузку:

 

 

Временные файлы gitsync

 

После того как выгрузка завершилась можно увидеть что временный каталог с выгрузкой сохранился:

 

На ERP он будет занимать около 5 ГБ. По умолчанию gitsync создает временные каталоги с разными именами в каталоге временных файлов операционной системы. И в случае с Windows они остаются там надолго. Если систему не перезагружать (а ведь сервера редко перезагружаются) этими временными файлами можно забить весь диск. Что собственно и происходит на практике, если не позаботиться об этих файлах самостоятельно. Поэтому мы всегда будем указывать отдельный каталог временных файлов для выгрузки и затем самостоятельно чистить его.

 

 

Настройки git на загрузку больших объемов данных

 

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

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

 

 

 

Кириллические названия файлов

 

По умолчанию git преобразует и экранирует кириллические буквы в именах файлов :

 

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

git config —local core.quotepath false

или в целом для всей системы

git config —global core.quotepath false

 

Последняя команда будет распространяться на все репозитории, для которых явно не задана настройка  core.quotepath ture.

Теперь кириллические символы отображаются правильно:

 

 

Создание или эмуляция удаленного репозитория

 

 

Создаем “эмуляцию”

 

Удаленный репозиторий не обязательно поднимать на серверах компании, взрывать мозг докер-контейнерами и даже не обязательно регистрироваться на Gitlab.com/Github.com.  Git-позволяет использовать другой локальный репозиторий как удаленный. Для нас это будет выглядеть как эмуляция удаленного репозитория. Хотя для Git это вовсе не так и заложено в самой его сути — любой репозиторий, удаленный или находящийся рядом с вашим на том же жестком диске, абсолютно равноправный и каждый из них может быть удаленным (remote) для другого.

Для создания “эмулирующего” удаленного репозитория  выполним в каком либо пустом каталоге команду  git init —bare

Ключ —bare необходим вот для чего. Если создать репозиторий без этого ключа , то он будет обладать рабочей директорией. Рабочая директория — это одно из тех пространств с которым работает git. Файлы из нее перемещаются сначала в область stage а затем коммитятся в историю git. (если еще нет полного понимания понятий working directory , staging area / index , то рекомендую прочитать про это в замечательной книге про git : https://git-scm.com/book/ru/v1/Введение-Основы-Git )

 

Так вот, если в нашем “удаленном” репозитории есть рабочий каталог и выполнено переключение на ветку develop, то отправка в эту ветку из ветки develop другого репозитория через git push работать не будет. Git разумно считает что если выполнен чекаут на эту ветку значит с файлами этой ветки сейчас ведется работа и отказывается их перезатереть. Команда push отработает либо если в удаленном репозитории текущей веткой является отличная от develop, либо если репозиторий создан с ключем —bare. При создании репозитория этот ключ говорит  гиту, что этот репозиторий специальный — без рабочей директории.  Именно так создаются репозитории на githab и gitlab. После создания репозитория прямо в его корне можно увидеть то, что в других репозиториях находится в скрытом каталоге .git :

 

Теперь у нас есть такой каталог, который мы будем указывать как один из удаленных (remote) для нашего репозитория

 

 

Создаем облачный репозиторий

 

Для создания облачного удаленного репозитория зарегистрируемся gitlab. Он предоставляет возможность хранить анонимные репозитории объемом до 10 Гб, что подойдет даже для ERP. Создавать публичный репозиторий для типовых конфигураций 1С разумеется нельзя.

 

Зарегистрируемся под двумя адресами, ранее использованными в файле AUTHORS :

vladimirov_super_puper_dev@mail.ru

aleksandrov_super_puper_dev@mail.ru

 

В GitLab специально дадим пользователям другие имена, чтобы показать связь только через e-mail.

Сначала создаем пользователя vladimirov_super_puper_dev@mail.ru и создаем новый проект-репозиторий:

 

Укажем ему удобное для нас имя, которое будет определять какой полный путь к репозиторию мы будем указывать при назначении его удаленным для нашего репозитория:

 

 

ГитЛаб подсказывает нам как теперь отправить изменения из имеющегося репозитория в этот удаленный репозиторий. Но здесь ошибка, для приватных репозиториев нужно обязательно добавлять пользователя и собачку перед gitlab.com. Правильная команда будет приведена далее:

 

Зарегистрируем теперь второго пользователя с почтой aleksandrov_super_puper_dev@mail.ru, дадим ему безумное имя, чтобы впоследствии показать, что связь устанавливается по почтовым адресам, а не именам :

 

Теперь от имени пользователя-владельца репозитория подключим членов команды к этому репозиторию, поиск пользователя GitLab можно выполнить по его имени :

       

 

Дадим добавленному в члены команды пользователю роль Developer : 

 

                   

Так выглядит один из способов организации совместной работы в GitLab. Подробно про права и правила GitLab сейчас не будем. Цель у нас проста — просто выполнить git push в этот удаленный репозиторий и связать коммиты с авторами и задачей на разработку.

Создадим и задачу, с которой будем осуществлять и проверять связь изменений в нашей системе 1С в дальнейшем:

 

 

Задаче присвоен номер #1:

 

 

 

Связываем наш репозиторий с “удаленными” и отправляем изменения в них

 

Связать наш репозиторий с удаленным можно командой

git remote add origin https://vladimirov_super_puper_dev@gitlab.com/vladimirov_super_puper_dev/ut_git_remote.git

 

На практике именно такую команду и следует выполнять и позже мы откорректируем настройки нашего репозитория для работы только с одним удаленным репозиторием. Но у нас теперь два “удаленных” репозитория один из которых мы создали на своем же жестком диске. Воспользуемся этим, чтобы показать интересную особенность git.

В команде связи с удаленным репозиторием origin — это просто имя-синоним по которому мы будем обращаться к адресу https:///vladimirov_super_puper_dev@gitlab.com/vladimirov_super_puper_dev/ut_git_remote.git. Можно вообще обходиться без этой команды связи и использовать всегда адрес https:///vladimirov_super_puper_dev@gitlab.com/vladimirov_super_puper_dev/ut_git_remote.git .

 

Мы же добавим два удаленных репозитория с разными синонимами:

 

Обратите внимание на запись во втором варианте. Git — из мира Linux и ему часто нужны прямые слэши.

В файле настроек репозитория ut_git.gitconfig при этом появляются такие строки :

 

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

При первой отправке ветки в удаленный репозиторий ее обязательно нужно связать с ее “удаленным” аналогом. Делается это с помощью ключа -u  или его более расширенного варианта —set-upstream  c указанием удаленного репозитория (его синонима или полного пути) и имени удаленной ветки:

 

При отправке изменений в gitlab система запросит пароль и сохранит его в своем хранилище паролей. Нужно сразу сказать что этот пароль может “слетать” с разной периодичностью. Поэтому при настройке выгрузки через планировщик Windows под своим аккаунтом иногда можно обнаружить, что выгрузка перестала работать.

Альтернативой является использование SSH ключа (я еще этим не пользовался). Или выгрузка с применением Jenkins в котором можно сохранять пароль.

 

После ввода паролей в случае с большими конфигурациям 1С начнется длительный процесс отправки:

 

Для определенности далее будем использовать только удаленный репозиторий на Гитлаб назвав его просто origin. Откроем файл .git/config, установим синоним origin для репозитория gitlab  и для ветки develop укажем имя репозитория origin. Конечно, как и для всего в git, для этой операции существует соответствующая команда. Но сейчас мы просто изменим конфигурационный файл:

 

 

 

Пример связи коммитов с задачами и пользователями гит-сервера

 

Сделаем от каждого из наших двух разработчиков помещение изменений в хранилище. Для связи с задачей в GitLab в начале комментария нужно написать #НомерЗадачи.  В конце публикации будет приведен пример работы через Fisheye или Bitbucket , когда решетку ставить не нужно.

Для закладки важно правильно указывать именно комментарий. Его gitsync передает в качестве комментария к коммиту. Метки закладок в хранилище 1С роли не играют.

 

 

 

Выполним уже известную нам команду :

gitsync export "C:data
eposut_storage" "C:data
eposut_gitconfig" -tempdir "C:data
epos emp"

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

gitsync export "C:data
eposut_storage" "C:data
eposut_gitconfig" -tempdir "C:data
epos emp"  -useVendorUnload —storage-user deploy —storage-pwd deploy

 

а после нее отправим изменения на Гитлаб , теперь уже достаточно будет одной простой команды

git push

 

В GitLab появится два коммита имеющих автоматически созданную ссылку на ранее созданную задачу.

Несмотря на различные имена в файле AUTHORS и имена пользователей Гитлаба установлена корректная связь с пользователями Гитлаба через e-mail :

 

Атрибуты коммитов, устанавливаемые gitsync

 

Важной деталью является то, что gitsync устанавливает время коммитов в git в соответсвии со временем закладок в хранилище.

Поэтому, если мы работаем со старым хранилищем и сначала поместили в git файл .gitignore и структуру каталогов, а затем начали выполнять коммиты из старого хранилища, то может так оказаться так, что операции, фактически выполненные позже (выгрузка из хранилища) в логах гита, числятся как операции выполеннные раньше, чем фактически совершенный первый коммит. На скриншоте .gitignore помещен 24 числа, а коммит фактически выполненный после него числится 23-им числом. При этом данные даты являются просто атрибутами коммитов , как и почтовые ящики авторов. При этом git log показывает фактическую хронологию снизу в верх :

 

 

Также в файле config перед коммитом gitsync  подменяет автора , на определенного через файл AUTHORS. Это то, благодаря чему устанавливается корректная связь авторов коммитов пользователями в Fisheye, Gitlab и так далее. Поэтому зайдя в этот файл настрек репозитория можно увидеть такую ситуацию:

 

 

 

Скрипт выгрузки

 

Переходим к написанию скрипта выгрузки.

В него в качестве параметров нам нужно передавать

  • путь к хранилищу конфигурации  (—storage-path)
  • путь к репозиторию (—repository-dir). Но помня, что внутри репозитория есть отдельный каталог для выгрузки будем также передавать…
  • подкаталог для выгрузки  (—configuration-subdir)
  • путь к каталогу временных файлов, для самостоятельной очистки этого каталога по окончанию выгрузки  (—temp-dir)
  • флаг необходимости отправки в удаленный репозиторий в случае успешного завершения прочих шагов (—push-to-remote)

 

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

 

Скрип писался для того, чтобы он мог запускаться в том числе из Jenkins. Если ограничиться планировщиком Windows, как мы сделаем в этой публикации, то параметр управляющий отправкой в удаленный репозиторий будет не нужен. Можно было бы всегда вызывать команду git push , которая ничего бы не сделала, если выгрузка не привела к изменениям и отправлять было бы нечего. Но у Jenkins есть свой шаг — отправка в remote в случае успеха шагов сценария. Поэтому задействуем параметр —push-to-remote. Вызывая скрипт из bat-файла планировщиком Windows будем устанавливать его в ON. Если же вы встроите скрипт в Jenkins в сценарий с последующей отправкой при успехе выгрузки, то параметр надо установить в OFF.

 

Для разбора переданных в скрип параметров удобно применять библиотеку cmdline http://oscript.io/library/package/cmdline 

В ходе выполнения скрипта нам потребуется часто выполнять запуск команд операционной системы. OneScript поддерживает метод ЗапуститьПриложение. Этот метод позволяет получить код возврата. Но нам будет удобно использовать библиотеку 1commands https://github.com/oscript-library/1commands , которая позволяет создавать объект Команда и получать консольный вывод выполняемых команд.

 

Итого в нашем скрипте появляются строки импортирующие библиотеки :

#Использовать cmdline
#Использовать 1commands

 

Чтобы не дублировать код, создавая объект “Команда” каждый раз при запуске команд системы создадим метод, позволяющий не только запускать команды, но и логировать их выполнение выводя сообщения в консоль. Сообщения эти потребуются во время отладки скрипта и при просмотре логов работы скрипта, при его запуске например из Jenkins. Для запуска через планировщик Windows они будут бесполезны.

Также будем передавать в метод ожидаемый код возврата наших команд, и если ожидаемый код возврата не совпадает с фактическим — будем прерывать выполнение.

 

Функция ВыполнитьКоманду(СтрокаКоманды,
РабочийКталог,
ОжидаемыйКодВозврата = 0,
СообщениеДоВыполнения = "",
ОсновноеСообщениеОбУспехе = "",
ОсновноеСообщениеОбОшибке = "",
СообщатьВыводКоманды = Ложь)


ВыводКоманды = "";
Команда = Новый Команда;

Команда.УстановитьРабочийКаталог(РабочийКталог);
Команда.УстановитьСтрокуЗапуска(СтрокаКоманды);
Команда.УстановитьПравильныйКодВозврата(ОжидаемыйКодВозврата);
Команда.ПоказыватьВыводНемедленно(Ложь);


Если ЗначениеЗаполнено(СообщениеДоВыполнения) Тогда
Сообщить(СообщениеДоВыполнения);
КонецЕсли;



Попытка

Команда.Исполнить();
ВыводКоманды = Команда.ПолучитьВывод();

Если СообщатьВыводКоманды Тогда

Сообщить("Выполнена команда: " + СтрокаКоманды);

Если ЗначениеЗаполнено(ВыводКоманды) Тогда
Сообщить("Вывод команды: " + ВыводКоманды);
КонецЕсли;

КонецЕсли;


Если ЗначениеЗаполнено(ОсновноеСообщениеОбУспехе) Тогда
Сообщить(ОсновноеСообщениеОбУспехе);
КонецЕсли;


Исключение

ВызватьИсключение ОсновноеСообщениеОбОшибке + Символы.ПС
+ "Выполнена команда: " + СтрокаКоманды + Символы.ПС
+ "Код возврата " + Команда.ПолучитьКодВозврата() + Символы.ПС
+ "Вывод команды: " + Команда.ПолучитьВывод();

КонецПопытки;



Возврат ВыводКоманды;

КонецФункции



 

Как мы уже видели выше, при отправке изменений на GitLab и, как увидим ниже, при использовании продуктов Atlassian, крайне важно в комментарии корректно указывать номер задачи. Иначе не произойдет связи коммитов с задачами в соответствующих системах учета задач на разработку. Создадим метод — шаблон для проверки комментария. Пока наполним его простейшей проверкой на длину строки. На практике же нужно делать более сложные проверки. Вплоть до обращения через API к Jira/GitLab для проверки наличия задачи по номеру :

// Реализацию необходимо заменить на свою, например проверять наличие # и номера
// задачи в начале комментария для связи коммитов с задачами в таск-трекере
Функция КомментарийКоммитаНекорректен(Комментарий)

КомментарийНекорректен = СтрДлина(Комментарий) < 5;

Возврат КомментарийНекорректен;

КонецФункции

 

Теперь переходим к основному коду скрипта. Вначале распарсим переданные параметры испольуя объекты библиотеки cmdline и сделаем отладочный вывод значений параметров в консоль. Формируя команду запуска gitsync дополнительно зададим параметры -verbose для более подробного вывода и -check-authors , чтобы он проверял наличие автора закладки в файле AUTHORS:
 

КодВозврата = -1;
ЭтотСценарий = ТекущийСценарий();
ТекущийКаталог = ЭтотСценарий.Каталог;
РазделительПути = ПолучитьРазделительПути();


Парсер = Новый ПарсерАргументовКоманднойСтроки();
Парсер.ДобавитьИменованныйПараметр("--storage-path");
Парсер.ДобавитьИменованныйПараметр("--temp-dir");
Парсер.ДобавитьИменованныйПараметр("--repository-dir");
Парсер.ДобавитьИменованныйПараметр("--configuration-subdir");
Парсер.ДобавитьИменованныйПараметр("--push-to-remote");


Параметры = Парсер.Разобрать(АргументыКоманднойСтроки);

ПутьКХранилищу = Параметры["--storage-path"];
КаталогРепозитория = Параметры["--repository-dir"];
КаталогФайловКонфигурацииВнутриРепозитория = КаталогРепозитория + РазделительПути + Параметры["--configuration-subdir"];
ПутьКоВременнымФайлам = Параметры["--temp-dir"];
ОтправлятьВУдаленныйРепозиторий = ВРег(Строка(Параметры["--push-to-remote"]));


КомандаЗапускаGitsyncШаблон =  "gitsync export ""%1"" ""%2"" -limit 1 -tempdir ""%3"" -verbose on -check-authors";

КомандаЗапускаGitsync = СтрШаблон(КомандаЗапускаGitsyncШаблон,
ПутьКХранилищу,
КаталогФайловКонфигурацииВнутриРепозитория,
ПутьКоВременнымФайлам);



// Для сценариев Jenkins самостоятельно выполняюдих отправку изменений параметр нужно задавать как OFF

Если ОтправлятьВУдаленныйРепозиторий = "ON" Тогда
ОтправлятьВУдаленныйРепозиторий = Истина;
ИначеЕсли ОтправлятьВУдаленныйРепозиторий = "OFF" Тогда
ОтправлятьВУдаленныйРепозиторий = Ложь;
Иначе
ВызватьИсключение "Должен быть задан параметр --push-to-remote ON или --push-to-remote OFF";
КонецЕсли;



// Вывод переменных

Сообщить("--------------------------------------------------------");
Сообщить("ПАРАМЕТРЫ ИСПОЛНЕНИЯ ПОЛУЧЕННЫЕ ПО ПАРАМЕТРАМ КОМАНДНОЙ СТРОКИ:");
Сообщить("ПутьКХранилищу = " +ПутьКХранилищу);
Сообщить("КаталогРепозитория = " + КаталогРепозитория);
Сообщить("КаталогФайловКонфигурацииВнутриРепозитория = " + КаталогФайловКонфигурацииВнутриРепозитория);
Сообщить("ПутьКоВременнымФайлам = " + ПутьКоВременнымФайлам);
Сообщить("КомандаЗапускаGitsync = " + КомандаЗапускаGitsync);
Сообщить("ОтправлятьВУдаленныйРепозиторий = " + Строка(ОтправлятьВУдаленныйРепозиторий));
Сообщить("--------------------------------------------------------");

 

Параметр  -limit 1 в команде запуска gitsync заставляет его обработать только одну следующую закладку в хранилище. Он играет важную роль — позволит нам проверять комментарий каждой закладки в отдельности и останавливаться, если комментарий к ней неверен. Также он позволит добиться отправки коммита в удаленный репозиторий и только потом, при следующем запуске скрипта, перейти к следующей закладке в  хранилище. Это особенно важно, если код-ревью или тестирование является частью процесса разработки и проводится до подготовки кода к релизу. Если параметр не передать, то gitsync будет выгружать все закладки, накопившиеся с прошлого запуска. На ERP выгрузка может занимать от 15 минут до 1 часа. Если за час несколько разработчиков сделало несколько коммитов, то ждать несколько часов, прежде чем изменения пойдут на ревью или тестирование не эффективно. Отправка коммитов по очереди позволяет распараллелить процесс выгрузки, ревью и тестирования.

 

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

// Создаем каталог временных файлов, если он не существует

ОбъектПроверкиСуществованияКаталога = Новый Файл(ПутьКоВременнымФайлам);

Если НЕ ОбъектПроверкиСуществованияКаталога.Существует() Тогда
СоздатьКаталог(ПутьКоВременнымФайлам);
КонецЕсли;


Если НЕ ОбъектПроверкиСуществованияКаталога.Существует() Тогда
ВызватьИсключение "Не удалось создать каталог временных файлов "+ПутьКоВременнымФайлам;
КонецЕсли;

Переключимся на ранее созданную ветку develop на случай если в репозитории по какой-то причине велась работа с другой веткой. Например мы смотрели изменения в ней. Если переключение не удалось, то код возврата будет не равен 0 и мы прервем выполнение.

// Переключаемся на ветку разработки

ВыполнитьКоманду("git checkout develop",
КаталогРепозитория,
0,
"",
"Переключились на ветку develop",
"Не удалось переключиться на ветку develop",
Истина);

 

Перейдем к вопросу проверки корректности комментария в процессе выполнения скрипта.

Gitsync имеет параметр -stop-if-empty-comment. Однако этот параметр не позволит нам обрабатывать появление некорректного комментария самостоятельно. Кроме того нам нужно не просто проверять комментарий на пустоту, но и например проверять правильность указания номера задания в нем, его длину , формат и т.д. Затем можно добавить отправку оповещения на почту при обнаружении ошибок.

Можно использовать хуки https://git-scm.com/book/en/v2/Customizing-Git-Git-Hooks. Но для этого надо научиться работать с хуками и кроме того разделить логику работы алгоритмов между скриптом и хуком.

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

Комментарий будем получать как консольный вывод команды  git log -1 —pretty=format:"%s”

Исправление ситуации с неверным комментарием можно провести одним из упомянутых зеленым текстом способов :

 

// Проверка на пустой комментарий предыдущего коммита. В gitsync есть флаг -stop-if-empty-comment,
// но через собственную проверку мы получаем возможность обрабатывать факт пустого комментария по своему
// Например отправить письмо ответственному сотруднику
//
// После выявления ошибки последний комментарий необходимо исправить вручную, возможные варианты действий:
// 1) непосредственно через git командой git commit --amend, затем необходимо выполнить push вручную
// 2) исправив комменентарий в хранилище, откатить последний коммит (сделав обратный последнему) через
//    команду git revert HEAD --no-edit, одновременно с этим будет уменьшена версия в файле VERSION,
//    после чего можно будет провести повторную выгрузку

КомментарийПоледнегоКоммита = ВыполнитьКоманду("git log -1 --pretty=format:""%s""", КаталогРепозитория);

Если КомментарийКоммитаНекорректен(КомментарийПоледнегоКоммита) Тогда

ВызватьИсключение "Последний коммит создан с пустым или слишком коротким комментарием.
|Выгрузка последующих коммитов из хранилища преостановлена.";
КонецЕсли;

 

Теперь перейдем к вопросу проверки наличия изменений после отработки gitsync. Если новых закладок в хранилище не было, то никаких ошибок выгрузки не будет. Код вовзрата будет 0. Можно было бы делать push в remote и в этом случае. Но что если мы захотим подключить следующий шаг — запуск сборки, тестирования  и т.д? Целесообразно проверять есть ли изменения. Они будут если хеш последнего коммита до запуска выгрузки и хеш последнего коммита после запуска выгрузки отличаются. Поэтому перед запуском выгрузки получим хеш последнего коммита и после выгрузки сравним его с новым.

Хеш будем получать как консольный вывод команды  git log -1 —pretty=format:"%H”

ХешПоследнегоКоммитаДоВыгрузки = ВыполнитьКоманду("git log -1 --pretty=format:""%H""", КаталогРепозитория);
Сообщить("Хеш последнего коммита до выгрузки = " + ХешПоследнегоКоммитаДоВыгрузки);


// Запускаем gitsync
ВыполнитьКоманду(КомандаЗапускаGitsync,
КаталогРепозитория,
0,
"Запускаем gitsync",
"",
"Выполнение gitsync завершилось с ошибкой",
Истина);


// Проверка на пустой комментарий после нового коммита
КомментарийПоледнегоКоммита = ВыполнитьКоманду("git log -1 --pretty=format:""%s""", КаталогРепозитория);

Если КомментарийКоммитаНекорректен(КомментарийПоледнегоКоммита) Тогда

ВызватьИсключение "Текущий коммит создан с пустым или слишком коротким комментарием.
|Отправка в удаленный репозиторий коммитов с таким комментарием запрещена.";
КонецЕсли;


// Проверка на новый коммит в репозитории
ХешПоследнегоКоммитаПослеВыгрузки = ВыполнитьКоманду("git log -1 --pretty=format:""%H""", КаталогРепозитория);
Сообщить("Хеш последнего коммита после выгрузки = " + ХешПоследнегоКоммитаПослеВыгрузки);


Если ХешПоследнегоКоммитаДоВыгрузки = ХешПоследнегоКоммитаПослеВыгрузки Тогда

// Вызываем исклюение, иначе шаг выполнения этого скрипта в Jenkins будет считаться
// успешным и далее пойдет отправка в удаленный репозиторий средствами Jenkins.
// Далее будет  подключаться автотестирование. Если отправлять нечего, то последующие
// шаги в Jenkins, включая автотестирование выполняться не должны.

// Для уверенности в том, что отключение вызова исключения не приведет к попытке
// отправки в удаленный репозиторий, установим флаг отправки в Ложь

ОтправлятьВУдаленныйРепозиторий = Ложь;
ВызватьИсключение "В резульате выгрузки в репозитории не было выполнено никаких изменений,
|отправка изменений в удаленный репозиторий не будет выполнена";

КонецЕсли;

 

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

// Отправляем в удаленный репозиторий

Если ОтправлятьВУдаленныйРепозиторий Тогда

ВыполнитьКоманду("git push origin develop",
КаталогРепозитория,
0,
"Выполняем отправку изменений на удаленный репозиторий",
"Выполнена отправка коммита в удаленный репозиторий",
"Не удалось выполнить отправку в удаленный репозиторий");

КонецЕсли;


// Удаляем временные файлы

УдалитьФайлы(ПутьКоВременнымФайлам);
Сообщить("Выполнено удаление временных файлов");

 

ВАЖНО!  Хорошей практикой, а иногда и необходимостью, является выполнение команды git pull  (что равносильно последовательному выполнению git fetch и git merge) перед выполнением git push. Она позволит сначала получить актуальные изменения из удаленного репозитория и остановиться, если перед отправкой потребуется ручное вмешательство и объединение изменений. Но в данном случае мы только отправляем в удаленный репозиторий изменения и никогда не принимаем их из него, поэтому git pull не нужен. Если же работать в репозитории и с внешними файлами проекта, то эту команду будет нужно добавить.

Кроме того очень важно понимать, что и как будет происходить при выполнении этой команды или указанной замены для нее из пары команд fetch и merge. Также очень полезно понимание родственной им команды rebase и наиболее часто применяемой при работе с 1С при выполнении git pull и git push операции fast forward. Без понимания этих процессов переходить к коллективной работе с git будет рискованно. Наиболее наглядные материалы по этой теме из встреченных мной в сети находятся по этим ссылкам:

https://habr.com/post/161009/

https://webdevkin.ru/posts/raznoe/izuchaem-git-merge-vs-rebase-dlya-nachinayushhix

https://webdevkin.ru/posts/raznoe/kak-skleit-kommiti-git

http://gearmobile.github.io/git/fast-forward-git/

 

Наконец запустим скрипт следующей командой и убедимся в том, что он работает корректно:

oscript "C:data
eposprocess-storage.os" —storage-path "C:data
eposut_storage" —temp-dir "C:data
epos emp"  —repository-dir "C:data
eposut_git" —configuration-subdir "config" —push-to-remote ON

 

 

Регулярная выгрузка по расписанию

 

Для регулярного запуска будем использовать планировщик Windows. Это не лучшее решение. Дальше будут указаны преимущества использвоания Jenkins вместо планировщика, но чтобы не превращать публикацию в четвертый том “Войны и мира” сейчас эту тему развивать не будем.  

Для запуска через планировщик полезно написать BAT-файл, который будет содержать в себе две строки:

chcp 65001

oscript "%~dp0process-storage.os" —storage-path "%~dp0ut_storage" —temp-dir "%~dp0temp"  —repository-dir "%~dp0ut_git" —configuration-subdir "config" —push-to-remote ON

 

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

Создадим задачу со следующими настройками :

Учетные данные для авторизации на гит-сервере будут браться задачей из хранилища паролей указанного для задачи пользователя:

Укажем запуск каждые 5 минут. Можно и чаще, если это требуется для более оперативной работы:

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

Укажем что в один момент времени может выполняться только одна задача:

Лог можно будет увидеть в журнале задач :

 

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

 

git  требует авторизации, но окна отображаются в фоне и добраться до них невозможно. Авторизация при этом требуется на этапе отправки в удаленный репозиторий. В этом случае все процессы oscript , git , git-credential-manager надо завершить и выполнить команду git push вручную.

 

Также эта проблема с успехом обходится при применении Jenkins. В Jenkins есть хранилище паролей (правда эти пароли сохраняются в явном виде во временные текстовые файлы при работе сценариев). Кроме того применяя Jenkins мы получаем возможность:

  • Не останавливаться только на выгрузке и подключить следующие шаги — тестирование, подготовку релиза.
  • Распараллеливать процесс выгрузки  и тестирования, передавать выполненные изменения в задачу тестирования не мешая при этом дальнейшей синхронизации хранилища и git-репозитория.  
  • Увидеть логи выполнения скрипта (консольный вывод) и статистику выполнения. На скриншоте ниже  красные сборки — это обращения к хранилищу не получившие изменения или упавшие по другой причине. Синие — получившие изменения и успешно выполнившие отправку в удаленный репозиторий

 

 

Однако это уже тема для другой публикации. Для изучения Jenkins очень рекомендую курс Jenkins Essential Training , а в применении к 1С курс "Разработка по промышленным стандартам на платформе 1С:Предприятие. Часть 2" 

 

 

 

Что мы получаем при использовании Gitlab, Upsource, Crucible и т.д.

 

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

 

Продукты Atlassian

При интеграции Crucible, Fisheye и Jira символ  # перед номером задачи писать необязательно. Связь с задачей все равно будет установлена автоматически благодаря системе нумерации проектов в Jira (код проекта = префикс задачи).

 

 

Также мы получаем возможность одним кликом мыши из задачи в Jira просмотреть изменения кода, связанные с задачей и вторым кликом создать код-ревью по задаче в целом, а не по каждому коммиту в отдельности:

 

 

Аналогичный процесс уже описывался Андреем Овсянкиным во время выступления на конференции Infostart : //infostart.ru/public/548028/ 

 

 

GitLab

При выгрузке в Gitlab так вероятно не получится и для связи коммитов с задачами, как мы видели выше, нужно писать #НомерЗадачи  Текст комментария 

Кроме того система код-ревью через мердж-реквесты, принятая в GitLab, плохо подходит для проведения поскоммитных ревью, неизбежных выгрузке изменений из хранилища в Git.  В итоге GitLab при работе с хранилищем 1С не позволяет удобно проводить ревью задачи в целом.  Ревью же каждого коммита в отдельности — штука затратная по времени и нервам.  Ведь ошибка из коммита №1 по задаче может быть уже исправлена в коммите №4 по той же задаче. А просматривать коммиты вероятно придется последовательно.

Пока что у меня нет решения как можно удобно проводить ревью по всем коммитам в рамках задачи используя GitLab. Если у кого-то есть решение, пожалуйста, поделитесь в комментариях.

 

Upsource

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

Интеграция с таск-трекерами: https://www.jetbrains.com/help/upsource/2.0/issue_tracker_integration.html

Автоматизация создания код-ревью: https://blog.jetbrains.com/upsource/2018/07/26/orderly-code-reviews-in-upsource

 

 

Хранение внешних обработок, тестов, документации в репозитории

 

Файлы тестов, документации, внешних обработок (см. Precommit1C) в идеале должны быть консистентны с исходным кодом конфигурации. А значит в идеале должны храниться в том же репозитории. Однако при этом есть разумное требование — каждый коммит в git должен быть связан только с одной задачей. Конечно сам git не требует делать именно так. Но нарушение этого правила может привести к бардаку и все преимущества от применения системы контроля версий потеряются.

 

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

  • Разработчик 1 положил изменения в хранилище 1C по одной задаче
  • Разработчик 2 положили в каталог внешних обработок изменения по другой задаче
  • Началась выгрузка изменений из хранилища и закончилась, выполняется коммит. С точки зрения Разработчика 1 он должен был относиться только к его задаче.
  • Аналогично с точки зрения разработчика Разработчик выполнявший вторую задачу еще не собирался делать коммит внешних обработок, но они уже слились в одном коммите с изменениями по задаче 2 уехали в Bitbucket/Gitlab.

 

Поэтому при хранении внешних обработок, файлов тестирования лучше создать отдельный репозиторий для каждого разработчика. И перед отправкой своих изменений в общий репозиторий (git push) получать изменения из удаленного репозитория (git pull). В этом случае коммиты связанные с выгрузкой и коммиты связанные со внешними обработками не будут сливаться вместе. Так мы приближаемся к процессу git-flow со всеми его рисками в виде конфликтов при мерджах.

Разумеется это также приведет к необходимости выделения большого репозитория для каждого разработчика (около 5 гигабайт на 1С: ERP и еще больше в случае хранения внешних файлов проекта). Также это повышает вероятность того, что файлы исходников хранилища в репозиториях разработчиков случайно или намеренно будут внесены нежелательные изменения и они уедут в общий репозиторий.

 

Другим возможным решением является выделение отдельного репозитория для внешних отчетов и обработок. Но в этом случае у нас меньше возможности поддерживать соответствие репозитория конфигурации и репозитория внешних файлов.

Лучшее решение для внешних обработок — придерживаться одного источника исполняемого кода и, если код обработки не требует постоянного изменения, добавлять обработки в состав конфигурации. Для документации же и тестов все равно придется применять один из вышеописанных подходов.

 

 

Методы облегчения конфигурации, репозитория и ускорения выгрузки

 

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

Конечно главный из них — использование SSD дисков. Десятки тысяч мелких файлов, с которыми ведется работа, скажут спасибо за такой подарок и начинают обрабатываться быстрее. По практике полная (не инкрементальная) выгрузка каждого коммита ERP без SSD диска занимает 45 — 60 минут, с SSD диском 15-20 минут.  Для небольших конфигураций время кончено буде меньше. Например для УТ 11 оно составляло 5 минут. В этом случае оптимизировать время выгрузки наверное не имеет смысла.

Лучший прием для уменьшения времени выгрузки (но не размера репозитория) — это использование инкрементальной выгрузки, поддерживаемой gitsync. О ней можно прочитать здесь : https://github.com/oscript-library/gitsync. Как указано в документации, в течение дня происходит инкрементальная выгрузка, благодаря информации, содержащейся в файле ConfigDumpInfo.xml. Неактуальные файлы удаленных / переименованных объектов метаданных при этом не удаляются. Ночью надо сделать отдельную полную выгрузку, перед ее выполнением удалив файл ConfigDumpInfo.xml. Я этот прием не использовал, так как в этом случае неудобно отслеживать факт переименования объектов метаданных. Да и доведя время выгрузки до 5-15 минут в этом уже не было необходимости.

 

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

 

1)  Снять с поддержки типовую конфигурацию. Если конфигурация находится на поддержке , то cf  — файл поставщика хранится в каждой конфигурации, подключенной к хранилищу, и в самом хранилище. Если мы ведем доработку типовой конфигурации по всем правилам (префиксация новых объектов, проведение код-ревью, работа с объектами без префиксов по всем правилам работы с типовыми объектами) то лишние замки и желтые квадраты на типовых объектах нам итак не нужны.

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

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

а)  Захватываем все типовые объекты

б)  Сравниваем объединяем с постановкой на поддержку.

в)  Проводим обновление конфигурации как находящейся на поддержке.

г)   Снимаем с поддержки.

д)  Помещаем изменения в хранилище и готовим релиз.

 

2)  Следующий метод — заменить неиспользуемые драйверы в общих макетах на пустые файлы. Огромное количество бинарников перестанет при этом каждый раз выгружаться.

3)  Очистить старые макеты регламентированной отчетности. Это одни из самых крупных файлов в составе конфигураций и хранятся в ней годами. Не обязательно их удалять, можно просто очистить содержимое табличных документов. Их очистка не помешает обновлению на новые релизы, так как их не будет в списке дважды измененных объектов — макеты 5-летней давности не обновляются.

4)  Быть осторожнее с ролями. Если роли назначить права на все объекты а затем их снять, то в выгрузке из ERP роль будет занимать до 16-20 мегабайт. И никак средствами конфигуратора от этого больше не избавиться. На УТ можно увидеть как роль вместо 1 килобайта начинает занимать 7 мегабайт. Править такие файлы после этого для уменьшения размера придется в текстовом или XML редакторе а затем делать загрузку в конфигурацию командой частичной загрузки файлов конфигурации :

 

 

О гит-клиентах

 

На больших конфигурациях графические клиенты вроде SourceTree или GitKraken часто зависают. Особенно при работе с объемными коммитами, вызванными переходом на новую редакцию или релиз типовой конфиуграции, созданием хранилища и т.д. SourceTree не рекомендую использовать. Прежде чем сделать какие-то действия, в том числе коммиты, этот клиент делает собственный индекс файлов. Выполняется это долго на больших конфигурациях. И если сделать коммит или другое действие не дождавшись индексирования, то можно потерять часть изменений.  Много лучше себя ведет более простой клиент SmartGit.

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

 

 

Содержимое прикрепленного файла

  • Файл скрипта .os
  • Bat-файл с командой запуска
  • .gitignore

 

 

89 Comments

  1. Vladimir Litvinenko

    Методика писалась около года назад. В связи с актуальностью на новом проекте решил ее обновить с учетом новых параметров gitsync и граблей, на которые пришлось наступить, и всё-таки довести до публикации. Сейчас хотелось бы написать больше по теме совместной работы с репозиторием, но практика в достаточной степени пока не наработана и лучше оставить тему для другой публикации ) Возможно в следующий раз получится подробнее остановиться на использовании сервера сборок вместо “деревянного” планировщика.

    Reply
  2. fishca

    Огромное спасибо за огромную проделанную работу по написанию данного материала! Архиполезно!

    Reply
  3. artbear

    Очень хороший лонг грид 🙂

    Спасибо за использование нашего инструмента gitsync.

    Он сейчас переживает очередное рождение — 4 или 5 🙂 ??

    Reply
  4. artbear

    И про KDiff3 отличный совет, сам его использую почти 20 лет.

    Reply
  5. Vladimir Litvinenko

    (3) Артур, Вам спасибо за его создание. Без него всё было бы сложнее, если вообще возможно. Барьер вхождения в эту тему определенно был бы выше.

    Reply
  6. nixel

    Труд, достойный внимания и прочтения 🙂

    Пара комментариев по гитсинку:

    * работа по tcp и http доступна в gitsync 3.0

    * временные файлы все же уже чистятся 🙂

    Если честно, не совсем понятно, зачем вы писали скрипт, который просто пробрасывает переданные параметры командной строки в … командную строку гитсинка.

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

    В любом случае, спасибо за статью и интерес к теме!

    P.S. Вижу, что курс не прошел зря 🙂

    Reply
  7. theshadowco

    (1) совместаня работа — это легко, вот см картинку-пример (хранилищей нет, только git и gitflow)

    Reply
  8. Vladimir Litvinenko

    (6)

    Часть дополнительных проверок, которые вы описали, можно упаковать в виде плагинов к гитсинку

    Никита, о механизме плагинов к gitsync узнал только сейчас из Вашего комментария. Спасибо за замечание, буду изучать вопрос.

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

    курс не прошел зря

    Курс был полезен, спасибо. Рекомендую его в публикации для знакомства с Jenkins. Изначально ставил этот процесс полностью как описано в публикации. Но после прохождения понял какие преимущества будут в результате подключения сервера сборок к этому процессу и в том числе подогнал скрипт под использование в сборочной линии. Головную боль с докером до сих пор вспоминаю, но с положительной стороны )) Тоже было очень полезно, познакомился наконец с 1С в Linux.

    временные файлы все же уже чистятся

    Работу с временными файлами проверял на версии gitsync 2.4.3. Сейчас ведь она актуальна. Временные файлы сохраняются. Возможно есть какой то ключ для их удаления? Подскажите, если так.

    Тут еще один момент. Удаление временных файлов на 1C: ERP может занимать несколько минут, если речь идет не про SSD диск. Возможно при применении HDD их целесообразнее делать после git push. По той же причине, по которой применяется параметр -limit 1 — это ускоряет появление и доступность коммита в Gitlab/Fisheye/Upsource и позволяет быстрее двигать задачи на разработку дальше.

    работа по tcp и http доступна в gitsync 3.0

    Возможность работать с хранилищем по TCP в версии 3.0 — это отлично! Надо будет проверить.

    Reply
  9. Vladimir Litvinenko

    (7)

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

    Вообще было бы классно увидеть пример описываемого Вами процесса на примере работы именно с кодом типовой конфигурации. Здесь тоже процесс описан https://infostart.ru/public/310640. Как применить его при работе с внешними обработками и документацией понятно. Как версионировать скрипты и фичи тоже понятно. Хотя и при этом возникают сложности описанные в публикации.

    Не хватает примеров как работать с типовыми и кодом самой конфигурации. Было бы очень классно прочитать практические советы и примеры. Те же мерджи форм или кода модулей объектов из состава конфигурации.

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

    Reply
  10. nixel

    (8)

    Работу с временными файлами проверял на версии gitsync 2.4.3. Сейчас ведь она актуальна. Временные файлы сохраняются.

    кто-то недавно божился, что поправлено)

    если это не так, то стоит в первую очередь проверить на версии 3.0, поддержка ветки 2.х сейчас осуществляется ооочень неохотно, т.к. силы разработчиков брошены на полировку 3.0 и наконец-то выкатку в релиз.

    Reply
  11. nixel

    (10) я кажется вспомнил. был момент, что временные файлы очищались не после запуска, а *перед* следующим запуском. то есть при использовании limit и периодическом запуске переполнения можно избежать. но не ручаюсь 🙂

    Reply
  12. Evil Beaver

    Фундаментально, спасибо!

    Reply
  13. PerlAmutor

    Спасибо за публикацию. Тема довольно сложная.

    По практике выгрузка каждого коммита ERP без SSD диска занимает 45 — 60 минут, с SSD диском 15-20 минут.

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

    Я правильно скажу, что основная цель всех этих мучений заключается в том, чтобы:

    1. Избавиться от захватов объектов и вести параллельную разработку, а не просить отпустить объект, когда человек ушел в отпуск?

    2. Красивое представление изменений в веб-интерфейсе

    3. Качественное комментирование кода конфигурации

    ?

    Reply
  14. tsukanov
    По практике выгрузка каждого коммита ERP без SSD диска занимает 45 — 60 минут, с SSD диском 15-20 минут.

    Жесть какая. Выгрузка коммитов в платформе не оптимизирована как обычная выгрузка? Или с чем это связано?

    Reply
  15. Vladimir Litvinenko

    (13)

    Эта заметка настораживает. Конечно, если делать коммиты раз в день, то проблем быть не должно.

    Если делать закладки в хранилище раз в час то проблем тоже не будет. А при использовании нормального железа и раз в 15 минут проблем не вызовет. При работе с небольшими конфигурациями и раз в 5 минут можно. Если сделано две закладки подряд, то они все равно обработаются, просто за 10-40 минут.

    У gitsync есть инкрементальная выгрузка. Добавил о ней информацию в публикацию. Она позволит делать выгрузку очень быстро. Но тогда надо регулярно делать автоматическую задачу на полную выгрузку. Если 15-20 минут — время которое устраивает, то можно не использовать инкрементальную выгрузку.

    для оперативного исправления бага с предыдущего коммита ничего не останется как лезть напрямую в рабочий конфигуратор и править там по-старинке

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

    Уже затем исправленный баг должен по всем правилам работы с задачами на разработку пройти через базу разработчика и хранилище для разработки и дойти до релизного cf-ника или exe-файла поставки. В идеале еще и тестами покрыт, если в команде дошло дело до таких продвинутых штук как покрытие тестами.

    основная цель

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

    Reply
  16. Vladimir Litvinenko

    (14)

    Время работы не будет таким большим при работе с конфигурациями, меньшими по размеру, чем ERP. Для УТ 11 это время можно сократить до 5 минут.

    Время работы во многом связано со следующим алгоритмом:

    * Выгружается нужная версия хранилища в виде cf-файла

    * Загружается во временную файловую базу (здесь появляются проблемы с лицензиями).

    * Разбирается на исходники путем выгрузки во временный каталог.

    * Затем идет обработка этого временного каталога, удаляются файлы из рабочего каталога репозитория, файлы туда переносятся из временного каталога.

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

    * Удаляется множество мелких файлов из временного каталога.

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

    Reply
  17. tsukanov

    (16) Не совсем понимаю. А для чего все это делается?

    Пардон за глупые вопросы. Я могу чего-то недопонимать.

    Я предполагал, что версия из хранилища сразу выгружается в XML. Платформа этого не позволяет?

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

    «инкрементальная выгрузка» — это то, как я описал?

    Reply
  18. Vladimir Litvinenko

    (17)

    Да, инкрементальная выгрузка ведет себя именно так, как Вы описали. Но тогда переименования объектов отслеживать сложнее. Неактуальные версии файлов остаются в выгрузке до вечера, когда отработает задание по полной выгрузке. Про нее подробнее написано в конце страницы здесь: https://github.com/oscript-library/gitsync

    При полной выгрузке gitsync помогает оперативно отслеживать переименования и удаления файлов. Мне показалось целесообразнее поработать над размером конфигурации, описанными в публикации методами, чем создавать отдельное задание на полную выгрузку (очистку неактуальных файлов). Ведь в таком случае информация об удалении файлов уйдет в GitLab / Fisheye либо от анонимного пользователя, либо от последнего, кто делал нормальный коммит. В общем будет неудобно смотреть историю изменений. Ведь конечная цель именно в том, чтобы корректно видеть изменения в увязке к задаче в таск-трекере, например Jira, проводить объективное ревью в системах вроде Upsource или Crucible и не получить проблем при загрузке конфигурации из репозитория, например на сервере сборок типа TeamCity.

    За одно решается проблема с занимаемым базами разработчиков дисковым пространством. Если таких баз много, то вычищение из ERP лишних драйверов и древних макетов объемом по 20-40 Мб каждый, приносит пользу.

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

    Reply
  19. tsukanov

    (18) Спасибо. Понял в чем проблема. Я просто думал что платформа при инкрементальной выгрузке сама удаляет файлы. Удивлен что это не так.

    Reply
  20. Vladimir Litvinenko

    (19)

    Может быть что-то уже изменилось в новых версиях платформы. Там уже 8.3.14 готовят. Надо будет посмотреть. Новости по этой теме не отслеживал.

    Reply
  21. tsukanov

    (20) Проверил на 12 платформе. Файлы удаляются…

    Reply
  22. GreenDragon

    (1) Огромное вам человеческое спасибо! Как раз начал внедрять методики разработки с применением git у нас в отделе. Куплены и практически курсы от серебрянной пули по промышленной разработке, а тут ещё и ваша статья подоспела. Ещё раз спасибо!

    Reply
  23. sergey.novikov

    А не возникало проблем, что конфигурация, выгруженная из хранилища и загруженная в файловую версию, не сохраняется из-за превышения допустимой длины ключа индекса?

    Недавно выхватил такую беду

    Reply
  24. Vladimir Litvinenko

    (21)

    Не могли бы Вы подсказать, какую последовательность действий выполняете? У меня не удается заставить платформу при инкрементальной выгрузке удалять неактуальные файлы вплоть до платформы 8.3.12.1529. Указываю ключ -update при выгрузке для инкрементальной выгрузке вместо полной. Файлы со старыми именами также сохраняются.

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

    Reply
  25. tsukanov

    (24) Платформа 8.3.12.1595 (64)

    Выгружал тупо через меню в конфигураторе )

    Проверял так:

    1. Добавил константу > выгрузил > файлы появились

    2. Удалил константу > выгрузил > файлы удалились

    ps Сейчас даже перепроверил. И удаление и переименование. Все отрабатывает как надо.

    Reply
  26. tsukanov

    (24) Проверил еще 8.3.10.2772

    Тоже все работает

    ps Сейчас еще из командной строки проверю

    Reply
  27. Vladimir Litvinenko

    (26)

    Через конфигуратор выполняется полная выгрузка. Та же, что выполняется через gitsync в режиме полной выгрузки. Для инкрементальной необходимо указание ключа -update в командной строке, как на скриншоте выше. https://wonderland.v8.1c.ru/blog/inkrementalnaya-vygruzka-konfiguratsii-v-xml/. Получается, что в этом случае платформа, к сожалению, до сих пор не анализирует наличие «линших» неактуальных файлов и не удаляет их.

    Поэтому и для gitsync все еще потребуется второе «ночное» задание для полной выгрузки, которое не сможет корректно проставить авторов изменений.

    Reply
  28. tsukanov

    (27) Ну пусть полная. Не в названии дело. Но она же идет меньше минуты на ERP и удаляет файлы.

    ps Правда меньше минуты только в случае если были только добавления и изменения. При удалении оно дольше.

    Reply
  29. tsukanov

    (27) В общем так. Платформа 8.3.10.2772 (64) из командной строки тоже все работает с инкрементальной выгрузкой

    Последовательность действий в повершеле:

    $1c = «C:Program Files1cv88.3.10.2772in1cv8.exe»
    $ArgList = @(‘DESIGNER’, ‘/F C:UsersadminDocumentsInfoBase’, ‘/DumpConfigToFiles C:	emp	est_dump -Format Hierarchical’)
    Start-Process $1c -ArgumentList $ArgList
    # Тут открыл конфигуратор и руками удалил объект
    $ArgList = @(‘DESIGNER’, ‘/F C:UsersadminDocumentsInfoBase’, ‘/DumpConfigToFiles C:	emp	est_dump -Format Hierarchical -update’)
    Start-Process $1c -ArgumentList $ArgList
    # Тут файлы успешно удалились
    

    Показать

    ps Ну и дальше с ключом -update тоже все отрабатывает. Файлы добавляются/удаляются. Вроде как все норм.

    Reply
  30. Vladimir Litvinenko

    (28)

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

    Однако если добавить еще одну константу, закрыть конфигуратор и выполнить команду 1cv8.exe config /F»E:DatabasesУТ 11.4″ /N»Admin» /DumpConfigToFiles E:ut_dump (без -update) то все же запускается полная выгрузка даже при наличии файла ConfigDumpInfo.xml. Даже если ничего в конфигурации не менять и снова выполнить эту команду — будет происходить полная выгрузка.

    На платформе 8.3.12 она по субъективным ощущениям выполняется быстрее. Но при использовании gitsync время же тратится не только на выгрузку. Еще выполняется получение версии конфигурации (cf-файла) из хранилища, его загрузка в файловую базу и только потом выгрузка. Ускорение процесса в целом будет не так велико.

    Надо будет смотреть что в версии gitsync 3.0 будет нового.

    Reply
  31. Vladimir Litvinenko

    (29)

    Посмотрите время изменения всех остальных файлов в выгрузке. Поменялось ли оно и стало ли совпадать со временем выполнения последней команды выгрузки?

    Reply
  32. tsukanov

    (31) Какая разница полная она или нет? )

    Оно происходит быстро и удаляет файлы. Мне остальное не важно )

    Я же делаю с ключом -update. Уж что там платформа делает без понятия.

    Reply
  33. tsukanov

    (30)

    Но стоило мне переименовать константу, как платформа снова начала выгружать конфигурацию полностью.

    Ну видимо чисто технически инкрементальная выгрузка не всегда возможна (подозреваю это связано с ролями, например). Но у вас в gitsync это очевидно ровно также.

    Тут уж ничего не поделать.

    Еще выполняется получение версии конфигурации (cf-файла) из хранилища, его загрузка в файловую базу и только потом выгрузка. Ускорение процесса в целом будет не так велико.

    Платформа сразу версию не умеет выгружать?

    Я не в курсе. Ни разу не делал этого.

    Reply
  34. Vladimir Litvinenko

    (32)

    Да механизм хотелось бы понимать. Если бы у меня получилось воспроизвести Ваш результат, то вопросов было бы меньше. У меня же файлы не удаляются, что видно и на скриншоте выше и вот еще на этом. Мистика ) В любом случае, спасибо за исследование. Надо будет лучше изучить вопрос.

    Reply
  35. tsukanov

    (34) Я же приложил вам код на повершеле. Не знаю чем еще помочь.

    Reply
  36. tsukanov

    (34) Вопрос (чисто любопытство): как так получилось, что вы используете cmd и винду 7 в 2018 году?

    Reply
  37. Vladimir Litvinenko

    (36)

    Много всего привязано к операционке, в основном курсов на uvfPlayer. У Курсов-по-1С можно запросить еще ключи при смене ОС, но многие поставщики курсов такого не позволяют. Тот же Инфостарт не выдает вторые ключи на курсы. Фактически вторую ОСь надо ставить или вторую машинку брать. Windows 10 на виртуалке запускаю.

    Reply
  38. tsukanov

    (30)

    Еще выполняется получение версии конфигурации (cf-файла) из хранилища, его загрузка в файловую базу и только потом выгрузка. Ускорение процесса в целом будет не так велико.

    Судя по докам думаю вам стоит попробовать использовать ключ /ConfigurationRepositoryUpdateCfg.

    Не нужно будет выгружать cf и загружать в файловую базу.

    Последовательность действий одной выгрузки:

    1. /ConfigurationRepositoryUnbindCfg

    2. /ConfigurationRepositoryUpdateCfg -v <нужная версия>

    3. /DumpConfigToFiles -update

    Теоретически будет быстрее

    Reply
  39. Vladimir Litvinenko

    (22) Действительно желаю успехов в этом. Очень надеюсь, что таких команд станет больше.

    Reply
  40. sergey.novikov

    (23) Я к тому, что гитсинк 2.4.3 не поднимает эти эксепшены наверх, в результате трудно опередлить причину ошибки….

    бывают и ошибки формата потока и прочая ересь

    Reply
  41. Vladimir Litvinenko

    (40) Да, с тем, что настоящая причина ошибки не всегда доступна из вызвавшей программы были проблемы. В таких случаях приходится выполнять команду экспорта вручную и если консольный вывод с параметром -verbose on все еще не дает нужной информации, то глубже зарываться. Например выгружать и загружать конфигурацию вручную. К счастью это бывает редко, если с конфигурацией, жестким диском и ключом или сервером лицензирования в целом всё в порядке.

    Reply
  42. sergey.novikov

    (41) Пробую сейчас играть с gitsync 3.0.0, пока в этом плане больше нравится, он более понятно сообщает в чем именно проблема

    Reply
  43. aleximuson

    Я вот немного не понял роль Jenkins’а…

    Вы сборку/тестирование руками запускаете?

    Или Jenkins здесь используется как продвинутый шедулер?

    Просто я из прочитанной мною информации о Jenkins вывел для себя следующий сценарий его использования:

    0. Для Git{Hub,Lab, etc} настраивается хук, которой соединяет репозиторий с Jenkins’ом

    1. Коммитится что-то в репозиторий

    2. git-хук дергает Jenkins API

    3. Jenkins реагирует на это, запускает сборку/тестирование/деплой

    Или я что-то не так понял?

    Reply
  44. Evil Beaver

    (23) Да, все косяки файловой версии, включая длину индекса и уже упомянутые тут лицензии будут всплывать на шаге загрузки cf во временную файловую базу.

    gytsync не умеет работать с выделенной серверной базой для этого, насколько мне известно.

    Reply
  45. Vladimir Litvinenko

    (43) Jenkins упомянут как следующий шаг развития системы, также как и интеграция с инструментами для код-ревью и системами учета задач на разработку. Чтобы не перегружать публикацию эту тему развивать не стал. В примерах, приведенных в публикации он не используется, за исключением одного скриншота.

    Можно использовать его как продвинутый шедулер вместо планировщика Windows. В этом случае в качестве преимущества мы получим лучшее визуальное представление логов исполнения и визуальное представление сборок. Обработка хранилища, которая привела к появлению новых коммитов в репозитории, будет отображаться синим. Те запуски, которые не привели к новым коммитам — красным. Хотя это конечно зависит от Вашей реализации. Сервер сборок можно использовать и для более сложных сценариев, например, чтобы запускать другие задачи после обработки следующей версии хранилища. Запуск можно производить средствами самого сервера сборок.

    Скрипт написан таким образом, чтобы код возврата после его выполнения был не равен 0 в случае, если в результате выгрузки из хранилища не произошло изменений или возникла исключительная ситуация. В Jenkins в декларативной сборочной линии или пайплайне следующими шагами могут быть отправка изменений в origin и/или запуск тестирования последней обработанной версии хранилища. Для декларативной сборочной линии эти послесборочные операции должны быть с признаком Push Only If Build Succeeds (для отправки изменений в origin) и Trigger only if build is stable (для задачи тестирования).

    Можно вызывать задачу Jenkins и из самого скрипта или гит-хука через POST-запрос. В этом случае наверное будет проще передать в качестве параметра номер версии хранилища или хеш коммита. А можно и вызывать задачу как послесборочную операцию. Мне больше нравится последний вариант. Но здесь множество вариантов на любой вкус ))

    Reply
  46. GreenDragon

    (6)

    * работа по tcp и http доступна в gitsync 3.0

    Если не ошибаюсь, gitsync 3.0 живёт пока что в ветке develop. Думаю, стоит подождать мердж в master/

    (6)

    Reply
  47. aleximuson

    (45) Большое спасибо за развернутый ответ и вообще в целом за публикацию!

    Reply
  48. bash08

    Статья хорошая. Мы тоже в организации начинаем процесс модернизации разработки. Используем в разработке расширения. Сколько всего перечитал, нигде нет методики использования гит + расширения. Только если разрабатывать на EDT. Мы пока не готовы перевести всю разработку на EDT. Может быть у кого то есть опыт использования git + расширения?

    Reply
  49. Vladimir Litvinenko

    (48) Искренне не хотелось бы вызвать холивар. Но кажется указанные проблемы с невозможностью перейти с 8.2 на 8.3 и неверным, хотя и обычным для 1С, подходом к разработке в целом связаны.

    При подготовке к релизу в хранилище выкладываются тонны кода

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

    Никакое автоматизированное тестирование применяться не будет, если его выполнение предполагается только перед релизом, а не хотя бы каждый день. Потому что пару раз сорвав обещанные сроки подготовки функционала из-за того, что тестирование перед релизом сообщило об ошибках, и наспех поправив эти ошибки, вызвав тем самым новые, идея непрерывного тестирования будет дискредитирована. Как в глазах руководства, так и в глазах разработчиков. Дальше под каким-нибудь предлогом типа нехватки времени или сложности написания тестов она будет заметена под ковёр. О фактической причине — неверном процессе, никто и не скажет ))

    Никакое ревью кода не заработает, если оно будет выполняться после слива в хранилище большого количества готового, по мнению разработчиков, функционала. Просто не будет времени отключиться от прочих задач и несколько часов делать ревью. Даже если это будет делать один человек — толку мало. Внимание нельзя удерживать на коде коллеги столько времени, ошибки будут пропущены, особенно логические. В этом случае ревью перестает быть регулярным коллективным процессом, встроенным в общий процесс разработки. Опять же будет заметено под ковёр под благовидным предлогом типа «мы профессионалы и доверяем коду друг друга» , «ну оно же работает, а код мы исправим потом, лет через пять» и прочие социально приемлемые отмазки. Прибавьте к этому что разработчики обычно изначально больше мотивированы почитать Инфостарт или Хабр, нежели код друг друга.

    Иначе говоря при таком процессе выгрузка в Git и подключение Upsource/Gitlab/Crucible в целом смысла не имеет.

    Дергать хранилище при каждом чихе. Мне кажется не самой хорошей идеей периодически трогать хранилище и выгружать из него изменения.

    Поверьте, хранилище не обидится за это. Вежливо предупредите его, что его файлы будут трогаться только на чтение, то есть на посмотреть. Если же оно проявит признаки испуга, то можно действовать постепенно. Может быть начать с раза в день, а не раза в 2-5 минут. Потом, когда хранилище привыкнет к такому дерганию можно будет и почаще подергать. Вот что делать с износом диска при чтении файлов хранилища и их последующем раскладывании на исходники, я не знаю. Можно конечно на RAM диски пересесть ))

    Reply
  50. Aleximus_III

    (50) Легаси код — наследие предков, когда-то в бородатые времена написанная конфигурация. Мне встречались в основном отраслевые решения, аналогов которых не было на тот момент, написанные с нуля. Этот черный ящик как-то работает, есть не просит, но и его приходиться поддерживать и даже что-то дорабатывать/исправлять баги.

    Никто не говорит что перевести это все на 8.3 невозможно. Просто никто на это не даст денег. Ну или не те и не так продают 🙂

    Если Вы с такими конфигурациями не сталкивались, я Вам завидую :).

    Автоматическое тестирование — да, слышали. Весь покрытый тестами, абсолютно весь, где-то в индустрии есть :)))

    Но я не писал про автоматическое тестирование, просто тестирование, отделы целые имеются в компаниях, руками все тестируют. Ужасно? Каменный век? Бесспорно!

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

    Тут уже от команды и культуры отдельных разработчиков зависит. Надо оно или нет решать сугубо им.

    Тут хотя бы с малого начать, с автоматической сборки поставки после изменения версии конфигурации. Что бы не руками обновлять тестовые базы. А уж потом думать о высоком (для индустрии, не из мира 1С, обыденном): автотесты, кодревью…

    В общем хорошо когда все хорошо, и конфигурация на базе БСП, и версия платформы свежая, и программисты слышали такие слова как git, docker, CD/CI. А когда все это пока только Цель, а инструменты описанные в статье хочется использовать здесь и сейчас…

    Что-то меня грусть и тоска одолела 🙁

    Reply
  51. Vladimir Litvinenko
    Reply
  52. Evil Beaver

    (48) мы гитсинкаем уже 3 года. Вы не правы. Правда, мне уже лень объяснять почему.. Вы пытаетесь рассуждать о вкусе молока по фотографии.

    Reply
  53. Evil Beaver

    (51)

    а инструменты описанные в статье хочется использовать здесь и с

    Инструменты в массе своей написаны еще во времена 8.2. И практически все развиваются с сохранением поддержки 8.2.

    Есть редкие исключения, но gitsync поддерживает 8.2 и неуправляемые формы.

    Reply
  54. Evil Beaver

    (49) опыт в сообществе есть, но если брать именно автоматический gitsync (как утилиту с конкретной версией и функциональностью), то сейчас он этого делать не умеет. Ждет своего автора.

    Reply
  55. theshadowco

    (9) Разницы «типовая» или нет нет никакой, все зависит от поставленного процесса.

    А так да, любой инструмент можно применить, главное чтобы был удобен.

    По поводу кейсов — есть консалтинг, обращайтесь :). А если серьезно, до определенного взросления команды смысла нет — масса примеров когда работы напрямую с продовой ИС считаются нормальными.

    Reply
  56. Vladimir Litvinenko

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

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

    Reply
  57. theshadowco

    (57) конфигуратор можно, но не обязательно

    Reply
  58. theshadowco

    (57) а так, приходите на IE — если буду с ноутом, смогу показать 🙂

    Reply
  59. strange2007

    Отмечу только про обновление (личный опыт):

    — Конфигурацию снимать с поддержки и вообще забыть про неё.

    — Перед обновлением стандартную конфу снять с поддержки.

    — Накатить свою подсистему на стандартную конфигурацию (предыдущий пункт)

    — Обновить рабочую конфу или тестовую, которая в хранилище.

    Всё. Никаких усложнений с поддержками и прочими танцами.

    А статья интересная. Большая работа проделана. Такая глобальная разработка… не каждому под силу

    Reply
  60. elu.viro36

    А вывод из исходников обратно в базу каким образом происходит?

    Reply
  61. ilyatroitskiy

    Здравствуйте, коллеги, тема отличная, сам уже пару недель пытаюсь двигаться в этом направлении!

    Подскажите по какой причине может очень долго проходить выгрузка в файлы?

    Вот пример, на 1 коммит в хранилище — 10 минут:

    ИНФОРМАЦИЯ — Получаем исходники для версии 5945, 24.09.2018 12:13:31

    ИНФОРМАЦИЯ — Получаем исходники для версии 5946, 24.09.2018 12:21:12

    ИНФОРМАЦИЯ — Получаем исходники для версии 5947, 24.09.2018 12:29:58

    ИНФОРМАЦИЯ — Получаем исходники для версии 5948, 24.09.2018 12:39:33

    ИНФОРМАЦИЯ — Получаем исходники для версии 5949, 24.09.2018 12:48:03

    у нас так никогда не получиться актуальная версия конфы в гите, потому что коммиты в хранилке происходят чаще

    подскажите куда копнуть?

    Reply
  62. elu.viro36

    (62)

    Подскажите по какой причине может очень долго проходить выгрузка в файлы?

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

    Reply
  63. Serg O.

    это ж космос какой то…

    !!! HELP !!!

    при подключении обработчика перехвата внешних обработок…. как тут написано ( precommit1C )

    куча внешних файлов — и на КАЖДЫЙ

    — 2 раза Конфигуратор 8.3 спрашивает (см.фото 1 и 2)

    подскажите как выключить эту дебильную проверку 1С 8.3 ???

    Reply
  64. Vladimir Litvinenko

    (64)

    Это результат работы механизма защиты от опасных действий.

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

    В этот файл необходимо внести строку DisableUnsafeActionProtection=.*

    Эта строка говорит 1С, что необходимо отключить защиту от опасных действий для всех баз, так как регулярному выражению .* удовлетворяет строка подключения к любой базе. Более безопасно было бы отключать защиту только для отдельных баз, например файловых. Но на CI-сервере это наверное не актуально.

    Более подробно описано здесь :

    ИТС : https://its.1c.ru/db/v838doc#bookmark:adm:TI000000377

    Документация по precommit1C : https://github.com/xDrivenDevelopment/precommit1c

    Reply
  65. Serg O.

    (65) спасибо

    DisableUnsafeActionProtection=.*

    помогло!

    Reply
  66. Serg O.
    Reply
  67. Vladimir Litvinenko
    Reply
  68. Serg O.

    я на 1С пишу, и скрипт Jenkins мне не надо… спасибо

    есть onescript и bash

    я про статью в целом — сразу вываливать 3х параметрическую функцию… не очень понятно зачем

    в итоге пришлось самому почти с нуля копать… даже просто скопипастить — не работает в итоге ничего!?

    пришлось переписывать функции под себя… на onescript-е

    и изобретать снова свой велосипед…с квадратными колёсами

    для «работы» — всего 3 строки достаточно для начала, даже 2х (без копирования хранилища)

    а уже эти 2 главных шага «обворачивать» в мега-проверки и супер-пупер-функции

    Reply
  69. Serg O.

    в целом — очень хорошая статья, много полезного и интересного.

    Про выгрузку больших файлов git и русификацию не догадаешься сам.

    так что, в целом, за статью, спасибо автору

    Reply
  70. petrov_2015

    Очень достойный (с претензией на академичность) труд. Спасибо. Зашло.

    Поскольку данная инструкция пошагово применялась в действии, то с учетом юниорства возникли вопросы:

    — «Настройка .gitignore» есть смысл перенести До «Создание ветки develop»

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

    — «Первая выгрузка» есть смысл рекомендовать с ключом «-limit 1»,- она же Первая

    — «Пишем скрипт выгрузки» там осознанно пропущен код собственно запуска gitsync, который имеется в скачанном скрипте?

    и по существу:

    — планируется ли отдельная статья (или дополнение к этой) по Jenkins?

    — как Вы синхронизируете хранилища Расширений с git?

    Reply
  71. Vladimir Litvinenko
    Reply
  72. petrov_2015

    (72)

    — Комментарии по поводу «Настройка .gitignore» и «Первая выгрузка» — это мне как джуниору в этой теме было понятнее и проще

    — «Пишем скрипт выгрузки» — Да, пардон, в статье есть блок кода вызова gitsync (почему обратил на него внимание только в скачанном скрипте?)

    — по Jenkins: скрипт увидел, с какого видео начать понял. Спасибо.

    — по Расширениям: приходится их использовать для Бухгалтерии и ERP

    странно, что структура хранилища расширений похожа на обычное и Просматривается Tool1C, НО конфа Не выгружается,

    штатное же в gitsync v2 взаимодействие с хранилищем тоже не работает. Иссшуз 122 видел, какие-то движения есть в v8storage https://github.com/khorevaa/v8storage/issues/4

    Reply
  73. petrov_2015

    (72)

    Не заработал что-то у меня приведенный пайплайн скрипт…

    Установил Jenkins (на Windows 10)- обновил плагины — создал Item типа pipeline — вставил приведенный выше скрипт

    — поменял agent { label ‘storage_export’ } на agent { label ‘master’ }

    — добавил путь к своему process-scheduler.bat

    — вместо bat-ника включил собственно его содержимое ‘oscript «%~dp0process-storage.os» —storage-path…’

    — пробовал вставлять простые bat ‘echo %PATH%’

    все одно: задание зависает на выполнении bat — это видно в консоли вывода.

    Что не так? В синтаксисе или какие галочки/плагины нужно добавить?

    Reply
  74. Vladimir Litvinenko

    (74)

    Это одна из причин по которой не стал делать публикации про Jenkins )) Есть довольно много тонкостей в его использовании.

    Например в команде oscript %~dp0process-storage.os %~dp0 будет указывать на текущий каталог, а при выполнении задачи Jenkins текущим каталогом будет не местоположение скрипта .os а рабочий каталог задачи Jenkins который может выглядеть например вот так:

    D:jenkinsworkspaceerp_export_storage_to_git

    И в нём будет произведена попытка запустить скрипт, что конечно не удастся. Происходит скорее всего не зависание, а прекращение выполнения команды из-за того, что файл скрипта не найден. Хотя может быть и зависание, если не видеть полный лог, то сложно сказать.

    Для выполнения скрипта нужно либо прописать к нему полный путь, либо сменить директорию через cd /D перед этим, либо организовать работу с git-репозиторием, который будет автоматически затягиваться в рабочую директорию задачи Jenkins.

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

    Reply
  75. petrov_2015

    (75)

    Настройки и результат на прикрепленной картинке.

    Путь конечно же указываю, но более никаких галочек в настройка Item не ставлю. Запускаю пока опцией «Выбрать сейчас».

    Вместо «process-scheduler.bat» подставлял его содержимое.

    Пробовал «простой» bat-ник: bat ‘echo %PATH%’

    Результат Не меняется. Такое подозрение на синтаксис запуска bat-ника?

    Reply
  76. Vladimir Litvinenko

    (76)

    У вас судя по всему вообще не выполняется шаг bat

    Результат каждой из строк этой команды должен выводиться сразу, не дожидаясь выполнения остальных команд.

    Вот например в батнике ставлю паузу 20 секунд. Но результат выполнения строк по переключению кодовой страницы и смены директории выводится в stdout (точнее в лог задачи) сразу:

    То есть в Вашем случае дело не в bat-файле и не в скрипте .os , а в том, что команда bat не выполняется. Может быть для этого есть какие-то настройки безопасности? Проверьте также установлен ли у Вас плагин

    https://wiki.jenkins.io/display/JENKINS/Pipeline+Nodes+and+Processes+Plugin

    Насколько понимаю он нужен для шага bat в пайплайне. Но у меня этот плагин ставился при установке Jenkins и я не могу его даже удалить. Поэтому если его нет, то возможно проблема была в установке Jenkins.

    Reply
  77. Vladimir Litvinenko

    (76) Ответил ниже. Движок Инфостарта открепил сообщение от Вашего.

    Reply
  78. petrov_2015

    (77)

    Заработало!!!

    Создал новый item типа pipeline — вставил туда тот же (!) пайплайн-скрипт — запустил и все Поехало! Фантастика какая-то.

    Причину так и не нашел. Старый item там и не работает. Предполагал что проблема скрыта в файле настроек, но сравнение config.xml различий Не выявило. Оставлю этот item, как причина всллывет отпишусь.

    Как бы то ни было вышеприведенный скрипт Работает! (на дефолтных настройках Jenkins)

    Но для джуниоров рекомендовал бы 2 корректировки:

    1. агента заменить на label ‘master’ или any иначе система ищет label ‘storage_export’ и не находит.

        agent { label ‘master’ }

    2. при вызове скрипта прописать путь к текущему разделу + «process-storage.bat» заменить на «process-scheduler.bat» что описывается в статье + не дублировать вызов «chcp 65001» от есть в bat-нике

    def statusCode = bat script:
    «»»
    d:
    cd d:/Repo/1C
    process-scheduler.bat
    «»»,
    returnStatus:true
    

    Спасибо за ответы и поддержку.

    Reply
  79. petrov_2015

    (79)

    Нашлась-таки (!) проблема не работы пайплайн-скрипта: в наименовании Item использовались Русские буквы.

    Причем для наименований item Типа job кириллица допустима и bat-скрипт работает, а item типа pipline тот же bat-скрипт — Не работает.

    Reply
  80. zlakizla

    (1)

    Владимир, здравствуйте! Огромное спасибо за все Ваши статьи по Vanessa и синхронизацию хранилища и git. Сейчас внедряю автотесты в своей команде, вместе с этим и гит для командной работы с фичами. Параллельно со статьями Vanessa прочитал Вашу статью по синхронизации гит и хранилища. Возник небольшой вопрос, если у вас будет время, буду благодарен за ответ:) Возможно не внимательно читал (+ еще посмотрел презентацию git-flow в 1С), но так и не понял одного момента:

    Основной плюс гита состоит в том, что разработчики параллельно могут вести работу в одном и том же модуле, каждый в своей ветке и дальнейшем мержить в ветку develop. Т.е. явное преимущество перед хранилищем 1с, нет очереди к захвату объекта, работа идет параллельно. Но во время работы «Хранилище + Git» мы выгружаем коммиты из хранилища 1с, т.е. разработчики продолжат работу через хранилище? Они также захватывают объекты и помещают, а потом вот эти вот коммиты из хранилища 1с с помощью gitsync выгружаются в репозиторий. Не могу уловить, где тут используется параллельная работа над одним и тем же модулем с помощью git?

    Reply
  81. Vladimir Litvinenko

    (81) Параллельная работа над одним объектом конфигурации в этом случае невозможна. Более того, разработчики могут даже не знать ничего про git, а только пользоваться инструментами, которые обращаются к гит-репозиторию.

    Такая система нужна для проведения код-ревью и связи задач в таск-трекере с изменениями в хранилище, а также может быть удобна для системы непрерывной сборки (тестирования новых коммитов-закладок в хранилище). Основное — это кончено сделать изменения в системе 1С контролируемыми и повысить прозрачность разработки, не требуя при этом ни от кого переучиваться для работы с git.

    Разработчик работает по задаче, после того как изменения по ней помещены в харнилище мы в Jira видим, какие изменения были по ней сделаны, какие объекты поменялись, доступен просмотр кода и статистика по нему, количество коммитов и статусы код-ревью:



    Если в коде будут обнаружены ошибки или логические нестыковки легко их отметить и исправить:

    Reply
  82. zlakizla

    (82) Спасибо за пояснение. Видео по git-flow запутало, когда там выделили этот плюс параллельной разработки в гите, а потом начали рассказывать про выгрузку хранилища 1с в гит, где параллельная схема не работает)

    Reply
  83. Vladimir Litvinenko

    (83) Недавно в телеграм-канале было обсуждение подхода, который позволит работать с фича-бранчами даже без применения EDT: https://t.me/ssl1c/18371

    Также про аналогичный подход писал Дмитрий Королёв, очень интересная информация: http://forum.infostart.ru/forum9/topic212167/message2165933/#message2165933

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

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

    Reply
  84. lazarenko

    Жесть, че так сложно то? Вон я состряпал, работает с tcp хранилищем

    https://github.com/LazarenkoA/1C2GIT

    К тому же самодостаточный exe, не нужно в планировщик добавлять, есть логирование, ну нужно всякие сторонние ПО (ну кроме гита естественно)

    Reply
  85. zlakizla

    (84) Благодарю за статьи! Я все больше погружаюсь в процесс и возникают вопросы. Сейчас настроил выгрузку хранилища 1С в гит с помощью гитсинк. Разработчики подключены к единому хранилищу 1С, они делают закладки, а гитсинк экспортирует это дело в гит в ветку develop. Далее я пост фактум делаю код-ревью, если что-то не устравивает, то разработчик опять захватывает объект, правит код и делает закладку в хранилищу 1С. Далее работает гитсинк.

    Если все хорошо, то нужно изменения перенести в базу препрода. Я выгружаю конфигурацию хранилища 1С и с помощью типового сравнения/объединения переношу изменения в базу препрод. Из базы препрода я потом автоматически скриптом формирую поставку и обновляю прод. Задачи, которые нужно перенести в препрод (а затем в прод) я собираю по Jira, со статусом «Готовые к проду». Вот тут и возникает проблема с тем, что нужно перенести не весь код, который сейчас в хранилище 1С в базу препрод. Как обычно бывает в хранилище может быть код, который еще не доделан или не протестирован. И мне нужно перенести только тот код, который реализован в рамках уже готовых к проду задач. А при сравнении/объединении конфы хранилища и конфа препрода вывалится просто голый код, без комментариев, не понятно кто и что делал по какой задаче.

    Вот тут вопрос: У нас процесс кривой или есть какой-то способ красиво перенести только нужные коммиты в препрод?

    До всех этих танцев с гитсинком и гитом разработчики просто выделяли функции или куски кода комментариями Начало-Конец и указывали номер задачи. На это и ориентировался, когда переносил изменения в препрод из хранилища 1с.

    Reply
  86. Vladimir Litvinenko

    (86) Скинул в личку пару ссылок. Может быть покажутся Вам полезными.

    Reply
  87. a.doroshkevich

    (87)Владимир, а можно и мне в личку эти ссылки?

    Так как вопрос Максима сейчас для меня крайне актуален

    Reply
  88. Vladimir Litvinenko

    (88) Антон, посмотрите в личных сообщениях. Должен быть ответ.

    Reply
  89. a.doroshkevich

    (89)Спасибо!

    Reply

Leave a Comment

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