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

14.09.18

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

Файлы

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование	Скачано	Купить файл	По подписке PRO
storage_to_git_script.zip .zip 3,92Kb 111	111	2 500 руб. Купить	1 SM Скачать

Вы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».

0% комиссии — оплата напрямую исполнителю;
Исполнители любого масштаба — от отдельных специалистов до команд под проект;
Прямой обмен контактами между заказчиком и исполнителем;
Безопасная сделка — при необходимости;
Рейтинги, кейсы и прозрачная система откликов.

Постановка задачи
Выбор инструментов
Ограничение Gitsync на TCP, HTTP и что с этим делать
Структура каталогов и репозиториев
Настройки хранилища
Установка Git
Настройка репозитория
Создание или эмуляция удаленного репозитория
Пример связи коммитов с задачами и пользователями гит-сервера
Атрибуты коммитов, устанавливаемые gitsync
Пишем скрипт выгрузки
Регулярная выгрузка по расписанию
Что мы получаем при использовании Gitlab, Upsource, Crucible и т.д.
Хранение внешних обработок, тестов, документации в репозитории
Методы облегчения конфигурации, репозитория и ускорения выгрузки
О гит-клиентах

Данная публикация предназначена для коллег, которые понимают какую пользу принесет доступ к истории и коду конфигурации в 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\repos\ut_storage" "C:\data\repos\ut_git\config" -tempdir "C:\data\repos\temp"

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

gitsync export "C:\data\repos\ut_storage" "C:\data\repos\ut_git\config" -tempdir "C:\data\repos\temp" -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_git\config и если выполнить команду для этого подкаталога, то 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 мы сможем убедиться, что не обрабатываем коммиты от служебных пользователей.

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

Вступайте в нашу телеграмм-группу Инфостарт

1c git gitsync onescript oscript crucible fisheye bitbucket gitlab upsource code-review

+290 –1

См. также

Многопоточный TCP сервер с защищённым каналом для сценарного языка OneScript

Инструментарий разработчика Сервера OneScript Системный администратор Программист 1С 8.3 Россия Бесплатно (free)

Библиотека для создания многопоточного TCP-сервера, а так же TCP-клиента с поддержкой SSL/TLS шифрования для экосистемы OneScript. Удобный инструмент для построения распределенных систем, высоконагруженных сервисов, систем реального времени. С низким порогом вхождения и подробной документацией с примерами.

12.01.2026 2566 ahyahy 2

Текстовый пользовательский интерфейс (TUI) для сценарного языка OneScript

Инструментарий разработчика OneScript Работа с интерфейсом Программист Россия Бесплатно (free)

Представляю кроссплатформенную библиотеку для разработки приложений с текстовым пользовательским интерфейсом (TUI) для сценарного языка OneScript. Она использует модель программирования, похожую на классические Desktop GUI (например, WinForms или WPF), но целиком работает в текстовом режиме. Возможно это ностальгия по DOS временам, но в наше время это так же и повышенная скорость отрисовки интерфейса, и легкость в написании скрипта. Создавайте интуитивно понятные окна, кнопки, поля ввода и выпадающие списки. Благодаря OneScript инструмент будет доступен даже новичкам без долгого обучения.

14.11.2025 4294 ahyahy 12

Осенний бот, или мастер-класс по созданию приложения с использованием фреймворка Осень

OneScript Мессенджеры и боты Программист Бесплатно (free)

Создаём Telegram-бота для декомпиляции 1С файлов на OneScript и фреймворке Осень. Разберём архитектуру MVC для Telegram-бота. Научимся работать с фреймворком Осень: внедрение зависимостей, аннотации, логирование. Реализуем разбор бинарных файлов (EPF, ERT, CF, CFE.). Упакуем бота в Docker-контейнер

21.08.2025 5080 untru 15

DevOPS Управление разработкой из 1С

DevOps и автоматизация разработки OneScript Программист Бесплатно (free)

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

12.08.2025 9114 untru 13

Мы построили OneScript. 10 лет локомотиву DevOps в 1С

OneScript Программист 1С:Предприятие 8 Бесплатно (free)

В 2024 году главному инструменту DevOps в 1С исполнилось 10 лет. Расскажем о том, что представляет собой экосистема 1Script в 2024 году и почему её важно включить в свой рабочий процесс.

16.06.2025 9322 Evil Beaver 43

OneScript + EDT + GIT

Групповая разработка (Git, хранилище) EDT OneScript Программист 1С:Предприятие 8 Бесплатно (free)

В данной публикации рассматривается пример реализации скрипта, который автоматизирует получение ветки из GIT репозитория и обновление конфигурации, если разработка проекта ведется в EDT.

11.06.2025 7730 AlexF1 4

Коннектор MySQL для 1С и OneScript (open-source)

WEB-интеграция OneScript Программист Стажер Бесплатно (free)

Библиотека для работы с базами MySQL на основе внешней компоненты. Для Linux и Windows, бесплатно и с открытым исходным кодом!

08.04.2025 6873 bayselonarrend 27

Коннектор PostgreSQL для 1С и OneScript (open-source)

