diff --git a/docs/Git-LFS.md b/docs/Git-LFS.md new file mode 100644 index 0000000..580a8ec --- /dev/null +++ b/docs/Git-LFS.md @@ -0,0 +1,28 @@ +Для увеличения быстродействия репозитория Git можно использовать расширение __git lfs__ (https://git-lfs.github.com) + +Если используется сервер репозиториев Git, необходимо убедиться, что он поддерживает это расширение и включить настройки для проекта. Например, GitLab, GitHub, BitBucket - поддерживают. + +Выполнить начальную настройку репозитория до выполнения первого коммита: + +```bash +git lfs install +``` + +Включить отслеживание бинарных файлов конфигурации +```bash +git lfs track "*.cf" +git lfs track "*.bin" +git lfs track "*.png" +git lfs track "*.gif" +git lfs track "*.bmp" +git lfs track "*.jpg" +git lfs track "*.zip" +``` +В этом примере - все файлы конфигураций поставщиков, файлы макетов с "Двоичными данными" и картинки из конфигурации попадут в lfs. + +Например, чтобы переносить в LFS только некоторые типы файлов с расширением `*.bin` можно включить отслеживание только шаблонов и модулей без исходного кода по маске: + +```bash +git lfs track "*/Ext/Template.bin" +git lfs track "*/Ext/Module.bin" +``` \ No newline at end of file diff --git a/docs/Home.md b/docs/Home.md new file mode 100644 index 0000000..4e5bda2 --- /dev/null +++ b/docs/Home.md @@ -0,0 +1,29 @@ +# 1С:ГитКонвертер + +Конфигурация предназначена для односторонней синхронизации хранилища конфигурации "1С:Предприятия" с репозиторием Git и последующим переходом на разработку в [1C:Enterprise Development Tools (1C:EDT)](http://v8.1c.ru/overview/release_EDT_18/) с сохранением истории. + + +### Основные возможности + +* Конвертирование существующего хранилища конфигурации 1С в репозиторий Git в формате 1C:EDT +* Обновлять изменения из хранилища 1С в репозиторий Git +* Параллелизировать загрузку истории хранилища из копий хранилища +* Ограничение нагрузки на сервер с помощью очередей +* Возможно "сращивать" историю в Git, если хранилище конфигураций "1С:Предприятия" обрезалось или начиналось заново. +* Создание корректной истории переименования объектов метаданных (см. [Как это работает](Как-это-работает#Коммит-в-git)) +* Выгружать только изменения конфигурации. Доступно для Платформы 8.3.10 и выше, требуется использовать "очереди" +* Создание сквозной история изменений для "хранилищ исправительных версий" если вы используете [Технологию разветвленной разработки конфигураций](https://its.1c.ru/db/v8std/content/2149184358/hdoc) или аналогичный процесс - хранилище версии можно загружать в "ветку" Git, получив сквозную историю в ветке. +* Возможность автоматически указывать Git теги при изменении версии конфигурации. +* Поддержка конвертации разных хранилищ в разные ветки одного репозитория на различных версиях Платформы и различных версиях 1C:EDT. + +### Необходимые компоненты + +* Конфигурацию можно запустить, используя 1C:Enterprise Development Tools 1.10 (https://releases.1c.ru/project/DevelopmentTools10) +* Платформа 1С:Предприятия 8.3.12 и выше (https://releases.1c.ru/project/Platform83) +* СУБД, поддерживаемая 1С:Предприятием +* OS Windows 7 или выше, ОС Linux и macOS - в бета-режиме. + +## Полезные ссылки + +* Сайт 1C:EDT [https://edt.1c.ru](https://edt.1c.ru) +* Книга он-лайн [Групповая разработка в 1C:Enterprise Development Tools](https://edt.1c.ru/upload/docs_git/EDT&GIT.html) - см. Глава 6 - про 1С:ГитКонвертер, Постепенный переход на разработку в EDT \ No newline at end of file diff --git a/docs/_Sidebar.md b/docs/_Sidebar.md new file mode 100644 index 0000000..03ce1d1 --- /dev/null +++ b/docs/_Sidebar.md @@ -0,0 +1,32 @@ +[Начало](home) + +* [Как это работает?](Как-это-работает) +* [Начальная настройка](Начальная-настройка) + * [Настройка Windows](Настройка-Windows) + * [Настройка Linux](Настройка-Linux) + * [Настройка сервера 1С](Настройка-сервера-1С) + * [Настройка базы ГитКонвертера](Настройка-базы-ГитКонвертера) + +* [Настройка конвертации хранилища 1С](Настройка-конвертации-хранилища-1С) + * [Параметры конвертации](Параметры-конвертации) + * [Авторизация в сервере Git](Авторизация-в-сервере-Git) + * [Дополнительная настройка репозитория Git](Дополнительная-настройка-репозитория-Git) + * [Символы окончания строк](Символы-окончания-строк) + * [Git LFS](Git-LFS) + * [Информация пользователей](Информация-пользователей) +* Дополнительные возможности + * [Копии хранилища](Копии-хранилища) + * [Очереди выполнения](Очереди-выполнения) + * [Расширения](Расширения) + +* [Сценарии применения](Сценарии-применения) + * [Начать работу в EDT, не конвертируя все предыдущие версии хранилища](Начать-работу-в-EDT,-не-конвертируя-все-предыдущие-версии-хранилища) + * [Максимум скорости на историю](Максимум-скорости-на-историю) + * [Оперативное слежение за разработкой](Оперативное-слежение-за-разработкой) + * [Сращивание истории из нескольких хранилищ](Сращивание-истории-из-нескольких-хранилищ) + * [Сквозная история в ветках](Сквозная-история-в-ветках) + +* [Обновление с версии 1.0.4](Обновление-с-версии-1.0.4) + * [Конвертация выгрузки 1С:Предприятия в формат 1C:Enterprise Development Tools](Конвертация-выгрузки-1С-Предприятия-в-формат-1C-Enterprise-Development-Tools) + +* [Если что-то пошло не так (FAQ)](Если-что-то-пошло-не-так-FAQ) \ No newline at end of file diff --git a/docs/images/001-58.png b/docs/images/001-58.png new file mode 100644 index 0000000..598daab Binary files /dev/null and b/docs/images/001-58.png differ diff --git a/docs/images/001-59.png b/docs/images/001-59.png new file mode 100644 index 0000000..5cb06d5 Binary files /dev/null and b/docs/images/001-59.png differ diff --git a/docs/images/001-60.png b/docs/images/001-60.png new file mode 100644 index 0000000..b1b9418 Binary files /dev/null and b/docs/images/001-60.png differ diff --git a/docs/images/002-44.png b/docs/images/002-44.png new file mode 100644 index 0000000..20d9058 Binary files /dev/null and b/docs/images/002-44.png differ diff --git a/docs/Авторизация-в-сервере-Git.md b/docs/Авторизация-в-сервере-Git.md new file mode 100644 index 0000000..4534319 --- /dev/null +++ b/docs/Авторизация-в-сервере-Git.md @@ -0,0 +1,29 @@ +1С:ГитКонвертер позволяет конвертировать историю в локальный репозиторий или в локальный с отправкой изменений в удаленный репозиторий. + +В качестве сервера Git вы можете использовать одну из публичных систем управления репозиториями, которые есть в интернете. Например, **GitLab**, **GitHub**, **BitBucket** и др. Их достоинство заключается в том, что от вас не требуется предварительная установка и настройка программного обеспечения. Недостатком является то, что для размещения удалённого приватного (не публичного) репозитория вам, скорее всего, придётся использовать платный аккаунт. + +В то же время, например, **GitLab** имеет _бесплатную_ версию, которую вы можете скачать и установить на сервере своей организации. Так же GitLab.com предоставляет бесплатно возможность создавать приватные репозитории с некоторыми ограничениями. + +## Варианты авторизации + +### Простая авторизация (логин и пароль) + +Это авторизация в 1С:ГитКонвертере сделана по умолчанию для простоты адаптации разработчиков 1С. В форме настроек хранилища необходимо указать: +* адрес сервера Git +* логин и пароль для доступа на сервер. + +Если локальный репозиторий уже был создан без настроек удаленного репозитория - необходимо нажать на кнопку **Установить адрес репозитория Git** рядом с адресом сервера Git в форме настроек хранилища. + +Учтите, что логин и пароль - хранятся в базе данных 1С:ГитКонвертера, а так же в файле настроек `/.git/config` в репозитории. Поэтому безопасность этой информации обеспечивается доступом к самому серверу на котором расположен 1С:ГитКонвертер. + +### Авторизация по ssh + +Этот способ немного сложнее настраивать, но все серверы Git поддерживают такой способ авторизации по умолчанию. При этом, в 1С:ГитКонвертере нет ограничений использовать, настроенный самостоятельно, доступ по ssh. В форме настроек хранилища достаточно указать адрес сервера Git. + +**Внимание!** Настройку авторизации по протоколу SSH необходимо выполнять для пользователя ОС под которым запущен сервер 1С, т.к. соединение с Git-сервером будет выполняться под этим пользователем. + +### Авторизация Windows Credential Manager + +Аналогично способу `ssh` можно использовать авторизацию с помощью `Windows Credential Manager` настроив доступ вручную для пользователя под которым запущен сервер 1С:Предприятия. В форме настроек хранилища в 1С:ГитКонвертере аналогично - достаточно указать адрес и произвольные символы в поле логина и пароля. + +### [Подробнее о протоколах](https://git-scm.com/book/ru/v2/Git-на-сервере-Протоколы) \ No newline at end of file diff --git a/docs/Версия-Платформы-Хранилища.md b/docs/Версия-Платформы-Хранилища.md new file mode 100644 index 0000000..c1c086f --- /dev/null +++ b/docs/Версия-Платформы-Хранилища.md @@ -0,0 +1,14 @@ +Расширение позволяет конвертировать в формат EDT на одной версии 1С:Предприятия, а для подключения к хранилищу использовать другую версию Платформы. + +### Подробней +В процессе разработки существует необходимость менять версии Платформы (в т.ч. версию сервера Хранилищ 1С), при этом есть ограничение со стороны EDT - что версии поддерживаются не все, а только выпущенные на момент выпуска EDT. Обычно, необходимо версию Платформы для выгрузки в xml и версию сервера хранилищ 1С держать одинаковой. +В некоторых случаях, команда разработки хотела бы использовать сервер на версии Платформы который EDT не поддерживает, при этом конфигурация в хранилище находится в режиме совместимости с поддерживаемой EDT версией Платформы. + +Другой сценарий - когда команда разработки привязана к строго определенной сборки (в 4-й цифре) 1С:Предприятия и не имеет возможности для конвертации в формат EDT использовать более свежую версию, в которой, например, исправлены ошибки выгрузки. + +### Настройка + +1. Установите расширение в ИБ ГитКонвертера +2. В карточке настройки конвертации хранилища - появляется дополнительное поле "Версия хранилища" и прежнее поле "Версия выгрузки". +3. В "Копиях хранилища" так же можно указывать версию Платформы сервера хранилищ отличную от версии выгрузки. + diff --git a/docs/Дополнительная-настройка-репозитория-Git.md b/docs/Дополнительная-настройка-репозитория-Git.md new file mode 100644 index 0000000..367587d --- /dev/null +++ b/docs/Дополнительная-настройка-репозитория-Git.md @@ -0,0 +1,19 @@ +По умолчанию создается файл настроек `.gitattributes` в который добавлены настройки бинарных файлов: + +``` +*.bin binary +*.axdt binary +*.addin binary +``` + +По умолчанию создается файл исключений `.gitignore`, в который добавляются файлы `DumpFilesIndex.txt` и `ConfigDumpInfo.xml` - не требуемые для работы с исходными файлами конфигурации 1С. + +Если репозиторий был создан с помощью кнопки в карточке хранилища, в локальный конфиг репозитория добавляются настройки для более комфортной работы: + +```bash +git config --local core.quotepath false +git config --local gui.encoding utf-8 +git config --local i18n.commitEncoding utf-8 +git config --local diff.renameLimit 1 +git config --local diff.renames false +``` diff --git a/docs/Если-что-то-пошло-не-так-FAQ.md b/docs/Если-что-то-пошло-не-так-FAQ.md new file mode 100644 index 0000000..626dfe3 --- /dev/null +++ b/docs/Если-что-то-пошло-не-так-FAQ.md @@ -0,0 +1,54 @@ +## Расписание конвертации включено, но список версий пуст + +* Проверьте, что задана константа __"Путь к версиям платформы на сервере"__ и в настройках хранилища указана версия, соответствующая версии сервера хранилища конфигураций 1С:Предприятия. +* Проверьте файл логов `log.txt` в каталоге выгрузок - там может быть написано что-то вразумительное. +* Проверьте журнал регистрации базы 1С:ГитКонвертера - на наличие ошибок. Все мы - люди :) + +## Версии в списке версий хранилища в 1С:ГитКонвертере есть, но конкретная версия зависла (зациклилась) на этапе выгрузки конфигурации в xml + +* Можно посмотреть в лог пакетной операции для этой версии `/каталог выгрузки версий/ХХХ/log.txt` - пакетная операция Конфигуратора может сообщить что-то полезное +* Если база версии "развалилась" в контекстном меню формы списка версий __сбросить состояние__ версии - она будет получена заново из хранилища. + +## Версии обрабатываются, но не коммитятся в Git + +* Проверьте, разрешен ли анонимный коммит в Git +* Проверьте список версий хранилища - красным подсвечиваются версии, для авторов которых не указана контактная информация в регистре "Информация пользователей" +* Нажмите кнопку "Выполнить коммиты" - для принудительного запуска коммитов обработанных версий в статусе "Метаданные загружены" + +## Коммиты не появляются на сервере Git + +* Адрес Git-сервера был добавлен после создания хранилища? Нужно нажать кнопку "Установить адрес репозитория Git" чтобы настройки появились в config-файле. +* Откройте гит-клиент - проверьте, есть ли коммиты в локальном репозитории +* Посмотрите лог коммита на Git-сервер, расположенные `/каталог выгрузки версий/gi_log_ver_XXX.txt` +* Выполните команду `git push -u origin ` в консоли, чтобы проверить push вручную +* Проверьте права доступа для пользователя от которого запущен сервер 1С - от его имени выполняется запуск скриптов `*.bat/*.sh` и глобальные настройки Git для этого пользователя. + +## В какой-то версии произошел сбой и файлы версии закомичены не полностью + +Т.е. в этой версии часть файлов или все были сначала удалены в репозитории, а следующая версия добавила файлы заново - сквозная история потерялась :( + +* Можно установить контроль минимального количества файлов в выгрузке, чтобы такого не случалось в будущем. +* Т.к. это "односторонняя синхронизация" - то можно беспрепятственно откатить изменения `git reset --hard ` на версию, до проблемной. + * Далее в карточке хранилища установить поле "Версия в Git" на текущую в Git. + * Для всех версий, начиная с "проблемной" и последующих, выполнить команду в контекстном меню "Сбросить состояние" + * В каталоге `src` удалить файлы `DumpFilesIndex.txt` и `ConfigDumpInfo.xml` т.к. они не хранятся в репозитории и не откатились. + * Проверить что командные файлы `*.bat` (или `*.sh`) удалены для всех версий, начиная с проблемной. + * Если была установлена настройка Git-сервера, необходимо на сервере отключить защиту ветки (если есть такое) и выполнить `git push -u -f origin ` принудительную передачу данных с заменой репозитория на сервере. + +## В хранилище версия есть, а в Git она пропущена + +* Хранилище Конфигураций 1С:Предприятия позволяет сохранять новую версию без фактического изменения контента файлов, если меняется внутренняя версия объекта метаданных. Для Git в этом случае нечего коммитить. +* Откройте файлы логов и убедитесь в том, что версия была обработана корректно + +## Не появляются новые версии из хранилища 1С + +* Убедитесь что версии действительно есть в Хранилище и у вас не установлены фильтры при просмотре списка версий в ГитКонвертере +* Проверьте что написано в логе проекта - Конфигуратор может сообщать что-то полезное при получении отчета по хранилищу, который далее загружается в ИБ +* Убедитесь что сервер 1С:Предприятия работает по-умолчанию на русском языке +* Убедитесь, что "отчет по хранилищу" корректно загружается (см. "Журнал регистрации" на наличие ошибок. + +## Проверка доступности версий EDT не выполняется из формы настроек хранилища в ГитКонвертере + +* Убедитесь что на сервере установлена единственная версия 1C:EDT (множественность версий EDT не поддерживается) +* Выполните команду `ring edt platform-versions` убедитесь что версия 1С:Предприятия (она же версия хранилища 1С) указанная в форме настроек хранилища совпадает одной из списка, поддерживаемых EDT +* Проверьте, что пользователь, от имени которого запущен сервер 1С:Предприятия имеет право выполнять команду `ring ...` - после установки EDT требуется рестарт сервера чтобы другому пользователю была доступна новая консольная команда Ринга \ No newline at end of file diff --git a/docs/Информация-пользователей.md b/docs/Информация-пользователей.md new file mode 100644 index 0000000..24096cd --- /dev/null +++ b/docs/Информация-пользователей.md @@ -0,0 +1,5 @@ +Хранилище конфигураций "1С:Предприятия" использует для идентификации __Пользователя__, а в репозитории Git основным идентификатором является __email__ и имя пользователя. Для этих целей предназначен регистр сведений __Информация пользователей__, позволяющий указать соответствие пользователей хранилищ пользователям репозитория Git. + +Можно выполнять коммиты анонимно, с потерей информации об авторстве. Пользователь хранилища будет указан в дополнении к комментарию к каждой версии. + +Пользователи могут быть указаны общие для всех хранилищ или с уточнением по хранилищам. diff --git a/docs/Как-это-работает.md b/docs/Как-это-работает.md new file mode 100644 index 0000000..6c7caa8 --- /dev/null +++ b/docs/Как-это-работает.md @@ -0,0 +1,58 @@ +Конфигурация 1С:ГитКонвертер разработана для того, чтобы: + +* выполнить первоначальную конвертацию хранилища конфигурации в репозиторий Git, +* автоматически, по расписанию, обновлять ветку (например **master**) удалённого репозитория актуальным состоянием конфигурации из основного хранилища. + +Эта конфигурация может одновременно конвертировать и синхронизировать несколько хранилищ конфигурации и репозиториев. Для понимания принципов её работы рассмотрим пример с единственным хранилищем конфигурации, которое синхронизируется с удалённым репозиторием. + +[[images/001-58.png]] + +Компьютер, на котором установлена серверная информационная база с конфигурацией **1С:ГитКонвертер**, будем называть _сервер 1С:ГитКонвертера_. **1С:ГитКонвертер** получает данные из хранилища конфигурации, преобразует их в формат EDT, и фиксирует их в локальном репозитории, который находится на сервере 1С:ГитКонвертера. Затем он отправляет эти изменения в удалённый репозиторий Git, который находится на некотором компьютере, который назовём Git-сервер. Этот удалённый репозиторий и есть "хранилище проекта" для команды разработчиков (разработчик 1 и разработчик 2). + + +**1С:ГитКонвертер** одну за другой, по очереди, читает версии конфигурации из хранилища и преобразует их. Процесс преобразования одной версии состоит из следующих этапов: + +[[images/002-44.png]] + +1. Используя интерфейс командной строки 1С:Предприятия 8 в **каталоге выгрузки версий** создаётся информационная база, в которую из хранилища получается очередная версия. +1. Из информационной базы эта версия выгружается в XML файлы. +1. Используя интерфейс командной строки **EDT**, XML выгрузка конфигурации преобразуется в фалы внутреннего формата EDT. +1. Файлы внутреннего формата EDT помещаются в рабочий каталог проекта, который находится в **локальном каталоге Git**. +1. Командами Git'а выполняется фиксация изменений в локальном репозитории и отправка их в удалённый репозиторий. + +Из этой схемы важно понять, что когда вы будете настраивать конвертацию хранилища в 1С:ГитКонвертере вам нужно будет указать два каталога: +* Каталог выгрузки версий, +* Локальный каталог Git. + +Для оптимальной производительности важно, чтобы оба этих каталога находились на одном логическом диске. Тогда будет использоваться перемещение версий средствами операционной системы. В противном случае будет выполняться копирование данных, что может занять дополнительное время. + +Также из этой схемы вы можете понять, что на сервере 1С:ГитКонвертера вам понадобится установить следующее программное обеспечение (подробнее об этом рассказывается в разделе Установка программного обеспечения на сервер 1С:ГитКонвертера): + +* Сервер и клиент 1С:Предприятия 8 для работы конфигурации 1С:ГитКонвертер, +* Клиенты 1С:Предприятия 8 тех версий, на которых работают хранилища конфигураций, которые вы собираетесь конвертировать, +* СУБД, поддерживаемую 1С:Предприятием 8, для хранения информационной базы 1С:ГитКонвертера, +* EDT для преобразования XML файлов выгрузки конфигурации в формат EDT, +* Git для фиксации изменений в локальном репозитории и отправки их в удалённый репозиторий. + +Конфигурация **1С:ГитКонвертер** обладает возможностями, которые вы можете использовать опционально, по желанию. Это такие возможности как: + +* Использование Git LFS - для хранения больших бинарных файлов вне репозитория; использование этой возможности позволяет ускорить операции с репозиторием. +* Очереди выполнения - для балансировки нагрузки, создаваемой фоновыми заданиями, путём ограничения количества операций, выполняемых в каждой очереди. +* Копии хранилища - для параллельной загрузки версий одного хранилища конфигурации. + +Перед выполнением дальнейших шагов желательно сначала ознакомиться с этими возможностями, потому что, например, решение об использовании **Git LFS** необходимо принять до начала работы с 1С:ГитКонвертером, основываясь на размере вашего хранилища конфигурации, количестве версий в нём и наличии конфигураций поставщиков. Другие возможности вы сможете задействовать и потом, уже в процессе работы. + +### Коммит в Git + +Для того, чтобы создать правильную историю изменений объектов в Git репозитории аналогичную Хранилищу 1С необходимо учитывать особенности двух систем: + +* Хранилище конфигураций 1С:Предприятия сохраняет изменения по объектам, идентификатором которого является внутренний UUID, недоступный для редактирования в Конфигураторе. +* Репозиторий Git отслеживает изменения контента файлов при их перемещении. + +В случае, если объект в Конфигураторе был переименован - Хранилище 1С:Предприятия сохраняет новую версию того же объекта. Но если выгрузить конфигурацию в файлы - этот переименованный объект окажется в другом месте файловой иерархии, по сравнению с предыдущей версией. Если удалить объект, а потом создать с таким же именем - то история в Хранилище 1С будет новая для нового объекта. + +Так же, в выгрузке конфигурации 1С в xml присутствует множество файлов, очень похожих по контенту и именам (например ФормаСписка.xml), отличающихся только внутренним идентификатором (UUID). + +Поэтому, если в одной версии хранилища были удалены одни объекты (файлы), добавлены и/или переименованы другие - в Git нужно явно сообщить, что удалять, несмотря на похожие файлы в других каталогах, а так же то, какие файлы переименовываются. Таким образом, одна версия хранилища 1С может превращаться в 3 коммита: удаление файлов, переименование, и все остальные изменения контента в файлах и добавления файлов. + +Чтобы обеспечить корректное переименование истории объектов метаданных при переименовании/удалении их в хранилище конфигураций 1С:Предприятия создается файл индекса `DumpFilesIndex.txt` идентификаторов и файлов для каждой версии. На основе этого файла строится командный файл для выполнения коммита в Git `git_command_1.bat` \ No newline at end of file diff --git a/docs/Конвертация-выгрузки-1С-Предприятия-в-формат-1C-Enterprise-Development-Tools.md b/docs/Конвертация-выгрузки-1С-Предприятия-в-формат-1C-Enterprise-Development-Tools.md new file mode 100644 index 0000000..89c85ae --- /dev/null +++ b/docs/Конвертация-выгрузки-1С-Предприятия-в-формат-1C-Enterprise-Development-Tools.md @@ -0,0 +1,48 @@ +Выполнить конвертацию необходимо разово, чтобы "переключить" текущий формат с 1С:Предприятия на формат 1C:EDT. + +![Конвертация хранилища в формат 1C:EDT - Convert repository to 1C:EDT](../blob/master/ConvertToEDT.png?raw=true) + +__Внимание!__ +Конвертация в формат 1C:EDT необратима, поэтому последующая синхронизация с хранилищем 1С будет выполняться в формате 1C:EDT. Конечно, можно сделать "checkout" на коммит до конвертации и продолжить конвертацию в формате 1С:Предприятия в другой ветке, или откатить все изменения с помощью `git reset --hard ` и т.д. +Можно так же, в тестовых целях, создать копию элемента справочника "Хранилищ" и копию репозитория - создать ветку и конвертировать в формат 1C:EDT, оставляя возможность синхронизировать хранилище конфигураций с основной веткой Git в формате 1С:Предприятия. + +Структура каталогов выгрузки 1С:Предприятия и формата 1C:EDT похожи, но немного различаются. Для сохранения истории разработки в формате 1C:EDT запустите обработку __"Конвертация в формат EDT"__. Она выполняет перемещение файлов в соответствии с форматом 1C:EDT, выполняет коммит в гит, заменяет каталог `src` выгрузки 1С:Предприятия каталогом из 1C:EDT и выполняет второй коммит с изменением контента файлов. +Стоит отметить, что содержание xml-файлов 1C:EDT и 1С:Предприятия в некоторых случаях различается существенно, поэтому построчное авторство в таких файлах сохранить не удастся. +Файлы текстов модулей `*.bsl` сохраняют историю полностью. + +1. Установите 1C:EDT 1.8 и выше на сервер. +2. Если изначально каталог с именем проекта не был указан (ну забыли, не знали...) нужно заполнить **Имя проекта 1C:EDT** и будет выполнено перемещение `git mv ./src/... ./ИмяПроектаEDT/src/...` во время конвертации. Перемещение можно отключить, сняв галку **Выполнить перенос в каталог проекта**, если вы понимаете зачем это делаете. +3. Если использовали __Git LFS__ - убедитесь что типы файлов, вынесенные в __LFS__, после конвертации с новыми именами/расширениями так же попадут в __LFS__. +4. Выполните конвертацию репозитория с помощью обработки __Сервис -> Конвертация в формат EDT__, заполнив все обязательные поля. + +Если изначально был указан __"Каталог выгрузки в репозитории"__ соответствующий имени проекта, после конвертации можно открыть 1C:EDT в новом Workspace и выполнить импорт проекта из Git: __File -> Import -> Git -> Projects from Git__ и убедиться в корректности конвертации. + +__Внимание!__ Рекомендуется читать документацию к 1C:EDT о настройках Git, работе с проектом, импорте и др. + +Соответствие имен файлов формата выгрузки 1С:Предприятия и формата 1C:EDT + +``` +Configuration.xml -> Configuration.mdo +ClientApplicationInterface.xml -> ClientApplicationInterface.cai +CommandInterface.xml -> CommandInterface.cmi +HomePageWorkArea.xml -> HomePageWorkArea.hpwa +MainSectionCommandInterface.xml -> MainSectionCommandInterface.cmi +Form.xml -> Form.form +Template.xml -> Template.bin // BinaryData +Template.xml -> Template.mxlx // SpreadsheetDocument +Template.xml -> Template.dcs // DataCompositionSchema +Template.xml -> Template.txt // FileAwareTextDocument +Template.xml -> Template.htmldoc // HtmlDocument +Template.xml -> Template.addin // AddIn +Template.xml -> Template.scheme // GraphicalScheme +Template.xml -> Template.axdt // ActiveDocument +Template.xml -> Template.geos // GeographicalSchema +Template.xml -> Template.dcsat // DataCompositionAppearanceTemplate +Package.bin -> Package.xdto +WSDefinition.xml -> WsDefinitions.wsdl +Flowchart.xml -> Flowchart.scheme +Rights.xml -> Rights.rights +Schedule.xml -> Schedule.schedule +``` + +Другие файлы изменят имена не значительно, в соответствии с форматом 1C:EDT. Часть файлов (`Help.xml`, `Language.xml`, `Picture.xml`, `ФормаСписка.xml` и др.) будут удалены, т.к. контент файлов теперь хранится в составе других файлов. diff --git a/docs/Копии-хранилища.md b/docs/Копии-хранилища.md new file mode 100644 index 0000000..132ee0b --- /dev/null +++ b/docs/Копии-хранилища.md @@ -0,0 +1,19 @@ +Копии хранилища позволяют ускорить получение версий из хранилища за счет распараллеливания этого процесса. + +[[images/001-60.png]] + +Копии хранилища могут понадобиться вам, например, при конвертации больших конфигураций. В этом случае получение версии из хранилища может занимать значительное количество времени, в течение которого ресурсы, занятые выгрузкой и конвертацией в формат EDT, будут простаивать. + +## Настройка + +Список копий хранилища доступен из формы хранилища конфигурации по ссылке **Копии хранилищ конфигурации**. + +Вы можете использовать в копиях тот же адрес серверного хранилища конфигурации, но с разными пользователями. Количество "копий" влияет на размер создаваемого глобального кэша версий на сервере хранилища конфигурации. Поэтому размер кэша необходимо настроить. Для этого откройте в Конфигураторе информационную базу, подключённую к этому хранилищу, и укажите размер глобального кэша (**Конфигурация → Хранилище конфигурации → Администрирование хранилища... → Прочие → Глобальный кэш версий конфигурации**). + +Выберите максимальный размер кэша в 1,5 - 2 раза больше, чем: + +_<размер одной версии в Мб>_ * _<количество копий хранилища>_ + +Вы можете использовать в копиях адрес архивной копии хранилища, если в текущем хранилище конфигураций выполнялось сокращение версий. Тогда установите ограничение номеров версий в этой копии. Это позволит создать цельную историю изменений конфигурации в Git репозитории. + +Укажите **расписание получения версий** из этой копии. Если в копии указан адрес основного хранилища, вам необходимо в расписании учесть возможность работы разработчиков с хранилищем: запуски на получение выполнять с промежутками, обеспечивающими комфортную работу разработчиков. diff --git a/docs/Максимум-скорости-на-историю.md b/docs/Максимум-скорости-на-историю.md new file mode 100644 index 0000000..f2329db --- /dev/null +++ b/docs/Максимум-скорости-на-историю.md @@ -0,0 +1,80 @@ +## Цель + +Необходимо за максимально короткое время конвертировать историю огромную хранилища. +Предположим, что в оборудовании у нас нет ограничений или мы можем временно привлечь неограниченные ресурсы. + +## Настройка сервера хранилищ 1С + +Суть: создать множество копий хранилища чтобы параллелизировать получение версий. + +* Подключаем на том же сервере (или на отдельном сервере в той же сети) - отдельный SSD-диск +* Поднимаем 3 сервиса хранилищ конфигураций 1С на разных портах - настроенных на разные каталоги диска +* Настраиваем [кэширование сервера хранилищ](Настройка-конвертации-хранилища-1С) в зависимости от количества потоков получения из хранилища +* Копируем текущее состояние хранилища в 3 разных каталога - т.о. на одном SSD-диске 3 независимых копии хранилища. Следите за очередью к диску - может быть 3 шт. - это много, но крутые диски могут и больше! +* Сервер хранилищ - многопоточный - но у него есть ограничение по памяти. + +## Настройка репозитория + +Суть: необходимо избегать копирование данных с диска на диск - поэтому располагаем хранилище и каталог выгрузок на одном диске + +* Размещаем каталог репозитория и каталог выгрузки на одном SSD-диске. +* SSD-диск должен быть отдельным от того, на котором располагается сервер хранилищ 1С, если на одном сервере или сеть между серверами должна быть "прямая". +* В карточке настройки хранилища: + * В **Начальной версии** - указываем очень большое число, например `100000` - т.о. регламентное задание не будет пытаться выгрузить версии из хранилища и будет выполнять только сервисные действия (запуск коммитов, перезапуски итд). + * В **Версии окончания** укажите любое число - это ограничит рег.задание от получения отчета по хранилищу каждый раз - ведь нам нужно быстро догнать историю... +* Укажите расписание запуска "Каждый день, каждые 60 секунд" + + +## Настройка получения версий + +* Устанавливаем ограничения **"Количества подготавливаемых версий"** в настройках из расчета *Объем диска* / **Размер выгрузки** [см тут](Параметры-конвертации). +* Создаем пользователей в каждой копии хранилища 1С с именами "Выгрузка1", "Выгрузка2"... "Выгрузка-N" - из расчета того сколько сможет выдержать параллельных потоков. Для простоты посчитать можно так: `4Гб / Размер cf версии`, например версия конфигурации 500Мб - значит можно начать с 8 потоков на один сервис хранилища, а дальше - следить за памятью сервиса. +* Для каждого пользователя, для каждого сервиса хранилища 1С создаем настройку ["Копии хранилища"](Копии-хранилища) - в нашем примере 24 копии - для каждого настраиваем расписание запуска **"каждый день, каждые 60 секунд"** +* Укажите расписание запуска "Каждый день, каждые 60 секунд" + +## Настройка выгрузки в xml + +Суть: важно определиться - используем ли [выгрузку изменений](Параметры-конвертации) или нет. + +* Для **Выгрузки изменений** настраиваем для каждой очереди выгрузки рабочие диапазоны версий. + * Первая очередь - от 1 версии до 50 + * Вторая очередь - от 51 до 100 + * Третья очередь - от 101 до 150 + * Ограничением количества очередь - является размер диска, куда выгружаются версии +* Не используем **Выгрузку изменений** - создаем столько очередь выгрузки сколько копий хранилищ - 24 шт. +* Укажите расписание запуска очереди "Каждый день, каждые 60 секунд" + +## Настройка загрузки метаданных + +* Настраиваем количество очередей загрузки метаданных, в нашем примере - 10-20. +* Для каждой очереди загрузки будет запущена конвертация в формат EDT - нам необходимо чтобы было доступно 8 ядер процессора на одну очередь +* Укажите расписание запуска очереди "Каждый день, каждые 60 секунд" + +## Количество ядер CPU + +Суть: мы предположили, что у нас нет ограничений по оборудованию, поэтому посчитаем сколько нам необходимо. + +* 3-4 CPU на сервис хранилища +* 24/2 = 12 CPU на получение из копий хранилищ +* 1 CPU на очередь выгрузки +* 80 CPU - на 10 очередей загрузки + +ИТОГО: 110-130 CPU + +## RAM для сервера + +* 3-4 Гб на сервис хранилища 1С, реально будет работать в диапазоне 2-3Гб. +* 1Гб на очередь выгрузки +* 4Гб на очередь загрузки (с учетом того, что конфигурация cf - всего 500Мб), на 10 очередей + +ИТОГО: 80-90 Гб RAM + +# РЕЗЮМЕ + +Конечно, в любом проекте есть ограничения. +Определите, какие ограничения у вас: +* SSD (очередь к диску, размер) +* CPU +* RAM + +Рассчитайте максимальную загрузку сервера. \ No newline at end of file diff --git a/docs/Настройка-Linux.md b/docs/Настройка-Linux.md new file mode 100644 index 0000000..5dab53a --- /dev/null +++ b/docs/Настройка-Linux.md @@ -0,0 +1,8 @@ + +## Включение UTF-8 и языка по умолчанию + +TODO + +## Настройка выполнения в пакетных команд Конфигуратора в X-сервере + +TODO \ No newline at end of file diff --git a/docs/Настройка-Windows.md b/docs/Настройка-Windows.md new file mode 100644 index 0000000..3bf8336 --- /dev/null +++ b/docs/Настройка-Windows.md @@ -0,0 +1,25 @@ +## Длинные пути в Windows + +В некоторых версиях операционных системы Windows, по умолчанию, отключена работа с длинными путями. Длинный путь - это полный путь файла или папки, который превышает значение в 260 символов. + +Чтобы включить работу с длинными путями, необходимо: + +### Решения для тех у кого Windows 10 Pro и выше + +* Запустите консоль редактора локальной групповой политики, нажав Win+R и выполнив команду gpedit.msc +* Перейдите в раздел редактора Local Computer Policy -> Computer Configuration -> Administrative Templates -> System -> Filesystem -> NTFS (Конфигурация компьютера -> Административные шаблоны -> Система -> Файловая система -> NTFS) +* Откройте политику Enable NTFS long paths +* Включите политику, переведя ее в состояние Enabled +* Сохраните изменения + +### Решения для тех у кого Windows 10 Home и ниже + +* Запустите редактор реестра regedit.exe +* Перейдите в ветку HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Policies +* Создайте в данной ветке новый параметр типа Dword (32-bit) Value с именем LongPathsEnabled +* Измените значение ключа на 1 +* Сохраните изменения + +## Поддержка кириллицы в ОС + +TODO... \ No newline at end of file diff --git a/docs/Настройка-базы-ГитКонвертера.md b/docs/Настройка-базы-ГитКонвертера.md new file mode 100644 index 0000000..e3944e0 --- /dev/null +++ b/docs/Настройка-базы-ГитКонвертера.md @@ -0,0 +1,4 @@ +1. Разместите базу ГитКонвертера на сервере 1С. Работа в файловом режиме может быть использована только в демонстрационных целях. +2. Заполните константу __"Путь к версиям платформы на сервере"__, где располагаются файлы Конфигуратора 1cv8(.exe) в формате: `C:\Program files (x86)\1cv8\%ВерсияПлатформы%\bin` +где в параметр `%ВерсияПлатформы%` - будет подставлена текущая версия хранилища из настроек. +4. Для ограничения производительности можно включить константу __"Использовать очереди выполнения"__ - количеством очередей можно балансировать нагрузку на сервер. (см. [Очереди выполнения](Очереди-выполнения)) \ No newline at end of file diff --git a/docs/Настройка-конвертации-хранилища-1С.md b/docs/Настройка-конвертации-хранилища-1С.md new file mode 100644 index 0000000..106d2b1 --- /dev/null +++ b/docs/Настройка-конвертации-хранилища-1С.md @@ -0,0 +1,5 @@ +1. Рекомендуется использовать сервер хранилищ конфигураций 1С. + +Для оптимальной работы сервера хранилищ настройте __Размер глобального кэша__ в "Администрировании" в 1,5-2 раза больше __количества__ параллельных потоков (если используются "копии хранилища") __получения версий * размер одной версии, Мб__. + +2. Создайте настройку конвертации хранилища и [настройте параметры](Параметры-конвертации). \ No newline at end of file diff --git a/docs/Настройка-сервера-1С.md b/docs/Настройка-сервера-1С.md new file mode 100644 index 0000000..91d3655 --- /dev/null +++ b/docs/Настройка-сервера-1С.md @@ -0,0 +1,44 @@ +## Журнал регистрации + +Для ИБ ГитКонвертера на сервере 1С рекомендуется настроить удаление, перенос в архив или полностью отключить журнал регистрации, т.к. интесивность событий в ИБ может быть очень высокой, а ценность истории ЖР за прошлые периоды - низкая. + +Для легкого удаления и архивирования ЖР можно переключить его формат на старый режим. Для этого необходимо в каталог журнала регистрации ИБ скопировать пустой файл с именем: __1Cv8.lgf__. +Для больших проектов рекомендуется выполнить такую настройку (удаление/бэкапирование файлов журнала регистрации). + +Так же рекомендуется переключить регистрацию событий - только ошибки. Для этого следует выбрать команду __Конфигуратор - Администрирование - Настройка журнала регистрации... = Регистрировать ошибки__ и в открывшемся диалоге установить минимально необходимую вам периодичностью. + +Пример файла `remove_journal.bat` для ОС Windows позволяющий удалить журнал старше 3 дней + +```bat +@REM "Удаление журнала за 3 дня" +forfiles /p "C:\Program Files\1cv8\srvinfo\reg_1541\13b55eb8-943e-410a-a5fd-25e27a3337c2\1Cv8Log" /m *.lgp /D -3 /c "cmd /c del @file" +``` + +в этой строке необходимо заменить идентификатор ИБ `13b55eb8-943e-410a-a5fd-25e27a3337c2` на ваш идентификатор базы 1С:ГитКонвертера на сервере 1С. + +## Чистка кэша баз данных 1С + +В процессе выполнения пакетных операций 1С:Предприятие создает временные данные (кэши) которые необходимы для оптимальной работы. Т.к. 1С:ГитКонвертер создает множество баз, "отрабатывает" их и более в них не нуждается (удаляет сами базы), то кэши необходимо чистить на сервере 1С:ГитКонвертера. + +Пример скрипта `remove_old_caches.bat` для Windows: + +```bat +@REM "Удаление старых каталогов за 2 дня" +forfiles /p "c:\Users\USR1CV8\AppData\Roaming\1C\1cv8" /S /D -2 /C "cmd /c IF @isdir == TRUE rd /S /Q @path" +forfiles /p "c:\Users\USR1CV8\AppData\Local\1C\1cv8" /S /D -2 /C "cmd /c IF @isdir == TRUE rd /S /Q @path" +``` + +## Удаление файла списка версий `ibases.v8i` + +Для использования одного и того же кэша при разных запусках пакетных операций 1С:Предприятия Информационная База добавляется в список 1С. Со временем, если проект большой и количество версий в хранилище большое - список может очень вырости. Для сценария, когда 1С:ГитКонвертер приступает к конвертации версии сразу после ее внесения в Хранилище 1С т.е. "следит за разработкой", можно настроить чистку файла списка версий на сервере в период, когда все версии, добавленные за текущий день в Хранилище 1С, уже сконвертированы, например ночью, под утро: + +```bat +@REM "Удаление файла списка версий" +del /Q "c:\Users\USR1CV8\AppData\Roaming\1C\1CEStart\ibases.v8i" +``` + +Учтите, что **список версий** для каждого пользователя свой, т.о. можно удалять список только под тем пользователем, под которым запущен 1С сервер - в данном примере `USR1CV8`. + +## Перезагрузка сервера Windows + +В зависимости от интенсивности работы на сервере может потребоваться регулярная перезагрузка сервера Windows, например каждое утро перед началом рабочего дня разработчиков. \ No newline at end of file diff --git a/docs/Начальная-настройка.md b/docs/Начальная-настройка.md new file mode 100644 index 0000000..f27374a --- /dev/null +++ b/docs/Начальная-настройка.md @@ -0,0 +1,41 @@ +## Сервер + +Вам необходим "сервер", на котором будет выполняться вся конвертация и обработка версий. Сервером может быть: + +* Простой компьютер разработчика, например, включаемый ночью для задач "конвертации" +* Виртуальная машина в облаке +* Выделенный физический сервер + +Производительность и параметры сервера нужно выбирать: +1. Исходя из финансовых возможностей разработчика/компании +2. С учетом размера проекта: количества версии истории, размера одной версии, времени за которое хочется конвертировать историю + +## Программное обеспечение + +1. Установите на сервере 1C:EDT версии 1.8.1 и выше. Убедитесь, что корректно установлены компоненты консольного режима 1C:EDT. Для этого в терминале (командной строке) выполните команду: + + ``` + ring edt platform-versions + ``` + + убедитесь что текущая версия хранилища поддерживается в 1C:EDT. + +Добавьте параметры вывода утилиты RING, в окружение системы переменную `RING_OPTS` со значением `-Dfile.encoding=UTF-8` для корретного вывода сообщений в общий файл лога конвертации версии. + +Для вывода всех сообщений RING и EDT на русском, установите в `RING_OPTS` значение: + +``` +-Dfile.encoding=UTF-8 -Dosgi.nl=ru +``` + +2. Установите сервер 1С:Предприятия 8, версии 8.3.12 и выше. + +Все команды по конвертации каждой версии будут выполняться в операционной системе от пользователя, от которого запущена служба сервера 1С. Убедитесь, что этому пользователю доступна команда `ring ...` - возможно, потребуется перезагрузка сервера после установки 1C:EDT. + +3. Установите на сервер Git версии 2.16 и выше. Например, отсюда: https://git-scm.com/downloads + +4. Установите на сервер Git LFS, если планируете использовать в вашем проекте. [См. раздел Git LFS](Git-LFS) + +5. Разместите на сервере 1С:Предприятия базу 1С:ГитКонверетера и [выполните начальную настройку базы](Настройка-базы-ГитКонвертера). + +6. Установите клиенты 1С:Предприятия (Конфигуратор) тех версий, на которых запущено хранилище конфигураций 1С. Конфигуратор будет выполнять большую часть работ по конвертации. \ No newline at end of file diff --git a/docs/Начать-работу-в-EDT,-не-конвертируя-все-предыдущие-версии-хранилища.md b/docs/Начать-работу-в-EDT,-не-конвертируя-все-предыдущие-версии-хранилища.md new file mode 100644 index 0000000..5c4e82f --- /dev/null +++ b/docs/Начать-работу-в-EDT,-не-конвертируя-все-предыдущие-версии-хранилища.md @@ -0,0 +1,29 @@ +## Цель + +Нет желания, нет мощного оборудования или времени, чтобы конвертировать всю историю хранилища сначала. Необходимо начать разработку в EDT с текущего среза хранилища 1С (с определенной версии хранилища). + +## Настройка синхронизации, начиная с версии N + +1. Создаем настройку синхронизации в ГитКонверетре, [заполнив необходимые параметры](Параметры-конвертации) + +2. В поле **Начальная версия** укажите предыдущую версию хранилища, от той, которой необходимо начать `N-1`. + +3. В Конфигураторе выгрузите в файл "Отчет по версиям" хранилища и загрузите этот отчет в базу ГитКонвертера для текущей настройки синхронизации. + +4. Инициализируйте новый пустой репозиторий Git командой на форме настройки синхронизации хранилища. + + 4.1. Выполните [дополнительную настройку Git](Git-LFS) по необходимости. + +5. В поле **Версия в Git** в настройке - укажите предыдущую версию, как в поле **Начальная версия** `N-1`. + +6. Перейдите в список **Версий хранилища** в панеле навигации формы - и все версии с начала и до указанной в поле **Версия в Git**, выделив в списке, пометьте как "Помещенные в хранилище" с помощью команды в контекстном меню списка. + +7. Запустите конвертацию, включив расписание синхронизации в форме настройки хранилища. + +## РЕЗЮМЕ + +Первой версией в Git репозитории будет следующая версия, после указанной настройках - версия `N`. + +Далее, синхронизация хранилища 1С и Git репозитория будет выполнятся в режиме "слежения" и не будет требовать много ресурсов, чтобы конвертировать всю историю. + +В такой схеме история изменений будет не полной, выполнять `git blame` (авторство строк кода) можно будет только для новых версий в хранилище. \ No newline at end of file diff --git a/docs/Обновление-с-версии-1.0.4.md b/docs/Обновление-с-версии-1.0.4.md new file mode 100644 index 0000000..12ff233 --- /dev/null +++ b/docs/Обновление-с-версии-1.0.4.md @@ -0,0 +1,2 @@ +**Внимание!** Конвертация хранилища 1С в формат выгрузки xml 1С:Предприятия является устаревшей функциональностью и не доступна для новых настроек конвертации хранилища. +Текущие настройки синхронизации хранилища, конвертирующие в формат выгрузки xml 1С:Предприятия будут работать корректно, но рекомендуется выполнить разовую конвертацию в формат 1C:EDT и продолжить синхронизацию в этом формате. diff --git a/docs/Оперативное-слежение-за-разработкой.md b/docs/Оперативное-слежение-за-разработкой.md new file mode 100644 index 0000000..6cc6d21 --- /dev/null +++ b/docs/Оперативное-слежение-за-разработкой.md @@ -0,0 +1,18 @@ +## Цель +Необходимо как можно быстрее любое изменение в Хранилище 1С получать в Git-репозитории. Предположим, что у нас достаточно мощностей серверов чтобы обслужить работу разработчиков. + +## Настройки + +1. В настройках конвертации хранилища необходимо включить расписание конвертации очень интенсивное, например `Каждый рабочий день, с 9:00 по 19:00, повторять через 60 сек после завершения` - т.е. каждые 60 сек запрашивать новые версии. Но оцените нагрузку на сервер Хранилищ 1С - может быть для комфортной работы разработчиков лучше поставить `каждые 5 минут`. +2. Установите `Первую версию` очень большую, например **100000**, и `Последнюю версию` установите равным 0 - такая настройка говорит регламентному заданию не выполнять получение версий (`*.cf`) из хранилища - т.к. это может быть затратно по времени, но запрашивать отчет о новых версиях - обычно, это быстрая операция. +3. Создайте дополнительно настройку "Копии хранилища" в панели перехода: + * В поле `адреса хранилища` укажите такой же адрес, как основной настройке + * Создайте в Хранилище 1С второго пользователя с правами "только просмотр" (без возможности захвата объектов) и укажите этого пользователя в настройке "Копии хранилища". Пользователь должен отличаться от указанного в карточке настройки хранилища, т.к. авторизация одного пользователя в хранилище конкурентная. + * Установите расписание получения версий из Хранилища 1С `Каждый день, каждые 60 сек` при этом, подключение к хранилищу будет выполняться, только если новые версии были получены первым рег.заданием в п.1 + * Создайте дополнительные настройки "Копий хранилищ" для получения нескольких версий параллельно. Оцените, выдержит ли ваш сервер Хранилищ 1С такую нагрузку при интенсивной работе разработчиков. + +Дополнительно, оцените, необходимо ли использовать **Очереди выполнения** для стабилизации нагрузки на сервере ГитКонвертера. + +## РЕЗЮМЕ + +Одно рег.задание следит только за появлением новых версий в хранилище и выполняет запуск фоновых заданий на обработку полученных версий, коммит и т.д. Другое(ие) регламентное задание в "Копии хранилища" выполняет "тяжелую работу" по получению версии (`*.cf`) из хранилища. Версии появляются в списке ГитКонвертера и конвертируются максимально быстро. \ No newline at end of file diff --git a/docs/Оптимизация-выгрузки-на-8.3.15.md b/docs/Оптимизация-выгрузки-на-8.3.15.md new file mode 100644 index 0000000..315f84e --- /dev/null +++ b/docs/Оптимизация-выгрузки-на-8.3.15.md @@ -0,0 +1,8 @@ +Расширение позволяет для конвертации хранилищ 1С:Предприятия на версии **ниже 8.3.15** использовать оптимизированный алгоритм частичной выгрузки. При это не требуется настраивать [очереди выполнения](Очереди-выполнения) для частичной выгрузки. + +### Настройка + +1. Установите расширение в ИБ ГитКонвертера версии 1.0.6.2 или выше. +2. Установите на сервер любую платформу 1С:Предприятия версии 8.3.15.х или выше. +3. Укажете установленную версию в настройках в меню **Сервис -> Версия платформы 8.3.15 для оптимизации выгрузки** в формате `8.3.15.1489`. +4. В карточке настройки конвертации хранилища установите флаг **Выгружать изменения** \ No newline at end of file diff --git a/docs/Очереди-выполнения.md b/docs/Очереди-выполнения.md new file mode 100644 index 0000000..083306f --- /dev/null +++ b/docs/Очереди-выполнения.md @@ -0,0 +1,23 @@ +Очереди позволяют ограничить количество операций, выполняемых фоновыми заданиями. Различается два вида операций: операции выгрузки конфигурации и операции загрузки метаданных. + +[[images/001-59.png]] + +Вы можете создавать очереди для каждого хранилища конфигурации, или общие, на всю базу 1С:ГитКонвертера. +Необходимость использования очередей может возникнуть по двум причинам. +* Во-первых, это чрезмерная нагрузка на ресурсы сервера 1С:ГитКонвертера. Например, через какое-то время вы замечаете, что операции с диском или с оперативной памятью стали узким местом. Тогда с помощью очередей и запуска по расписанию вы можете ограничить количество операций, выполняемых фоновыми заданиями за один раз. +* Во-вторых, очереди понадобятся вам в том случае, если вы конвертируете большую конфигурацию, и для ускорения процесса хотите использовать не полную выгрузку конфигурации, а выгрузку только изменений - инкрементальную выгрузку конфигурации (такая возможность есть в платформе 1С:Предприятие 8 начиная с версии 8.3.10). + +## Настройка +Чтобы очереди выполнения стали доступны, установите флажок **Сервис → Использовать очереди выполнения → Использовать очереди выполнения**. + +Список очередей выполнения доступен из формы любого хранилища конфигурации по ссылке Очереди выполнения. + +Если очередь общая, то выбор версий для обработки выполняется по дате версии. Это следует учитывать при конвертации проектов с длинной историей и более "молодых" проектов в одной базе 1С:ГитКонвертера. + +Если очередь для хранилища, то для каждого хранилища конфигурации вам необходимо создать как минимум две очереди: +* Выгрузка конфигурации. Начиная с версии платформы 1С:Предприятие 8.3.10 вы можете использовать выгрузку изменений. Для этого необходимо выгружать версии строго последовательно, и поэтому не рекомендуется создавать более одной очереди на выгрузку. +* Загрузка метаданных. + +Для каждой очереди вам следует указать **количество операций** (версий конфигурации), которые будут обрабатываться за один запуск. + +Кроме этого вы можете указать диапазон версий, для разграничения "рабочей зоны" между разными очередями, а также расписание запуска. diff --git a/docs/Параметры-конвертации.md b/docs/Параметры-конвертации.md new file mode 100644 index 0000000..c5464d7 --- /dev/null +++ b/docs/Параметры-конвертации.md @@ -0,0 +1,34 @@ +## Основное + +* Укажите адрес хранилища. При использовании сервера хранилища рекомендуется настроить в администрировании хранилища параметр "Глобальный кэш версий конфигурации" чтобы количество кэшированных версий было больше параллельно получаемых версий. +* Укажите версию платформы, рекомендуется использовать **8.3.12.1412** и выше. Она должна совпадать с версией сервера Хранилища конфигураций 1С и должна быть поддерживаема 1C:EDT (для проверки нажмите кнопку) +* Укажите расписание запусков. +* Укажите __Каталог выгрузки версий__, в котором будут создаваться временные каталоги с номерами версий и выгрузкой данных. +* __Локальный каталог Git__ рекомендуется указывать на одном логическом диске с __Каталогом выгрузки версий__ - будет использовано перемещение версий возможностями ОС, иначе будет выполняться копирование. +* __Каталог выгрузки в репозитории__ - относительный путь к каталогу выгрузки внутри репозитория. Необходимо указывать **имя проекта 1C:EDT**. +* Установите флаг __Выполнять коммиты__ для выполнения коммитов. Отключение может быть необходимо с целью временно приостановить работу конвертера. + + +Нажмите кнопку "Создать гит репозиторий" перед конвертацией - команда выполняет инициализацию репозитория и начальную настройку, специфичную для конфигураций 1С. + +## Использование Git сервера + +Если репозиторий планируется размещать на сервере Git - выполните [настройки авторизации в Git](Авторизация-в-сервере-Git) + + +## Дополнительно + +* Укажите начальную версию в хранилище конфигураций, если текущее хранилище было обрезано и первая версия больше 1. +* Если указана версия окончания - не будет выполняться запрос новых версий. Это может быть полезно, если требуется конвертировать сначала всю историю разработки. +* Желательно ограничить количество подготавливаемых (выгружаемых) версий - рекомендуется установить значение исходя из __Размер базы с версией + Размер выгрузки в xml__ и размера жесткого диска. +* Укажите __Минимальное количество метаданных__ - число файлов и каталогов выгрузки в xml - необходимо для контроля, что все файлы выгружены. Рекомендуется устанавливать количество, примерно 90-95% от количества файлов в текущей версии, чтобы учесть возможность удаления метаданных (т.е. сокращения количества файлов) +* Разрешить помещать анонимно, если пользователь не найден в регистре [Информация пользователей](Информация-пользователей) - это может понадобиться, если автор хранилища версий единственный или авторство неуказанных пользователей не нужно. +* Не рекомендуется устанавливать __Удаление конфигураций поставщиков__, если планируется загружать конфигурацию из файлов и обновлять конфигурации поставщиков. Опция позволяет оптимизировать размер хранилища Git и не хранить объемные файлы *.cf. +* Установите __Удалять временные данные версии после коммита__ - рекомендуется на реальных проектах. +* __Выгружать изменения__ - позволяет на Платформе 8.3.10 и выше выгружать только изменения. Доступно при использовании __"Очередей"__ +* Установите флаг __Обрабатывать все очереди__, если используются очереди в ИБ. + +## Наименование и описание + +* Можно указать дополнительную информацию в описании +* Можно задать наименование настройки отличное от адреса хранилища в сворачиваемой группе "Описание" \ No newline at end of file diff --git a/docs/Расширения.md b/docs/Расширения.md new file mode 100644 index 0000000..8d6361e --- /dev/null +++ b/docs/Расширения.md @@ -0,0 +1,3 @@ +Расширения для кастомизации работы 1С:ГитКонвертера + +* [Версия Платформы Хранилища](Версия-Платформы-Хранилища) позволяет подклчаться к Хранилищу на версии, отличной от версии выгрузки. \ No newline at end of file diff --git a/docs/Символы-окончания-строк.md b/docs/Символы-окончания-строк.md new file mode 100644 index 0000000..0d23189 --- /dev/null +++ b/docs/Символы-окончания-строк.md @@ -0,0 +1,26 @@ +Если разработчики, работающие с репозиторием, используют разные операционные системы (Microsoft Windows, Linux, macOS), нужно настроить конвертацию символов окончания строк при чтении из репозитория. Следующие команды настраивают Git таким образом, что в рабочей копии разработчика будут использоваться "родные" для его операционной системы символы, а в репозитории всегда будет использоваться LF. + +Для операционной системы Microsoft Windows: + +```bash +git config --global core.autocrlf true +git config --global core.safecrlf true +``` + +Для операционных систем Linux и macOS: + +```bash +git config --global core.autocrlf input +git config --global core.safecrlf true +``` + +Подробнее о назначении этих параметров вы можете прочитать в документации Git на английском языке [git config core.safecrlf](http://git-scm.com/docs/git-config#git-config-coresafecrlf) и [git config core.autocrlf](http://git-scm.com/docs/git-config#git-config-coreautocrlf). + +**1С:ГитКонвертер** по умолчанию добавляет настройки окончания строк при инициализации репозитория кнопкой из формы настройки хранилища в локальные настройки репозитория: + +```bash +git config --local core.autocrlf true +git config --local core.safecrlf warn +``` + +Т.о. в репозиторий файлы попадут с окончаниями строк попадут как `LF`, выдавая предупреждения в лог, если в файле есть смешение `CRLF` и `LF`. diff --git a/docs/Сквозная-история-в-ветках.md b/docs/Сквозная-история-в-ветках.md new file mode 100644 index 0000000..e0692cf --- /dev/null +++ b/docs/Сквозная-история-в-ветках.md @@ -0,0 +1,20 @@ +При использовании [Технологии разветвленной разработки конфигураций](https://its.1c.ru/db/v8std/content/2149184358/hdoc) или аналогичного процесса для ветвления создается отдельное хранилище на каждую ветку на основе определенного номера закладки в основном хранилище. История в таком хранилище начинается с 1 версии и не содержит истории основного Хранилища. + +## Цель +Создание сквозной истории изменений для "хранилищ исправительных версий" в ветке Git репозитория. "Авторство кода" (`git blame`) будет сквозным для веток. + +## Настройки + +1. Создаем [настройку конвертации](https://github.com/1C-Company/GitConverter/wiki/Настройка-конвертации-хранилища-1С) для "исправительного" хранилища. + * Укажите `локальный каталог Git` репозитория отличающийся от основного хранилища + * Укажите `адрес репозитория на сервере Git` такой же как в настройке основного хранилища + * Укажите `имя ветки` например `release-1.2.1` имя ветки должно отличаться от имени, указанном в настройке конвертации основного хранилища. +2. Скопируйте локальный каталог репозитория Git для основного хранилища в каталог, указанный в текущей настройке. Убедитесь предварительно что в текущий момент не выполняются коммиты в основном, что локальный репозиторий не находится в состоянии модификации. +3. Найдите номер версии в основном хранилище на основе которого создано "исправительное" и скопируйте `хеш` коммита. + * выполните команду создания ветки на основе хеша в каталоге с локальным репозиторием исправительного хранилища: + * `git checkout -b "release-1.2.1" c0c007b9dbe142a70e3bba57a6770a5e5ab3defb` - такая команда выполняет переключение состояния файлов на указанный хеш коммита и создает ветку с именем `release-1.2.1` + * Удалите файлы `/MyProject/src/ConfigDumpInfo.xml` и `/MyProject/src/DumpFilesIndex.txt` в скопированном репозитории - эти файлы не хранятся в репозитории и используются для расчета частичной выгрузки и переименований файлов. + +## РЕЗЮМЕ + +Если вы нашли правильную версию в основном хранилище, то первая версия в "исправительном" будет ей равна и не содержит фактических изменений в файлах. Конвертация первой версии не приведет к добавлению нового коммита. Далее конвертация из "исправительного" хранилища продолжается как обычно, но в другую ветку. "Авторство кода" Git рассчитывает с учетом всех изменений, сделанных в основном хранилище. \ No newline at end of file diff --git a/docs/Сращивание-истории-из-нескольких-хранилищ.md b/docs/Сращивание-истории-из-нескольких-хранилищ.md new file mode 100644 index 0000000..fc88b31 --- /dev/null +++ b/docs/Сращивание-истории-из-нескольких-хранилищ.md @@ -0,0 +1,22 @@ +В течении длительного времени разработки Хранилище 1С "распухло" и было принято решение - создать новое хранилище на основе последней закладки в первом. В этом случае нет возможности просто добавить [копию хранилища](https://github.com/1C-Company/GitConverter/wiki/Копии-хранилища) с указанием диапазонов версий т.к. в каждом хранилище есть две разные версии с одинаковым номером: 1, 2, 3... + +## Цель +Необходимо в Git репозитории получить сквозную историю проекта из двух (или более) Хранилищ 1С, созданных с 1 первой версии (закладки в хранилище). + +## Настройки + +1. У нас уже существует настройка конвертации для первого (самого исходного) Хранилища 1С. +2. Добавляем настройку конвертации второго (и далее) Хранилища 1С + * В поле `адрес хранилища` укажите адрес второго хранилища на сервере хранилищ + * Укажите `каталог выгрузки версий` отличающийся от исходного + * Укажите `каталог репозитория` тот же самый, который указан в первой настройке хранилища + * Укажите `имя ветки` совпадающее с именем в первой настройке + * Временно снимите флажок `Выполнять коммиты` - до тех пор, пока не закончится конвертация из первого хранилища. + * Все остальные настройки могут быть настроены по аналогии или скопированы из первого. +3. Если второе хранилище было создано на основе версии, например, `№49538` из первого хранилища, но пока создавали разработчики добавили новые закладки `49539` `49540` `49541`... в исходное (первое) хранилище, то необходимо в первой настройке конвертации указать версию ограничения по которую необходимо выполнять коммиты = `49538` + +## РЕЗЮМЕ + +Коммиты в репозиторий необходимо выполнять последовательно. Поэтому сначала выполняем и завершаем конвертацию первого хранилища, потом продолжаем в этот же локальный репозиторий конвертировать из второго Хранилища 1С, установив флаг `Выполнять коммиты` во второй настройке и, сняв этот флаг в первой. **Важно**, чтобы имя ветки совпадало с указанным в первой настройке и адрес репозитория на Git сервере, если указан. + +Ближе к окончанию конвертации первого хранилища, можно запустить конвертацию и подготовку версий из второго хранилища, но сняв галочку `Выполнять коммиты` - это позволит пре-подготовить версии к моменту "переключения" хранилищ и быстро закоммитить. Количество подготавливаемых версий зависит от размера одной версии `*.cf`, базы, выгрузки и т.д. и объема вашего HDD/SSD диска. \ No newline at end of file diff --git a/docs/Сценарии-применения.md b/docs/Сценарии-применения.md new file mode 100644 index 0000000..91d9bb5 --- /dev/null +++ b/docs/Сценарии-применения.md @@ -0,0 +1,5 @@ +* [Начать работу в EDT, не конвертируя все предыдущие версии хранилища](Начать-работу-в-EDT,-не-конвертируя-все-предыдущие-версии-хранилища) +* [Максимум скорости на историю](Максимум-скорости-на-историю) +* [Оперативное слежение за разработкой](Оперативное-слежение-за-разработкой) +* [Сращивание истории из нескольких хранилищ](Сращивание-истории-из-нескольких-хранилищ) +* [Сквозная история в ветках](Сквозная-история-в-ветках) \ No newline at end of file