Введение
В 1С для хранения кода, его истории и ведения совместной работы используется хранилище конфигурации. Для других языков программирования тоже используются системы управления версиями кода. На данный момент одной из наиболее распространенных систем управления версиями является git. Историю git можно также узнать в сети, но, думаю, достаточно будет сказать, что на данный момент разработка ядра Linux ведётся при помощи этой системы, чтобы убедить: git — это серьёзно.
Если сравнить возможности git и хранилища конфигурации 1С, то для git можно выделить ряд полезных особенностей:
- git — распределённая система управления версиями. В отличие от хранилища конфигурации, для работы с git не требуется иметь доступ к серверу, хранящему код. Всё, что нужно для работы, хранится локально, достаточно время от времени (желательно регулярно) проводить синхронизацию локальных изменений и изменений других разработчиков. Обратной стороной этого достоинства является то, что при синхронизации могут возникнуть конфликты, которые нужно разрешать вручную. В случае с 1С здесь имеются сложности, так как значительную часть кода конфигурации представляют формы, макеты и другие типы данных, хранящиеся в виде xml документов. Ручное объединение таких документов представляет достаточно трудоёмкий процесс.
- git blame. Очень часто требуется выяснить, кто, когда и зачем добавил или изменил ту или иную строку кода. Можно потратить не один час, решая эту задачу средствами хранилища конфигурации 1С, а средствами git это делается моментально.
- Ветки. В репозитории git можно организовать ветки кода, в которых хранить альтернативные версии продукта или вести параллельную разработку с последующим их слиянием. Особую ценность представляет возможность управления разработкой посредством веток, называемая "git flow".
- Хранение любой информации. В отличие от хранилища 1С, в git можно хранить любую информацию (желательно текстовую, но это не обязательно). Поэтому при использовании git возникает возможность хранить не только конфигурацию, но и все внешние отчеты, обработки и другую сопутствующую информацию.
Возникает вопрос, а можно ли при текущем варианте разработки, без использования EDT, использовать git? Ответ на этот вопрос: "да".
В этой статье я не буду касаться вопросов установки git, его использования и других широко освещенных в сети тем. Будем считать, что базовые знания по работе с git у вас уже есть и вы умеете пользоваться github’ом, а также умеете устанавливать программы на компьютер, создавать службы и выполнять другие административные операции.
Git & 1С
Для начала зафиксируем стандартный процесс разработки решений для платформы 1С:Предприятие:
- Разработка ведётся коллективом разработчиков при помощи конфигуратора;
- В качестве системы управления версиями используется хранилище конфигурации;
- При доработке кода, в коде, как правило, оставляются комментарии с информацией, кто, когда и почему изменил код. При этом прокомментировать таким образом изменения в формах или макетах вообще не представляется возможным.
- Управление внешними обработками осуществляется вручную, а сами обработки хранятся в файловой системе. Получить предыдущие версии обработок, скажем для старых версий продукта, зачастую, если такая возможность заранее не была предусмотрена процессом, невозможно.
Разумеется, таким образом процесс разработки организован не у всех, но это наиболее распространённая схема совместной работы.
С выходом EDT становится возможным работать без использования конфигуратора и хранилища конфигурации, но этот вариант я не буду рассматривать в данной статье: сейчас немногие энтузиасты готовы перевести процесс разработки в EDT, да и классический процесс разработки будет применяться ещё довольно долго. В случае же использования EDT, работа с git не только упрощается, но и отпадает необходимость обоснования использования git, т. к. git становится единственным (пока?) средством управления версиями кода.
Итак, что мы можем получить от использования git в проекте разработки продукта на основе 1С:Предприятие?
На первое место я бы поставил возможность получать информацию об источнике изменений (git blame). Теперь разработчик не обязан помещать в код метки, указывающие причину изменения кода, git всё это делает сам. Код становится чище, разработчику нужно делать меньше непродуктивной работы. Помимо этого, также становится доступной история изменений в макетах и формах.
Во-вторых, в git-репозитории, наряду с конфигурацией можно хранить внешние отчёты и обработки, что позволит не только получать информацию об истории изменений, но и версии этих обработок на любой момент времени, что до того достигалось при помощи определённых усилий со стороны разработчиков.
В-третьих, в git-репозитории можно хранить не только код, но и документацию к продукту, что также решает массу проблем с организацией процесса документирования и получения истории изменения документации.
Давайте определим, каким должен быть процесс разработки, исключим из существующего процесса лишние элементы, а какие-то элементы изменим и, возможно, введём новые.
- Разработка должна вестись в конфигураторе, как и раньше.
- Если возможно, вести разработку без хранилища конфигурации, ведь ему на замену мы решаем ввести git. Забегая вперёд скажу: это, к сожалению, сделать будет нельзя, по крайней мере, без существенного усложнения процесса разработки, но ведь мы добиваемся обратного — его упрощения!
- Отсутствие необходимости комментировать изменения кода в самом коде. Описание изменений хранить отдельно от кода. По правде сказать, это можно делать и сейчас, заполняя комментарий версии при помещении объектов в хранилище конфигурации, однако в текущем виде комментарии могут дать ответ на вопрос, что было изменено в текущей версии, но нет инструмента, позволившего бы ответить на вопрос, в какой версии был изменён конкретный кусок кода.
- Внешние отчеты и обработки должны храниться вместе с кодом разрабатываемого продукта. При этом они также должны версионироваться по общим правилам версионирования кода git.
- Документация к продукту (пользовательская и разработческая) также должна располагаться в хранилище продукта. В конечном итоге, история изменения документации также представляет интерес, как и история изменения кода продукта.
Что можно сделать уже сейчас?
"Превращение" конфигурации в исходный код. Это делается при помощи меню конфигуратора "Конфигурация/Выгрузить конфигурацию в файлы" или использования ключа запуска конфигуратора "/DumpConfigToFiles". Однако следует помнить, что при работе без хранилища конфигурации возможны одновременные изменения одних и тех же объектов несколькими разработчиками, поэтому перед выгрузкой своих изменений нужно сначала произвести их слияние с изменениями других разработчиков.
Другими словами, при изменении конфигурации необходимо:
- выгрузить свою текущую конфигурацию в файлы;
- собрать из текущего состояния кода продукта конфигурацию (делается также через меню конфигуратора "Конфигурация/Загрузить конфигурацию из файлов" или ключа запуска конфигуратора "/LoadConfigFromFiles");
- выполнить получение изменений в локальный репозиторий продукта (pull);
- произвести сравнение/объединение текущей конфигурации продукта со своими изменениями;
- выполнить сохранение конфигурации в файлы, расположенные в локальном репозитории продукта;
- произвести commit изменений с указанием комментария изменений;
- выполнить push изменений в центральный репозиторий. При этом нужно быть готовым к тому, что с момента начала помещения Ваших изменений в git-репозиторий кто-то мог сделать это быстрее и при помещении изменений могут возникнуть конфликты, требующие ручного их разрешения. Для этого описанный здесь алгоритм нужно будет выполнять повторно.
Согласитесь, не самый простой способ до того так просто выполняющейся операции. Причём основную массу проблем вызывает именно асинхронные изменения кода, если их исключить, можно существенно упростить описанный процесс публикации изменений. Таким образом мы вынуждены вернуться к идее использования хранилища при разработке, к тому же у нас возникает единая точка возникновения изменений: не отдельная база разработчика, а само хранилище конфигурации. Каждое помещение изменений в хранилище и является отдельным коммитом в git-репозиторий. В результате, процесс помещения изменений в git-репозиторий существенно не изменяется:
- разработчик помещает изменения в хранилище конфигурации;
- производится выгрузка помещенных изменений в git.
Последний пункт не обязательно выполнять разработчику, его можно автоматизировать при помощи того же jenkins, в результате чего процесс разработки вообще останется без изменений.
Правда теперь выгрузку конфигурации придётся производить немного по-другому. Для выгрузки версии хранилища нужно сначала получить базу данных с нужной версией хранилища и затем уже выполнять её выгрузку в файлы. Для загрузки нужной версии конфигурации из хранилища используется ключ запуска конфигуратора "/ConfigurationRepositoryUpdateCfg". Выгрузку можно производить периодически или по факту изменения хранилища. При этом нужно "помнить" номер последней выгруженной версии хранилища и последовательно выгружать только те версии, которые появились после последней выгруженной.
Алгоритм выгрузки конфигурации получается следующим (я рассматриваю вариант с использованием git-сервера):
- клонируем репозиторий продукта в пустой каталог. Это необходимо, чтобы исключить влияние локальных изменений и выгружать конфигурацию в репозиторий, содержащий все изменения;
- определяем номер последней выгруженной версии хранилища;
- создаём пустую базу (команда запуска "CREATEINFOBASE") и подключаем её к хранилищу (ключ запуска конфигуратора "/ConfigurationRepositoryBindCfg")
- для каждой версии, большей, чем определённая на втором шаге, последовательно производим:
- обновление конфигурации на следующую версию хранилища;
- выгрузку конфигурации в каталог исходников в локальном git-репозитории;
- выполняем commit изменений с комментарием, указанном в хранилище конфигурации;
- устанавливаем номер последней выгруженной версии;
- выполняем push произведённых изменений в центральный репозиторий.
Таким образом в git-репозитории продукта у нас окажутся все версии хранилища со всей историей. Однако в процессе выгрузки изменений нужно будет решить вопрос с авторством коммитов, т. к. исходя из целей, в git-репозитории нам важно знать, кто произвёл те или иные изменения. Коммиты необходимо выполнять от имени их авторов с указанием их e-mail’ов.
gitsync
Безусловно, подобный функционал может реализовать почти каждый разработчик, и было бы странно, если бы эту функцию реализовывала каждая команда разработчиков и ни одна не поделилась бы результатами: готовым решением для синхронизации хранилища конфигурации и git-репозитория.
Такое решение существует, называется оно gitsync и реализовано на языке OneScript. Благодаря привычному синтаксису языка 1С:Предприятие, программы на OneScript будут понятны любому 1С-разработчику. Более того, на этом языке уже реализована масса инструментов предназначенных для автоматизации разработки на платформе 1С:Предприятие. В этой статье описаны существующие библиотеки для данного языка.
Здесь я продемонстрирую, как выполнить синхронизацию хранилища с git-репозиторием.
Для начала надо установить сам OneScript. Отсюда берём сам интерпретатор (в удобном для Вас виде и под Вашу платформу) и устанавливаем его в систему. Я буду демонстрировать использование на примере платформы Windows. По умолчанию OneScript устанавливается в каталог "C:Program Files (x86)OneScript" и в переменную "PATH" прописывается путь к каталогу исполняемых файлов OneScript "C:Program Files (x86)OneScriptin". Если ы устанавливали OneScript не при помощи установщика, то вам придётся прописать путь к этому каталогу самостоятельно.
Далее нужно установить gitsync (возможно он уже установлен вместе с OneScript, но в будущих версиях OneScript gitsync может быть убран из стандартной поставки). Установка библиотек и приложений OneScript, производится специальной утилитой "opm" (OneScript Package Manager, поставляется вместе с интерпретатором) из специально созданного хаба, куда разработчики помещают эти библиотеки и приложения. Разумеется, это не единственный способ устанавливать библиотеки и приложения. Их можно разработать самому или скачать из сети и сохранить в любой каталог, предварительно "сообщив" интерпретатору, что библиотеки и приложения нужно искать ещё и в нём.
На всякий случай выполним обновление библиотек оскрипта (данный шаг выполнять не обязательно, если у вас уже установлены последние версии библиотек):
REM Обновим только opm
> opm update opm
REM Обновим все установленные библиотеки
> opm update -all
REM Установим gitsync
> opm install gitsync
Нужно помнить, что в большинстве случаев данные команды надо выполнять с правами администратора, т. к. обновляемые библиотеки располагаются в иерархии каталога установки OneScript, в который запрещена запись простым пользователям.
После установки, gitsync доступен для запуска, т. к. скрипт запуска создаётся в каталоге исполняемых файлов OneScript. Ознакомиться с параметрами запуска gitsync можно при помощи команды
> gitsync help
Теперь нужно настроить git-репозиторий для работы с gitsync. Для этого надо создать в репозитории каталог, в котором будут храниться исходники конфигурации (примем, что это будет каталог "cf" в корне репозитория), инициализировать gitsync в данном репозитории, настроить пользователей хранилища и указать версию хранилища, начиная с которой нужно выполнять синхронизацию.
REM Здесь я создам сам git-репозиторий. Это делать не надо, если у вас уже есть git-репозиторий
> git init myProduct
> cd myProduct
REM Создадим каталог исходников
> md cf
REM Инициализируем gitsync. Здесь нужно указать путь к хранилищу конфигурации,
REM пока сетевой, но в будущем появится возможность указывать хранилище, расположенное
REM на сервере хранилища конфигурации и предоставляемое по протоколам tcp или http
REM
REM указание домена e-mail адресов не обязательно, но тогда вам потребуется указать его
REM вручную для каждого пользователя хранилища конфигурации
> gitsync init d:/path/to/storage/product cf -email my.domain.com
В результате выполнения этой команды в каталоге "cf" создались два файла: "AUTHORS" и "VERSION". В файле "AUTHORS" указаны все пользователи хранилища, здесь надо проверить правильность указания e-mail адресов этих пользователей. Все коммиты в git-репозиторий будут производиться от имени пользователей с этими e-mail’ами. Файл "VERSION" имеет формат xml и содержит единственный узел "VERSION", в который нужно записать номер версии хранилища, начиная с которой необходимо выполнять синхронизацию. Делать это вручную не обязательно, для этого у gitsync есть команда "set-version". Выполняем
> gitsync set-version cf 0
где "cf": — каталог, в котором расположен файл "VERSION", а 0: — номер версии, начиная с которой нужно выполнять синхронизацию.
К этому моменту к синхронизации всё готово. Выполняем команду
> gitsync export d:/path/to/storage/product cf
и ждём. Если у вас большая конфигурация или в хранилище достаточно много версий, ждать придётся ощутимо долго, будьте к этому готовы. Однако можно разбить синхронизацию хранилища с git-репозиторием на несколько этапов, выгружая за один запуск gitsync по небольшому количеству версий, указав ему параметры "-minversion" и "-maxversion". Также при запуске gitsync следите за версией платформы 1С:Предприятие (по умолчанию будет запускаться последняя версия), указать конкретную версию можно при помощи ключа "-v8version".
Всё. На данный момент в локальном git-репозитории мы имеем всю историю хранилища конфигурации и можно выполнить push в центральный репозиторий продукта на сервер, если у вас такой есть.
Для упрощения коллективной работы с репозиторием продукта я настоятельно рекомендую держать этот репозиторий на каком-либо git-сервере, но помните, что не всякий продукт можно выкладывать в общедоступные репозитории, например на github, из-за лицензионных ограничений. При этом есть возможность "поднять" свой собственный git-сервер внутри локальной сети. Есть разные git-серверы с разными возможностями, лицензиями и стоимостью, я использую простой и бесплатный gogs, но, наверное, сейчас остановил бы свой выбор на gitlab.
precommit1c
Теперь вернёмся к вопросу версионирования внешних отчётов и обработок. В последних версиях платформы есть возможность редактирования внешних отчётов и обработок в "иерархическом XML формате". В этом случае никаких особых действий производить не требуется. Правка отчетов и обработок, находящихся в репозитории продукта производится, как обычно, в конфигураторе, после чего осуществляется коммит изменений. При этом может возникнуть конфликт изменений, когда в репозитории на сервере находится более новая версия отчета/обработки, чем та, которая была изменена разработчиком. Здесь от разработчика потребуется произвести слияние изменения или внести свои изменения повторно, после получения свежей версии отчета/обработки. Впрочем, данный подход для git является штатным и к нему нужно привыкнуть, нужно только не забывать перед началом правки чего-либо получить свежие изменения в репозитории, а после изменений осуществлять коммит этих изменений и push на сервер.
Если же ваша платформа не поддерживает редактирование отчетов/обработок в "иерархическом XML формате", то можно воспользоваться специальной "утилитой" "precommit1c", которая является, по сути, набором git-"перехватчиков" (git hooks), выполняемых при какой-либо операции с репозиторием. В данном случае действия выполняются при коммите изменений в репозиторий. Для использования precommit1c необходимо его установить и настроить локальный репозиторий для работы с ним.
Установка самого precommit1c на компьютер производится через opm командой
> opm install precommit1c
Эту операцию, как уже говорилось выше, нужно выполнять с правами администратора системы. Настройка локального репозитория для работы с percommit1c выполняется командой
> precommit1c --install
запущенной в каталоге локального репозитория. Важно помнить, что данную операцию нужно выполнять в локальном репозитории каждого разработчика, в противном случае изменения обработки не отразятся в исходном коде этой обработки.
При коммите изменённой обработки в репозитории, precommit1c производит её разбор на файлы и помещает эти файлы в каталог "src" репозитория. Например, если обработка располагалась по пути "./epf/Внешние обработки/Моя обработка.epf", то исходники будут выгружены в каталог "./src/epf/Внешние обработки/Моя обработка". Также следует иметь ввиду, что формат выгрузки precommit1c не совместим с форматом хранения обработок в "иерархическом XML формате".
Собрать обработку обратно в epf файл можно при помощи того же precommit1c, используя команду "—compile", Например команда
> precommit1c --compile "/path/to/repository/src/epf/Внешние обработки/Моя обработка" "D:/epf"
создаст в каталоге "D:/epf" файл "Моя обработка.epf". Рекомендую при указании путей использовать прямые слеши ("/"), а не принятые в windows обратные. Это сэкономит вам массу времени и нервов при дальнейшей автоматизации процессов.
Структура репозитория
В процессе работы с продуктом у вас выработаются свои стандарты хранения информации внутри репозитория продукта. Вы для себя определите, где хранить файлы конфигурации, где хранить файлы внешних отчетов и обработок, где хранить документацию и прочие правила. Однако можно воспользоваться готовым шаблоном структуры репозитория продукта. В частности здесь можно "подсмотреть" рекомендуемую командой Silverbulleters иерархию каталогов. Возможно, изучение данной структуры поможет вам разработать подход к построению своей структуры, возможно, вы возьмёте данный шаблон за основу. Этот шаблон не догма и не руководство к действию, а только лишь пример.
Однако есть одна практическая рекомендация, которая может облегчить жизнь при дальнейшей эксплуатации различных инструментов: каталог исходников конфигурации нужно располагать как можно ближе к корню файловой системы. Причиной этому служит ограничение максимальной длины пути в операционной системе, особенно, когда в Вашей конфигурации присутствуют объекты с достаточно длинными наименованиями, что часто встречается в типовых конфигурациях и в БСП в частности. Эта рекомендация в большей степени касается windows, но 1С слабо отделим от windows, поэтому, даже если у вас вся разработка ведётся на Linux, всё равно не пренебрегайте этим правилом.
Итоги
В данной статье я попытался рассказать о способе включения git в процесс разработки решений на базе платформы 1С:Предприятие. Использование git позволяет расширить возможности хранения истории кода, проектной информации и документации. В дальнейшем, я постараюсь рассказать, как использование git позволит упростить построение инфраструктуры CI и, возможно, расскажу об основах ведения разветвлённой разработки 1С-конфигураций.
Ссылки
Первая часть: Введение в CI для 1С
Вторая часть: Использование git при разработке на 1С
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
Сначала расписываются преимущества распределенных CVS, а потом предлагается работать через хранилище, а гит использовать параллельно исключительно для удобства мониторинга репозитория? Я все правильно понял? 🙂
Да, всё правильно. Работая через хранилища, мы в итоге всё равно получим означенные преимущества.
Отчёты и обработки — само-собой.
git blame — тоже и сразу. Никаких
// 27.12.2017 Вася (Задача #123) { Добавленный код // }в коде.
С ветками придётся повозиться, но и тут без хранилища тоже никуда. Тем более в технологии вендора именно такая схема и описывается (см. «Технология разветвленной разработки конфигураций» на ИТС)
(3) можете как-то развернуть свой вброс?
(2) Как по мне — крайне неудачное сочетание ежа и ужа. Отчеты и обработки с документацией — они как бы сбоку, с ними все понятно.
Но геморроиться с совместным использованием двух CVS ради получения пары плюшек к первой из них — оверкилл.
Но это так, личное мнение. Раз вас устраивает, может и еще желающие найдутся.
Хотя первый раз такое применение вижу, обычно переползают на git именно из-за децентрализованности и git flow.
А вы намеренно оставляете централизованность, чтобы не мержить.
(5) Оверкилла, как такового нет. Делается один раз при настройке, а дальше работает само. Разработчики могут даже не знать об этом, удивляясь магии 🙂
А с git flow, как я сказал, придётся не просто, но, опять же, основная нагрузка придётся на внедрение, а сам процесс не сильно усложнится. Правда тут разработчикам уже надо будет знать/понимать что и зачем они делают.
(5)
К сожалению мержить конфигурации 1С без специализированных средств (конфигуратора) очень сложная и чреватая ошибками задача.
На самом деле, Технология разветвленной разработки конфигураций даёт ответ на все вопросы.
Использование git позволит построить полноценный CI (собственно, цель) с тестами и развёртыванием.
(7)
Это как раз понятно. При децентрализации придется разруливать конфликты, которые не возникают при централизованной разработке. Но на больших командах и проектах это окупается. А в маленьких командах обычно нет острой необходимости в git blame. Короче, сомневаюсь в широте целевой аудитории 🙂
(4) А что тут разворачивать? В 1с нет нормальных средств для распределённых средств.
Выгрузить конфигурацию и загрузить её обратно — занимает слишком много времени.
(9) Вроде в последних релизах что-то там серьезно улучшали в части инкрементальной выгрузки/загрузки конфы в файлики/из файликов, спецом для EDT.
Но «живых» отзывов не имею. Самому интересно.
ЗЫ. Т.е. теоретически загрузка/выгрузка теперь должна происходить пропорционально объему правок по скорости. А как оно на практике…
GIT и т.п. работает с кодом. Текстовыми файлами. Что именно должна сделать 1С чтобы вы могли версионировать и мержить текстовые файлы?
Есть проблема с метаданными, формами, их пересборкой. С самим кодом особых проблем нет.
Смотря какую конфу пилите — мини-самописка летает. А проекты уровня ERP у вас и на других платформах будут не быстро разворачиваться и компилиться.
Спасибо за статью, очень интересно.
Скажите использовали ли вы git для совместной разработки расширений 1С? От самой 1С хранилища расширений пока нет.
(12) Нет, не использовал, и, насколько я знаю, просто так это сделать сейчас нельзя. Всё, что доступно. это выгрузка расширений в файлы и загрузка обратно. Причём какой-либо методики централизованного управления разработкой расширений нет и у самой 1С, насколько я знаю.
Возможно через какое-то время ситуация изменится, но пока не известно, в какую сторону.
(11)
Тут всё отвечено ))
(12) Мы используем и вполне успешно.
Хотя, конечно, есть платформенные баги при выгрузке расширений 🙁 — например, роли выгружаются неверно.
Приходится следить за их выгрузкой в гит и удалять ненужные/недействительные изменения
но мы завязаны на используемую платформу 8.3.10.2299 у Заказчика.
(9) Нужен. Даже если использовать только «в одну сторону» для зеркалирования хранилища 1С на гит-сервер. Вы сразу же получите люшки в виде быстрой истории по коду, понимание того, кто и когда менял строчку кода, плюс привязку кода к задачам JIRA или Gitlab. Отзеркалировав свой код 1С в git (а это делается в фоне, автоматически без участия людей) вы получаете возможность пользоваться десятками инструментов из параллельного мира «не-1С» разработки.
(9) Можно ведь и не так глобально (в масштабах правки конфы) гит применять.
Как было упомянуто в статье, также применимо для хранения внешек. Это, к примеру, хорошо применится в авто-тестах — Jenkins будет выгребать внешки для xddTestRunner из гита и авто-тестировать.
Кстати, для желающих иметь собственный git-сервер — есть проект Bonobo. Наворачивается на IIS ()
(18) Еще GitLab есть, эдакий карманный GitHub. По слухам там страшная солянка технологий, но вроде есть готовые контейнеры для простого развертывания.
(19) Да, есть
(0) Спасибо, что ответы на свои вопросы в гиттере к авторам инструментов («несмотря на» и «вопреки всему» :)) и собственный опыт оформил в виде такой доходчивой и подробной статьи! Это однозначно лучше штатной документации.
Покажите ваш GitBlame в действии, покажите ваш SonarCube alert, покажите ваш Jenkins shedule, покажите ваш CodeReview comments, покажите ваш three-way merge, покажите…!
(22) С git blame проще всего. Как я говорил, оно работает «само» и не требует ничего, кроме наличия git.
Сонаром (пока) не пользуюсь, даже в глаза не видел. Планы есть, но не на ближайшую перспективу.
С jenkins’ом проще, это не последняя статья и в одной из следующих я планирую продемонстрировать, как я построил свой CI на практике.
С code review сложнее. Его нет по двум причинам. Во-первых gogs не очень поддерживает code review, а во-вторых в команде из одного разработчика данная функция не очень востребована )
Трёхстороннее сравнение тоже не использую. Как осуществлять мерж, у меня есть только теоретическое понимание, в любом случае я не думаю, что придётся делать что-то, кардинально расходящееся с методикой технологии разветвленной разработки конфигураций от 1С.
(21) И Вам спасибо на добром слове 🙂
(23) Хех, Sonar для 1С или у Silverbulleters покупать, или самому как-то пилить.
(23) можете подробнее расписать как вывести git blame.
Это только в консоле или можно как-то в source tree тоже вывести?
Спасибо.
(26) Не задумывался над возможностью blame в SourceTree. Нагуглилось такое: (выделяете интересующий файл и жмёте Alt-Shift-B). По мне, так не очень удобно, намного нагляднее и информативнее в VSC (Visual Studio Code — установить расширение Git Lens или Git Blame.
На фотографии в (23) виден результат работы обоих:
* Git Blame выводит результат в статус бар (с информацией «кто и когда»)
* Git Lens выводит в текущей строке (с информацией кто, когда и почему).
Да, не очень удобно смотреть эту информацию где-то отдельно (в том же VSC), было бы намного удобнее видеть это сразу в конфигураторе, но увы, причину, почему этого не будет, мы знаем. Будем ждать EDT, там эта возможность есть. С другой стороны, ответы на вопросы «кто? когда? почему?» нас интересуют эпизодически и при наличии каких-то побудительных причин, в процессе правки кода этим можно не интересоваться, хотя признаю, такая аргументация слабовата. Но в любом случае, данная информация у нас теперь есть и достать её не очень сложно, а это уже гигантский шаг.
(25) Чо, прям 2000 рублей для фирмы не найти, чтобы vanessa.services подключить?
(22) Показывал на инфостарт 2015, поищите.
(28) О. 2 тыр всего?? Я чет сходу ценник так и не увидел.
Можно ссылку?
(30) Уже 2500, спешите, как говорится.
(31) Аааа… Это месячная подписка.
А отдельно плагин для SQ продается?
(32) Да, но сильно дороже. По-моему, 2-3 мес. попробовать и понять — отличный сервис у ребят. Из коробки сразу работающее ВСЁ! И гиты и сонары и дженкинсы и трекинг задач. И никакого красноглазия и ручных настроек.
(33) Я понимаю, что сильно дороже. И красноглазие в зеркале видел;)
Но все ж. Сколько может стоить плагин отдельно?
(34) Напишите в Пулю, они точно знают.
(34)
еще 2 варианта к вышеописанному — облачный сервер и собственный сервер
(36) Ага, тоже видел… Посмотрим, может уломаю коллектив.
Подскажите еще какой порядок работы при поиске виновника ошибки.
Т.е например пользователь сообщает что в документе при проведении валит ошибку в модуле объекта такой-то строке.
Как оптимально найти в каталоге проекта этот модуль, чтобы посмотреть какие изменения были
т.е. через TotalCommander надо найти *Module.bsl и открыть его в VSC.
Или можно как-то более оптимально это сделать?
(38) в каталоге разобранной конфигурации вызовите F1, команду Language 1C (BSL):QuickOpen и наберите там первые буквы метаданного, в модуле которого ошибка
(38) Допустим репозиторий продукта лежит в каталоге «c:/product_repo», Исходники конфигурации лежат в каталоге «cf» («c:/product_repo/cf»). Если вы зайдёте туда в тотал-командере, то увидете выгруженную конфигурацию, разложенную по каталогам. Там будет каталог «Documents», в котором лежат выгруженные документы, будет каталог «Catalogs» со справочниками, каталог «DataProcessors» с обработками, «CommonModules» с общими модулями, etc. Нужный Вам модуль ищите в этой иерархии. Это всё достаточно очевидно, просто выполните в конфигураторе команду «Конфигурация/Выгрузить конфигурацию в файлы» в «Иерархический» формат и посмотрите, что будет лежать в репозитории.
Кстати, «находить» модуль в тотал-командере не обязательно, откройте сам репозиторий целиком в VSC (правой кнопкой на каталог репозитория и выполните команду «Open with Code»), так будет намного удобнее, не надо на каждый модуль открывать отдельное окно VSC.
Историю изменений конкретного файла можно смотреть в том же VSC. По мне, так там это реализовано не очень удобно, мне намного удобнее смотреть историю изменений непосредственно в web-интерфейсе git-сервера. В случае github-а это выглядит, например, так:
* blame:
* история:
(40)
— Доделана синхронизация и удалены лишние модули
— Скорректированы модули под рекомендации oscript
— gitsync: При уровне логирования debug не удаляем временные файлы fix #65
— немного косметики. + Бонусом 2 простые фичи
Казалось бы, пяток коммитов. Зачем разные комментарии на каждой строке? Зачем комментарии на пустые строки? Почему всё так перемешано? Как то не так я себе представлял blame..
(41) Это комментарии, заданные при коммите этой строки. Рассматривайте это так: «Эта строка появилась/изменилась в этом файле в результате доработки, опубликованной с этим комментарием».
Строки
Добавлены/изменены 2 года назад пользователем artbear с комментарием «gitsync: При уровне логирования debug не удаляем временные файлы fix #65», где «#65» — ссылка на задачу, которую он решал.
Строка
Добавлена/изменена пользователем bia-tech 11 месяцев назад с комментарием «Скорректированы модули под рекомендации oscript-app-template © EvilBeaver»
И так далее.
Пустые строки откомментированы, потому, что эти пустые строки тоже кто-то когда-то добавил.
Здесь видно, что artbear 2 года назад добавил 3 строки:
А пользователь nixel2007 11 месяцев назад, между
Добавил пустую строку.
Как-то так.
(41) Существует ли инструмент, который показывает не кто и когда наложил эту строку кода, а к какому функциональному блоку относится текущий абзац кода и почему он был написан именно так, с возможностью интерактивного ретроспективного анализа изменений с изменяемой детализацией?
(43) Вот это он и есть.
На примере моего предыдущего (42) комментария:
Переходим в комментарий «gitsync: При уровне логирования debug не удаляем временные файлы fix #65». Сразу видим изменения, которые были сделаны этим коммитом. Зелёные строки — добавленные, красные — удалённые.
В комментарии «#65», это ссылка. Переходим по ней и попадаем в задачу, при решении которой этот код был изменён именно так.
Хотя, возможно, я не понял вопроса.
Поставил последнюю версию oscript, пытаюсь выполнить:
opm update opm
В итоге:
КРИТИЧНАЯОШИБКА — {Модуль C:Program Files (x86)OneScriptlibopmsrcКлассыУс
тановкаПакета.os / Ошибка в строке: 336 / Ошибка установки пакета opm: Пакет не
найден}
Если так:
C:Windowssystem32>opm update -all
ПРЕДУПРЕЖДЕНИЕ — Ошибка обновления пакета 1commands: Пакет не найден в хабе
ПРЕДУПРЕЖДЕНИЕ — Ошибка обновления пакета asserts: Пакет не найден в хабе
ПРЕДУПРЕЖДЕНИЕ — Ошибка обновления пакета cmdline: Пакет не найден в хабе
ПРЕДУПРЕЖДЕНИЕ — Ошибка обновления пакета fluent: Пакет не найден в хабе
ПРЕДУПРЕЖДЕНИЕ — Ошибка обновления пакета fs: Пакет не найден в хабе
ПРЕДУПРЕЖДЕНИЕ — Ошибка обновления пакета json: Пакет не найден в хабе
ПРЕДУПРЕЖДЕНИЕ — Ошибка обновления пакета logos: Пакет не найден в хабе
ПРЕДУПРЕЖДЕНИЕ — Ошибка обновления пакета opm: Пакет не найден в хабе
ПРЕДУПРЕЖДЕНИЕ — Ошибка обновления пакета strings: Пакет не найден в хабе
ПРЕДУПРЕЖДЕНИЕ — Ошибка обновления пакета tempfiles: Пакет не найден в хабе
ПРЕДУПРЕЖДЕНИЕ — Ошибка обновления пакета v8runner: Пакет не найден в хабе
Из-за чего такое может быть?
Поставьте пока 18ю версию. С 19й есть вопросы совместимости
(45) у вас прокси нет, случаем?
(45) У вас прокси, похоже.
И какая версия OneScript стоит? Выполните oscript -version
также что показывает команда opm list
Конфигурация 1С от 1С, односторонняя синхронизация хранилища конфигураций 1С в репозиторий Git.
(49) Да, то же самое, только от 1С.
gitsync это инструмент. Можно взять другой (гитконвертер) и использовать его в этих же целях.
Кстати, есть и ещё один, не от 1С:
(44) инструменты для визуализации и навигации по нелинейной истории разработки
Масштаб. Выделение слоев можно применять на разных масштабах и уровнях абстракции. Важно понимать, что каков бы ни был уровень абстракции, на котором идет рефакторинг, всегда можно попытаться выделить слои и иметь достаточно хорошие шансы на успех; при этом не так важно, идет ли моделирование в терминах пакетов, компонентов, или даже файлов.
Более того, слои облегчают изменение масштабов абстракции, используемые для моделирования. Если в системе найдены слои, то изменение масштабов можно производить и вручную – несколько соседних слоев достояно легко объединяются в один слой, происходит укрупнение подсистем, с которыми идет работа. Понижение масштаба может быть достигнуто за счет разбиения одного слоя на несколько подслоев. Следует заметить, что это не всегда возможно, в отличие от объединения слоев, особенно без предварительной подготовки и вспомогательного рефакторинга систем разбиваемого уровня.
Время. Этот аспект касается того, когда нужно применять выделение слоев. Это достаточно хороший паттерн, чтобы с него начать анализ и рефакторинг архитектуры системы, особенно, если эрозия архитектуры не катастрофична. Выделение слоев ведет к тому, что рефакторинг архитектуры приобретает «направленность», задача сводится к меньшим подзадачам; теперь детальный семантический анализ можно применять только к тем слоям, которые имею непосредственное отношение к поставленной задаче. (с)
Я сам не понимаю чего я хочу, но…
Как версионировать требования (поведение, архитектуру), а не тексты сорцов?
(51) Постараюсь ответить, как понимаю это я. Очень упрощённо.
Разработчику требования версионировать не нужно, это задача, скорее, менеджера/аналитика (далее, просто аналитика). В свою очередь, аналитику не важен код.
Аналитик мыслит категориями системы, откуда и появляются требования. Т. е. есть описание системы (его тоже надо версионировать), из которого появляются требования, которые передаются разработчику в виде задач, по которым меняется код.
Описанный в статье механизм устанавливает соответствие «код — задача», но совсем не затрагивает соответствие «задача — требование» и, тем более, не даёт возможности «добраться» до изменений описания системы, в соответствии с которыми появилось требование.
Эту задачу можно решать «внешними» инструментами, например подключить (это возможно) какой-нибудь redmine или jira (к сожалению, на данный момент времени, в этих вопросах я не смогу Вам помочь более предметно), в которых и вести учёт продуктов/проектов/требований/задач. В этом случае мы сможем видеть всё, связанное с продуктом.
1С, кстати, предлагает своё решение этой задачи: СППР. В ней также есть реализация технологии разветвлённой разработки, но нет git-а. Нужно подождать какое-то время, появится и git, т. к. EDT волей-неволей потребует этого. Ну или «рядом» с СППР появится ещё какой-нибудь инструмент. Это не важно.
И! Внезапно, поведение версионировать можно.
Посмотрите на этот вопрос с точки зрения тестов, а, конкретно, инструмент . В нём (тестируемое) поведение системы описывается в простых текстовых файлах (фичах, features), которые вполне возможно хранить в репозитории продукта. Мало того, в этих фичах возможно описывать не только само поведение, но и кому и зачем оно нужно. Возможно это не совсем то, что нужно, но знать об этом полезно, а применять ещё более полезнее 🙂
(52) При разработке отдельной фичи считается хорошим тоном коммитить часто, но в хистори мастера лучше иметь фичу целиком в виде одного коммита. Автор пулл реквеста конечно может сквошить сам, но это неудобно, т.к. пулл реквест еще может дорабатываться после создания.
(52) Проблема не в том, что коммит нечитабелен, а в том что мы неспособны поделить код на такие куски, которые можно было воспринимать в совокупности.
(54) Если честно, я не понимаю сути проблемы.
Конфигуратор предоставляет возможность отображения объектов метаданных по подсистемам. Не пишите (я утрирую) один большой мега-модуль на всю конфигурацию, на разделите его на несколько, относящихся к определённым подсистемам.
Попробуйте описать кейс, который вызывает затруднения в понимании.
А вот можно спросить:
В этой ветке обсуждается gitsync, 1C-Gitter. 1С:ГитКонвертер.
Я правильно понимаю, что эти продукты служат для того чтобы выгружать хранилище конфигурации на например Github, и там на Githube применить для анализа кода всякие продвинутые инструменты?
А для групповой разработки без использования хранилища конфигурации эти инструменты не годятся, так?
(56)
В этой ветке обсуждается gitsync, 1C-Gitter. 1С:ГитКонвертер.
Я правильно понимаю, что эти продукты служат для того чтобы выгружать хранилище конфигурации на например Github, и там на Githube применить для анализа кода всякие продвинутые инструменты?
А для групповой разработки без использования хранилища конфигурации эти инструменты не годятся, так?
Почти всё так.
1. Эти инструменты просто «транслируют» изменения в хранилище в git-репозиторий.
2. Без хранилища эти инструменты не нужны.
При этом
3. Github (git-сервер) сам по себе ничего не умеет, только хранить git-репозитории для совместной работы. Можно не ограничиваться githubом, можно использовать другие git-серверы (gitlab, bitbucket), в том числе своим собственным, установленным у себя в сети (gitlab, gitea, etc).
4. «Продвинутые инструменты для анализа» просто берут репозиторий (код) из любого доступного места, того же githubа и работают уже с этим кодом локально.