Внешние источники данных OneScript Программист Стажер 1С:Предприятие 8 Бесплатно (free)

Библиотека для работы с базами PostgreSQL на основе внешней компоненты. Для Linux и Windows, бесплатно и с открытым исходным кодом!

20.02.2025 9499 bayselonarrend 30

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. Vladimir Litvinenko 2944 14.09.18 09:23 Сейчас в теме

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

Ответить

7. theshadowco 269 14.09.18 10:50 Сейчас в теме

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

Прикрепленные файлы:

9. Vladimir Litvinenko 2944 14.09.18 11:30 Сейчас в теме

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

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

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

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

56. theshadowco 269 18.09.18 15:31 Сейчас в теме

(9) Разницы "типовая" или нет нет никакой, все зависит от поставленного процесса.
А так да, любой инструмент можно применить, главное чтобы был удобен.

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

57. Vladimir Litvinenko 2944 18.09.18 20:53 Сейчас в теме

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

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

58. theshadowco 269 18.09.18 22:24 Сейчас в теме

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

59. theshadowco 269 18.09.18 22:26 Сейчас в теме

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

22. GreenDragon 15.09.18 15:05 Сейчас в теме

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

39. Vladimir Litvinenko 2944 17.09.18 09:55 Сейчас в теме

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

81. kulmaksim 75 03.04.19 11:13 Сейчас в теме

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

82. Vladimir Litvinenko 2944 03.04.19 13:59 Сейчас в теме

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

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

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

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

83. kulmaksim 75 03.04.19 14:05 Сейчас в теме

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

84. Vladimir Litvinenko 2944 03.04.19 14:20 Сейчас в теме

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

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

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

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

86. kulmaksim 75 21.05.19 18:38 Сейчас в теме

(84) Благодарю за статьи! Я все больше погружаюсь в процесс и возникают вопросы. Сейчас настроил выгрузку хранилища 1С в гит с помощью гитсинк. Разработчики подключены к единому хранилищу 1С, они делают закладки, а гитсинк экспортирует это дело в гит в ветку develop. Далее я пост фактум делаю код-ревью, если что-то не устравивает, то разработчик опять захватывает объект, правит код и делает закладку в хранилищу 1С. Далее работает гитсинк.
Если все хорошо, то нужно изменения перенести в базу препрода. Я выгружаю конфигурацию хранилища 1С и с помощью типового сравнения/объединения переношу изменения в базу препрод. Из базы препрода я потом автоматически скриптом формирую поставку и обновляю прод. Задачи, которые нужно перенести в препрод (а затем в прод) я собираю по Jira, со статусом "Готовые к проду". Вот тут и возникает проблема с тем, что нужно перенести не весь код, который сейчас в хранилище 1С в базу препрод. Как обычно бывает в хранилище может быть код, который еще не доделан или не протестирован. И мне нужно перенести только тот код, который реализован в рамках уже готовых к проду задач. А при сравнении/объединении конфы хранилища и конфа препрода вывалится просто голый код, без комментариев, не понятно кто и что делал по какой задаче.
Вот тут вопрос: У нас процесс кривой или есть какой-то способ красиво перенести только нужные коммиты в препрод?
До всех этих танцев с гитсинком и гитом разработчики просто выделяли функции или куски кода комментариями Начало-Конец и указывали номер задачи. На это и ориентировался, когда переносил изменения в препрод из хранилища 1с.

87. Vladimir Litvinenko 2944 22.05.19 10:45 Сейчас в теме

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

88. a.doroshkevich 1211 17.12.19 07:57 Сейчас в теме

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

89. Vladimir Litvinenko 2944 18.12.19 01:52 Сейчас в теме

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

90. a.doroshkevich 1211 18.12.19 04:54 Сейчас в теме

(89)Спасибо!

91. SergeyMordvin 2359 12.05.20 08:19 Сейчас в теме

(87) тоже буду очень благодарен за ссылки, заранее спасибо!

93. mityushov.vv 270 08.09.20 14:50 Сейчас в теме

(87) Добрый день. А можно и мне ссылку в личку кинуть?

94. jenyach 27.01.21 12:28 Сейчас в теме

(87) Владимир, скиньте пожалуйста и мне данные ссылки. Большое спасибо!

96. Segate 287 17.08.21 13:42 Сейчас в теме

(87)Добрый день, та же проблема, можно тоже получить ссылки?

99. zyzo 09.11.24 23:58 Сейчас в теме

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

95. jenyach 27.01.21 12:36 Сейчас в теме

(86) Максим, подскажите пожалуйста, удалось ли вам решить проблему выборочного получения коммитов? У меня сейчас схожая проблема, гитсинк "льет" коммиты в исходники, из которых автоматизированно собирается cf-файл, которым необходимо будет обновлять прод базу. В данном файле собираются, конечно, все выложенные коммиты, а хотелось бы только допущенные к обновлению

100. vaillant 16 04.02.25 10:55 Сейчас в теме

(86) поддерживаю предыдущего оратора))
удалось ли решить момент с переносом только необходимых изменений из гит в предрелиз?

101. kulmaksim 75 04.02.25 11:15 Сейчас в теме

(100) Добрый день. Удалось, конечно) Но это тема на целую статью. Если кратко, то при помещении в хранилище в обязательном порядке в комментарии указывается номер задачи JIRA. То есть, комментарий строго определенного формата и только по одной задаче. Дальше опять же выгрузка в git, но все коммиты уже привязываются к задаче Jira, это готовый функционал интеграции Gitlab и Jira.
Таким образом у нас есть коммиты git, привязанные к конкретным задачам Jira, а у задач есть статус. Все параметры, чтобы собрать только "готовые к проду" коммиты есть) Чтобы собрать релиз мы пользуем GitExtension, с помощью которого собираем отдельную ветку с готовыми к проду коммитами. Для этого используем интерактивный "git rebase". Он сначала показывает весь список коммитов, которые будут натянуты на ветку, а мы из него удаляем не готовые к проду и оставляем только готовые. После rebase у нас есть ветка с готовыми к проду коммитами и уже из этой ветки мы собираем cf, который дальше идет в продуктив.

102. vaillant 16 04.02.25 11:26 Сейчас в теме

(101) супер! вот до момента "мы пользуем GitExtension" у нас всё есть и работает)
а процесс сборки cf (по нужному номеру задачи, нам сейчас интересно можно ли по одному конкретному) автоматизирован или руками приходится собирать?

103. kulmaksim 75 04.02.25 11:31 Сейчас в теме

(102) Пока полуавтомат. Автоматически там сложновато из-за конфликтов при rebase. Они могут быть и их надо разруливать вручную. Но kdiff с этим в 90% случаев хорошо справляется и разруливает сам)

104. KirillZ44 12 11.07.25 06:59 Сейчас в теме

(101) Добрый день. Подскажите, пожалуйста, а как у вас реализован процесс получения изменений из git?

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

Я пробовал сделать следующим образом: С помощью команды git pull получал все изменения из удаленного репозитория, а затем, с помощью oscript и библиотеки v8runner, используя метод ЗагрузитьРасширениеИзФайлов, пытался обновить свое локальное расширение. Но если расширение подключено к хранилище, его обновление невозможно. При этом, расширение без подключенного хранилища обновилось подобным образом без проблем.

2. fishca 1314 14.09.18 10:29 Сейчас в теме

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

Ответить

3. artbear 1589 14.09.18 10:29 Сейчас в теме

Очень хороший лонг грид :)
Спасибо за использование нашего инструмента gitsync.

Он сейчас переживает очередное рождение - 4 или 5 :) ??

5. Vladimir Litvinenko 2944 14.09.18 10:38 Сейчас в теме

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

4. artbear 1589 14.09.18 10:30 Сейчас в теме

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

6. nixel 1474 14.09.18 10:40 Сейчас в теме

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

Пара комментариев по гитсинку:
* работа по tcp и http доступна в gitsync 3.0
* временные файлы все же уже чистятся :)

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

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

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

8. Vladimir Litvinenko 2944 14.09.18 11:17 Сейчас в теме

(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 - это отлично! Надо будет проверить.

10. nixel 1474 14.09.18 12:18 Сейчас в теме

(8)

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

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

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

11. nixel 1474 14.09.18 12:33 Сейчас в теме

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

46. GreenDragon 18.09.18 02:53 Сейчас в теме

(6)

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

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

12. Evil Beaver 8412 14.09.18 22:06 Сейчас в теме

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

13. PerlAmutor 162 15.09.18 06:38 Сейчас в теме

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

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

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

Я правильно скажу, что основная цель всех этих мучений заключается в том, чтобы:
1. Избавиться от захватов объектов и вести параллельную разработку, а не просить отпустить объект, когда человек ушел в отпуск?
2. Красивое представление изменений в веб-интерфейсе
3. Качественное комментирование кода конфигурации

?

15. Vladimir Litvinenko 2944 15.09.18 13:57 Сейчас в теме

(13)

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

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

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

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

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

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

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

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

14. tsukanov 15.09.18 08:09 Сейчас в теме

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

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

16. Vladimir Litvinenko 2944 15.09.18 14:03 Сейчас в теме

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

Время работы во многом связано со следующим алгоритмом:
* Выгружается нужная версия хранилища в виде cf-файла
* Загружается во временную файловую базу (здесь появляются проблемы с лицензиями).
* Разбирается на исходники путем выгрузки во временный каталог.
* Затем идет обработка этого временного каталога, удаляются файлы из рабочего каталога репозитория, файлы туда переносятся из временного каталога.
* Делается коммит изменений и отправка в удаленный репозиторий.
* Удаляется множество мелких файлов из временного каталога.

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

17. tsukanov 15.09.18 14:23 Сейчас в теме

(16) Не совсем понимаю. А для чего все это делается?
Пардон за глупые вопросы. Я могу чего-то недопонимать.
Я предполагал, что версия из хранилища сразу выгружается в XML. Платформа этого не позволяет?
Ну и если бы оно выгружалось в XML, то весь процесс кажется не больше минуты бы занимал.

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

18. Vladimir Litvinenko 2944 15.09.18 14:34 Сейчас в теме

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

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

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

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

19. tsukanov 15.09.18 14:38 Сейчас в теме

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

20. Vladimir Litvinenko 2944 15.09.18 14:42 Сейчас в теме

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

21. tsukanov 15.09.18 14:59 Сейчас в теме

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

24. Vladimir Litvinenko 2944 15.09.18 19:47 Сейчас в теме

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

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

25. tsukanov 15.09.18 20:19 Сейчас в теме

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

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

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

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

26. tsukanov 15.09.18 20:37 Сейчас в теме

(24) Проверил еще 8.3.10.2772
Тоже все работает

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

27. Vladimir Litvinenko 2944 15.09.18 20:54 Сейчас в теме

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

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

28. tsukanov 15.09.18 21:01 Сейчас в теме

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

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

30. Vladimir Litvinenko 2944 15.09.18 22:04 Сейчас в теме

(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 будет нового.

33. tsukanov 15.09.18 22:25 Сейчас в теме

(30)

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

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

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

Платформа сразу версию не умеет выгружать?
Я не в курсе. Ни разу не делал этого.

38. tsukanov 16.09.18 08:12 Сейчас в теме

(30)

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

Последовательность действий одной выгрузки:
1. /ConfigurationRepositoryUnbindCfg
2. /ConfigurationRepositoryUpdateCfg -v <нужная версия>
3. /DumpConfigToFiles -update

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

29. tsukanov 15.09.18 21:19 Сейчас в теме

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

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

$1c = "C:\Program Files\1cv8\8.3.10.2772\bin\1cv8.exe"
$ArgList = @('DESIGNER', '/F C:\Users\admin\Documents\InfoBase', '/DumpConfigToFiles C:\temp\test_dump -Format Hierarchical')
Start-Process $1c -ArgumentList $ArgList
# Тут открыл конфигуратор и руками удалил объект
$ArgList = @('DESIGNER', '/F C:\Users\admin\Documents\InfoBase', '/DumpConfigToFiles C:\temp\test_dump -Format Hierarchical -update')
Start-Process $1c -ArgumentList $ArgList
# Тут файлы успешно удалились

Показать

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

31. Vladimir Litvinenko 2944 15.09.18 22:11 Сейчас в теме

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

32. tsukanov 15.09.18 22:19 Сейчас в теме

(31) Какая разница полная она или нет? )
Оно происходит быстро и удаляет файлы. Мне остальное не важно )

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

34. Vladimir Litvinenko 2944 15.09.18 22:29 Сейчас в теме

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

35. tsukanov 15.09.18 22:34 Сейчас в теме

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

36. tsukanov 15.09.18 22:43 Сейчас в теме

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

37. Vladimir Litvinenko 2944 15.09.18 23:20 Сейчас в теме

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

23. sergey.novikov 57 15.09.18 15:54 Сейчас в теме

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

40. sergey.novikov 57 17.09.18 12:05 Сейчас в теме

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

41. Vladimir Litvinenko 2944 17.09.18 12:24 Сейчас в теме

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

42. sergey.novikov 57 17.09.18 12:40 Сейчас в теме

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

44. Evil Beaver 8412 17.09.18 19:36 Сейчас в теме

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

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

43. aleximuson 17.09.18 18:41 Сейчас в теме

Я вот немного не понял роль Jenkins'а...
Вы сборку/тестирование руками запускаете?
Или Jenkins здесь используется как продвинутый шедулер?

Просто я из прочитанной мною информации о Jenkins вывел для себя следующий сценарий его использования:
0. Для Git{Hub,Lab, etc} настраивается хук, которой соединяет репозиторий с Jenkins'ом
1. Коммитится что-то в репозиторий
2. git-хук дергает Jenkins API
3. Jenkins реагирует на это, запускает сборку/тестирование/деплой

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

45. Vladimir Litvinenko 2944 17.09.18 23:45 Сейчас в теме

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

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

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

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

47. aleximuson 18.09.18 06:51 Сейчас в теме

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

48. aleximuson 18.09.18 07:10 Сейчас в теме

Пока я вижу следующие проблемы, препятствующие использовать методику, описанную в статье:
1. Версия платформы. Думаю у многий полно легаси конфигураций, написанных и работающих в 8.2. Которые работают и даже поддерживаются. Насколько я понимаю gitsync работает только с 8.3 (?) В readme.md gitsync'а не нашел информации о требованиях к системе в целом и к платформе в частности.
2. Дергать хранилище при каждом чихе. Мне кажется не самой хорошей идеей периодически трогать хранилище и выгружать из него изменения. При подготовке к релизу в хранилище выкладываются тонны кода, разными группами, все это без того вызывает конфликты блокировок, так еще gitsync будет подноги лезть?.
3. Сборка при каждой закладке хороша, если используется методология от 1С, упомянутая в статье, где каждая закладка влечет за собой изменение версии конфигурации. Если в Вашей компании другой подход, например так называемый "релизный поезд". Все готовые фичи выкладываются в хранилище по мере их готовности, раз в неделю специально обученный человек говорит "баста, это будет новая версия". Захватывает корень, меняет версию конфы, ставит соответствующую метку. Вот тут, и только тут бы запустить сборку/тестирование/деплой всей конфигурации в целом.

ИМХО

50. Vladimir Litvinenko 2944 18.09.18 09:55 Сейчас в теме

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

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

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

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

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

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

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

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

Ответить

51. Aleximus_III 18.09.18 11:25 Сейчас в теме

(50) Легаси код - наследие предков, когда-то в бородатые времена написанная конфигурация. Мне встречались в основном отраслевые решения, аналогов которых не было на тот момент, написанные с нуля. Этот черный ящик как-то работает, есть не просит, но и его приходиться поддерживать и даже что-то дорабатывать/исправлять баги.
Никто не говорит что перевести это все на 8.3 невозможно. Просто никто на это не даст денег. ~~Ну или не те и не так продают~~ :)
Если Вы с такими конфигурациями не сталкивались, я Вам завидую :).

Автоматическое тестирование - да, слышали. Весь покрытый тестами, абсолютно весь, где-то в индустрии есть :)))
Но я не писал про автоматическое тестирование, просто тестирование, отделы целые имеются в компаниях, руками все тестируют. Ужасно? Каменный век? Бесспорно!

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

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

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

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

52. Vladimir Litvinenko 2944 18.09.18 12:50 Сейчас в теме

(51) Дело в том, что основной смысл применения Git в коллективе разработчиков 1С - это совместная работа над качеством кода, правильностью алгоритмов, структур данных. Снижение технического долга, о чем есть замечательный доклад Никиты Грызлова Управление техническим долгом - Концепция Continuous Inspection

Тот же быстрый доступ к истории кода имеет смысл только когда этой возможностью пользуются. А это невозможно, если коллеги воспринимают код друг друга согласно антипаттерну "Это-Не-Моя-Правка" : http://lurkmore.to/Анти-паттерн.

Если про это не говорить, то есть ли смысл вообще говорить про Git?

Автоматизированное тестирование и даже сборку можно сделать и без применения Гита. Достаточно фиксировать в каком-нибудь файле последнюю обработанную версию хранилища. Затем делать выгрузку следующей версии и обрабатывать ее. Для выгрузки версии хранилища в cf-файл есть простая консольная команда. Если начиная с определенной версии хранилища объявляется готовность именно этой версии к релизу, то это более простой вариант для выдергивания версии хранилища для релиза, чем через посредничество гита для этого. Это подход "в лоб" но если система уже работает так и менять процессы нет желания, то применить такой подход быстрее всего.

Если действительно хочется начать применять описанные инструменты - начните с код-ревью, ретроспектив и работы над процессом. С фиксации технического долга, возврата задач на доработку по причине некорректного/неоптимального кода, а не только по жалобам пользователей. С проверки на соответствие стандартам https://its.1c.ru/db/v8std. Начать кстати можно даже не выходя из экосистемы 1С : Автоматизированная проверка конфигурации

А дальше и остальные инструменты можно подключать постепенно.

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

Если же в Вашей команде подобных антипаттернов нет или вы решили взяться за их исправление, то вероятность успеха высокая. Не думайте, что есть мега крутые команды, где взяли и покрыли всё тестами и за ними теперь не угнаться. Многие только в начале или середине пути. Это процесс постепенный и движется, если есть к нему интерес и регулярные усилия. Главное понимать без чего именно это "не взлетит". И это не только инструменты ))

За пределами 1С всё, о чем мы говорим, вообще воспринимается как должное и как неотъемлемая часть разработки. Java, .Net, даже PHP-разработчики во всю используют эти подходы и делают круглые глаза, когда узнают том, как сильна наша замкнутость на экосистеме 1С. А ведь у них тоже базы данных есть и релиз не всегда означает изменение только кода на PHP. У них тоже код часто связан со структурами данных в БД и должен меняться синхронно с изменением структуры БД.

Ответить

54. Evil Beaver 8412 18.09.18 13:28 Сейчас в теме

(51)

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

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

53. Evil Beaver 8412 18.09.18 13:25 Сейчас в теме

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

49. DeniVi 18.09.18 08:16 Сейчас в теме

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

55. Evil Beaver 8412 18.09.18 13:29 Сейчас в теме

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

60. strange2007 149 19.09.18 11:11 Сейчас в теме

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

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

61. elu.viro36 21.09.18 09:42 Сейчас в теме

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

62. ilyatroitskiy 24.09.18 10:58 Сейчас в теме

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

Подскажите по какой причине может очень долго проходить выгрузка в файлы?
Вот пример, на 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

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

63. elu.viro36 25.09.18 05:48 Сейчас в теме

(62)

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

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

64. Serg O. 337 21.11.18 17:05 Сейчас в теме

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

!!! HELP !!!

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

куча внешних файлов - и на КАЖДЫЙ
- 2 раза Конфигуратор 8.3 спрашивает (см.фото 1 и 2)

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

Прикрепленные файлы:

65. Vladimir Litvinenko 2944 21.11.18 17:59 Сейчас в теме

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

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

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

ИТС : https://its.1c.ru/db/v838doc#bookmark:adm:TI000000377
Документация по precommit1C : https://github.com/xDrivenDevelopment/precommit1c

66. Serg O. 337 22.11.18 01:51 Сейчас в теме

(65) спасибо

DisableUnsafeActionProtection=.*

помогло!

67. Serg O. 337 27.11.18 15:09 Сейчас в теме

очень много кода ... попроще можно было бы...

для запуска по расписанию (когда 1 база - можно все параметры как переменные объявить)
и достаточно 1 строки в "батнике":

oscript c:\1c\myScript.os

P.S. достаточно 2х - 3х шагов:
опытным путём... копирования файла хранилища на локальный быстрый диск (SSD) - и распаковка его локально - идём в 5-10 раз быстрее, чем из "оригинала" хранилища (с которым ещё могут и работать)

// шаг 1 (не обязательно, но так быстрее!) - скопировать файл хранилища на "быстрый" диск
ВыполнитьКомандуCMD("copy /Y "+КаталогХранилища+ИмяФайлаХранилища+" "+КаталогХранилищаРабочий+ИмяФайлаХранилища);

//шаг2 - Распаковка хранилища в файлы
	ВыполнитьКомандуCMD("gitsync export """+КаталогХранилищаРабочий+""" src\config");

//шаг3 - помещение файлов в  Git репозиторий в ветку ИмяВетки (master/develop/...)
КомандаPush = "git push "+ИмяРепозитория+" "+ИмяВетки;
	ВыполнитьКомандуCMD(КомандаPush);

=============================а уже как улучшения - проверка изменения файла / ХЭШа===============

Если ФайлХранилищаНеИзменился(КаталогХранилища, КаталогХранилищаРабочий, ИмяФайлаХранилища) Тогда
	Сообщить("Хранилища - ОДИНАКОВЫ!", СтатусСообщения.Информация); // зелёным цветом!
иначе
// все 3 шага ...

//====> теперь и проверка хэша не нужна, хотя и можно... перед 2-ым шагом делать проверку
ХешПоследнегоКоммитаДоВыгрузки = ВыполнитьКомандуCMD("git log -1 --pretty=format:""%H""");

//====> теперь и проверка хэша не нужна, хотя и можно... перед 3-им шагом делать проверку
ХешПоследнегоКоммитаПослеВыгрузки = ВыполнитьКомандуCMD("git log -1 --pretty=format:""%H""");
Если ХешПоследнегоКоммитаДоВыгрузки  = ХешПоследнегоКоммитаПослеВыгрузки  тогда
сообщить("Хэш = "+строка(ХешПоследнегоКоммитаПослеВыгрузки)+" НЕ Изменился! Выгрузка в GIT - не требуется!", СтатусСообщения.Информация);
КонецЕсли;



//+++ функция проверки 1 файла в разных папках (по размеру / дате ) 
//       ТРЕБУЕТСЯ  #Использовать fs
//
функция ФайлХранилищаНеИзменился(КаталогХранилища, КаталогХранилищаРабочий, ИмяФайлаХранилища)
	рез  = ЛОЖЬ;
	ФайлХранилища = Новый Файл(КаталогХранилища + ИмяФайлаХранилища);		размерОбщ = ФайлХранилища.Размер();  ДатаИзмОбщ = ФайлХранилища.ПолучитьВремяИзменения();
	ФайлРабочий   = Новый Файл(КаталогХранилищаРабочий + ИмяФайлаХранилища);размерРаб  = ФайлРабочий.Размер();   ДатаИзмРаб  = ФайлРабочий.ПолучитьВремяИзменения();
	Сообщить("Общ.Хранилище "+строка(ДатаИзмОбщ)+" "+строка(размерОбщ)+" Байт");
	Сообщить("Раб.Хранилище "+строка(ДатаИзмРаб)+" "+строка(размерРаб)+" Байт (+"+строка(размерОбщ-размерРаб)+")");
	рез  = (размерОбщ = размерРаб); // и (ДатаИзмОбщ <= ДатаИзмРаб ); //достаточно только РАЗМЕРа!
	ФайлХранилища = Неопределено;
	ФайлРабочий   = Неопределено;
	возврат рез;	
КонецФункции

Показать

Прикрепленные файлы:

68. Vladimir Litvinenko 2944 27.11.18 15:55 Сейчас в теме

(67)

опытным путём... копирования файла хранилища на локальный быстрый диск (SSD) - и распаковка его локально - идём в 5-10 раз быстрее, чем из "оригинала" хранилища (с которым ещё могут и работать)

Да, такой подход может применяться, но нужно учесть что:

1) Будет ли ускорение зависит от канала связи.

2) Копирование хранилища придется выполнять каждый раз, даже если изменений в нем не произошло. При большом размере хранилища это большие накладные расходы.

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

4) Выгрузка версии из хранилища (чтение) не мешает одновременно работать с ним на запись (помещать новую версию)

достаточно только РАЗМЕРа

Пишу про хранилище без режима совместимости, в режиме совместимости не проверял.

К сожалению не достаточно проверять только размер. Более того, даже дата изменения не всегда меняется при помещении изменений в хранилище. И наоборот, иногда размер и дата меняется, когда в хранилище не происходили изменения. Возможно это связано с механизмом работы сервера хранилища. Но вот такое поведение.

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

очень много кода ... попроще можно было бы...

Да, можно было бы одной командой обойтись, особенно если сообщения от скрипта читает человек.
gitsync без команды export вообще позволяет указать адрес удаленного репозитория в параметрах командной строки - сам и отправит изменения без отдельного выполнения команды push.

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

Вот например мой текущий скрипт Jenkins, отправляющий email в случае ошибки и переводящий задачу в статус "Отменена" в случае если выгружать нечего. Кода становится еще больше ))) :



def emailJobStatus(status){

    emailext (
        subject: "${status}: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]'",
        body: """<p>BUILD STATUS IS ${currentBuild.result}: Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]':</p>
            <p>Check console output at "${env.JOB_NAME} [${env.BUILD_NUMBER}]"</p>""",
        recipientProviders: [[$class: 'DevelopersRecipientProvider']],
        to: "my.email@mydomain.com"
    )

}

pipeline{

    agent { label 'storage_export' }

    stages{ 
        
        stage('Выгрузка хранилища конфигурации') {
            steps{
                
                script{
                    
                    def statusCode = bat script:
                                            """chcp 65001
                                            process-storage.bat""", 
                                        returnStatus:true

                    echo "statusCode = ${statusCode}"
                    
                    if (statusCode == 100){
                        currentBuild.result = "ABORTED";
                    }
                    else if (statusCode != 0)
                    {
                        currentBuild.result = "FAILURE";
                    }
                    
                              
                } // script

            } // steps

        }  // stage          

    }

    post {        
        failure {
            emailJobStatus "BUILD FAILED"
        }
    }         
}

Показать

69. Serg O. 337 27.11.18 17:48 Сейчас в теме

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

я про статью в целом - сразу вываливать 3х параметрическую функцию... не очень понятно зачем
в итоге пришлось самому почти с нуля копать... даже просто скопипастить - не работает в итоге ничего!?
пришлось переписывать функции под себя... на onescript-е
и изобретать снова свой велосипед...с квадратными колёсами

для "работы" - всего 3 строки достаточно для начала, даже 2х (без копирования хранилища)
а уже эти 2 главных шага "обворачивать" в мега-проверки и супер-пупер-функции

70. Serg O. 337 27.11.18 18:00 Сейчас в теме

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

71. petrov_2015 16.01.19 10:16 Сейчас в теме

Очень достойный (с претензией на академичность) труд. Спасибо. Зашло.
Поскольку данная инструкция пошагово применялась в действии, то с учетом юниорства возникли вопросы:
- "Настройка .gitignore" есть смысл перенести До "Создание ветки develop"
иначе находясь в develop и создав и закомитив .gitignore и далее переключившись на master обнаруживается отсутствие .gitignore
- "Первая выгрузка" есть смысл рекомендовать с ключом "-limit 1",- она же Первая
- "Пишем скрипт выгрузки" там осознанно пропущен код собственно запуска gitsync, который имеется в скачанном скрипте?

и по существу:
- планируется ли отдельная статья (или дополнение к этой) по Jenkins?
- как Вы синхронизируете хранилища Расширений с git?

72. Vladimir Litvinenko 2944 16.01.19 11:36 Сейчас в теме

(71)

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

Да, конечно, так можно сделать. В этом случае нужно будет сначала сделать коммит в ветку master поместив в историю репозитория этот файл, а затем создать ветку develop командой git checkout -b develop. Это создаст ветку develop из ветки master сохранив её содержимое. Точнее говоря символическое имя develop будет указывать на тот же коммит, что и ветка master - так точнее понимать ))

Если же этого не делать, но при это вы хотите иметь в ветке master тот же самый gitignore то после его создания можно переключиться на ветку master и выполнить команду git merge develop. В этом случае все изменения из develop будут присутствовать и в ветке master.

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

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

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

Но если есть желание выгрузить вручную только первый коммит, а дальше максимально рано поставить всё на автоматику с логами, отчетами Jenkins по времени и успешности выгрузки, то это хорошая причина чтобы первую выгрузку сделать с параметром -limit 1. А дальше подключить скрипт выгрузки с этим же параметром как в публикации. Я всегда именно так поступал, как-то более прозрачно это кажется что-ли ))

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

Нет, код запуска есть и в скрипте в самой публикации. Там же есть строки

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

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

А ещё чуть ниже

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

Может быть где-то ещё ошибка в публикации? Уточните пожалуйста, если действительно есть.

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

Прежде чем ответить на вопрос сначала ссылку дам. Выше дважды задавался вопрос зачем вообще так сложно сделана выгрузка и зачем через скрипт. Возможно Вам пригодится информация из комментария http://forum.infostart.ru/forum9/topic199748/message2095295/#message2095295. В нём я объяснял, что это было сделано как раз для Jenkins , приведен Jenkinsfile для запуска скрипта и написано как поменять скрипт, чтобы он под этот пайплайн подходил (в одно из случаев возвращать код возврата 100). Если будут вопросы - задавайте.

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

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

И третья причина - сейчас сосредоточился на публикациях по Vanessa-ADD. Готов материал для следующей публикации по установке инструментов. Эта информация более универсальна.

А по Jenkins лучше меня расскажет Кирилл Семаев https://www.youtube.com/user/itsemaev, уже три отличных видео вышло. Еще по этой теме две ссылки на курсы в публикации приводил. Они тоже толковые. Очень рекомендую.

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

Расширений сторонюсь. Очень они нарушают единство кода и дробят его. В 1С итак никакого High Cohesion, Low Coupling не наблюдается, а с расширениями вообще жвах получается. Вот для технологии патчей они подходят или в качестве самостоятельных плагинов тоже очень подходят. Но на предприятии разработку с ними вести не хотел бы, мне кажется надежнее KDiff3 подключить для безопасного обновления типовой конфигурации. Хотя коллеги расширения используют, наблюдаю как они отваливаются потом периодически ))

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

http://forum.infostart.ru/forum9/topic204347/message2094553/#message2094553
http://forum.infostart.ru/forum9/topic204347/message2095157/#message2095157
http://forum.infostart.ru/forum9/topic172229/message1796840/#message1796840
http://forum.infostart.ru/forum9/topic174445/message1820669/#message1820669

Кроме того gitsync v2 сейчас не работает с расширениями. Возможно функционал появится в 3-ей версии. Вот открытый иссшуз на это: https://github.com/oscript-library/gitsync/issues/122

73. petrov_2015 16.01.19 12:48 Сейчас в теме

(72)
- Комментарии по поводу "Настройка .gitignore" и "Первая выгрузка" - это мне как джуниору в этой теме было понятнее и проще
- "Пишем скрипт выгрузки" - Да, пардон, в статье есть блок кода вызова gitsync (почему обратил на него внимание только в скачанном скрипте?)
- по Jenkins: скрипт увидел, с какого видео начать понял. Спасибо.
- по Расширениям: приходится их использовать для Бухгалтерии и ERP
странно, что структура хранилища расширений похожа на обычное и Просматривается Tool1C, НО конфа Не выгружается,
штатное же в gitsync v2 взаимодействие с хранилищем тоже не работает. Иссшуз 122 видел, какие-то движения есть в v8storage https://github.com/khorevaa/v8storage/issues/4

74. petrov_2015 24.01.19 12:55 Сейчас в теме

(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 - это видно в консоли вывода.
Что не так? В синтаксисе или какие галочки/плагины нужно добавить?

75. Vladimir Litvinenko 2944 24.01.19 14:34 Сейчас в теме

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

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

D:\jenkins\workspace\erp_export_storage_to_git

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

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

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

76. petrov_2015 24.01.19 15:45 Сейчас в теме

(75)
Настройки и результат на прикрепленной картинке.
Путь конечно же указываю, но более никаких галочек в настройка Item не ставлю. Запускаю пока опцией "Выбрать сейчас".
Вместо "process-scheduler.bat" подставлял его содержимое.
Пробовал "простой" bat-ник: bat 'echo %PATH%'
Результат Не меняется. Такое подозрение на синтаксис запуска bat-ника?

Прикрепленные файлы:

78. Vladimir Litvinenko 2944 24.01.19 17:27 Сейчас в теме

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

77. Vladimir Litvinenko 2944 24.01.19 17:17 Сейчас в теме

(76)
У вас судя по всему вообще не выполняется шаг bat
Результат каждой из строк этой команды должен выводиться сразу, не дожидаясь выполнения остальных команд.
Вот например в батнике ставлю паузу 20 секунд. Но результат выполнения строк по переключению кодовой страницы и смены директории выводится в stdout (точнее в лог задачи) сразу:

То есть в Вашем случае дело не в bat-файле и не в скрипте .os , а в том, что команда bat не выполняется. Может быть для этого есть какие-то настройки безопасности? Проверьте также установлен ли у Вас плагин
https://wiki.jenkins.io/display/JENKINS/Pipeline+Nodes+and+Processes+Plugin
Насколько понимаю он нужен для шага bat в пайплайне. Но у меня этот плагин ставился при установке Jenkins и я не могу его даже удалить. Поэтому если его нет, то возможно проблема была в установке Jenkins.

79. petrov_2015 25.01.19 10:28 Сейчас в теме

(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

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

Для отправки сообщения требуется регистрация/авторизация

Автор:

Владимир Литвиненко (Vladimir Litvinenko)

Рейтинг: 2944

Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.

Публикация:

№ 903269

Создание 14.09.18 09:30

Обновление 14.09.18 09:30

Статистика:

Просмотры 72240

Загрузки 111

Рейтинг 289

Комментарии 103

Характеристики:

Код открыт Да

Рубрики OneScript

Кому Системный администратор ,
Программист

Тип файла Архив с данными

Платформа 1С:Предприятие 8

Конфигурация Универсальные

Операционная система Не имеет значения

Страна Не имеет значения

Отрасль Не имеет значения

Налоги Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Абонемент ($m)