Процесс разработки с использованием GIT и расширений для 1С:ERP. Без EDT

02.04.24

Разработка - Групповая разработка (Git, хранилище)

Доработки 1С:ERP на крупных проектах можно организовать, не внося изменения в саму типовую конфигурацию, а используя только расширения и отдельные «микроконфигурации». Расскажем о том, как это сделать без EDT, используя процесс разработки GitHub Flow.

Меня зовут Валерий Дыков, я расскажу о том, как можно разрабатывать для 1С:ERP с использованием Git и расширений, практически не используя EDT. Это продолжение доклада с конференции Infostart Event 2021 Post-Apocalypse – расскажу, что изменилось за 2021-2022 год.

Я уже давно занимаюсь 1С – наверное, лет 20. У меня был собственный франчайзи, я работал в фирме «1С» и уже более 10 лет – в компании «Первый БИТ», офис Савеловский (он же БИТ.ERP).

Несколько слов про наш офис, чтобы было понятно, как мы работаем с Git, и почему именно так.

  • Офис у нас чисто проектный – мы делаем свои коробочные продукты, занимаемся проектами по ERP и еще немного промышленной автоматизацией.

  • Мы все удаленщики – уже 10 лет вся наша команда работает на удаленке.

  • Мы любим экспериментировать с разными интересными технологиями. И клиентов к себе на проекты выбираем тоже тех, которые любят разные интересные современные технологии. Исходя из этого, мы выбираем и методы разработки.

  • Если вам интересно, как у нас построено автоматическое тестирование, можете посмотреть видеозапись с митапа Инфостарта – там я рассказывал про тестирование.

А сейчас я продолжу тему доклада 2021 года про разработку.

 

В подразделении БИТ.ERP есть несколько проектных команд и у каждой из них своя небольшая специфика.

  • У каждой проектной команды свой репозиторий, где лежит свой код и свои тесты.

  • У каждой команды свой набор эталонных баз, на которых команда разрабатывает и тестирует.

  • Есть незначительные отличия в процессе разработки.

При этом у всех команд есть общие подходы и общие инструменты для работы:

  • Все разработчики во всех наших командах работают на своих виртуальных машинах в нашем облаке. Сейчас это в основном Linux, раньше был Windows.

  • Весь исходный код мы храним в Git, используем GitHub. Хранилище сейчас не используем.

  • Для работы с Git мы используем два подхода – это заявки в Service Desk и прямая работа с Git.

  • Разработка по задачам ведется в отдельных ветках – в ветку master принимаются только протестированные изменения.

  • Для тестирования используем Vanessa Automation.

  • Каждый разработчик в любой момент времени может через заявку запустить автотесты – они выполняются в фоне и никак не отвлекают разработчика. Результаты автотестов обязательно прикладываются ко всем пул-реквестам.

  • В результате мы в любой момент времени имеем в ветке master только протестированный релиз и можем отдавать заказчику релизы из ветки master максимально часто, в идеале каждый день – в этом как раз и заключается цель всех этих наших доработок и автоматизации.

 

В докладе мы пошагово рассмотрим типичный рабочий день нашего разработчика:

  1. День начинается с подключения к рабочему месту.

  2. Потом разработчик выбирает задачу из трекера – раньше он это делал в Jira, сейчас в Яндекс.Трекере. И создает окружение для разработки на своей виртуальной машине.

  3. Дальше вносит доработки – далее я расскажу про наши принципы внесения доработок.

  4. Помещает изменения в Git.

  5. Запускает тесты и убеждается, что все тесты зеленые.

  6. Делает pull-request по задаче в ветку master.

В результате путь разработки от задачи до релиза составляет один день – сразу после попадания этого изменения в ветку master клиент может забрать его к себе на продуктив.

 

Шаг 1. Подключение к рабочему месту

 

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

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

  • В качестве рабочих мест используются виртуальные машины на Linux. Мы создаем эти рабочие места программно – берем типовой образ Ubuntu и через Ansible ставим нужное программное обеспечение.

  • Состав установленных программ у всех сотрудников одинаковый – лучше мы поставим лишнее, чем не поставим что-то нужное, и потом придется это доставлять.

  • Создать или пересоздать рабочее место сотрудника можно в любой момент через заявку в Service Desk – нажали, и машинка создалась.

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

  • Для внутренней автоматизации мы используем Jenkins – разворачиваем на каждой машине разработчика Jenkins-ноду, чтобы иметь возможность выполнять там свой код.

  • Все машины подключены к общему мониторингу/алертингу.

  • И все машины имеют доступ к общим ресурсам – таким, как клиент-серверные базы данных, необходимые для работы.

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

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

 

Как мы обеспечиваем полностью программное развертывание?

  • Как правило, любой облачный провайдер предоставляет некий WEB API для работы с виртуальными машинами – через это WEB API мы можем программно создавать, удалять, добавлять новые машины.

  • Часто поверх этого WEB API можно использовать разные инструменты вроде Terraform – раньше мы пользовались Terraform.

Дальше мы устанавливаем необходимое ПО.

  • Как я сказал, мы используем Ansible. На Linux это вообще просто, но на Windows с помощью Ansible тоже можно необходимое ПО устанавливать.

  • Все пакеты мы ставим из локального репозитория – мы имеем локальное зеркало для всех программ, которые устанавливаем. Это полезно, потому что при установке из интернета могут возникать различные ошибки, когда что-то недоступно.

  • Ставим на виртуальные машины все нужные нам программы – диски стоят дешево, поэтому это несложно сделать.

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

На наших виртуальных машинках мы делаем для сотрудников в терминах Linux – два дисплея, в терминах Windows – два сеанса. Один – для человека, другой – для робота. Человек работает на одном дисплее, а Jenkins-нода – на другом дисплее или в другом сеансе.

  • В результате, когда Jenkins-нода запускает сеанс 1С или что-нибудь выгружает из конфигуратора, человек при своей работе этого не видит – для него это прозрачно.

  • При этом есть возможность через VNC подключиться к другому сеансу и посмотреть, что там делает Jenkins-нода.

 

По подключению к рабочему месту разработчика.

Раньше мы, как и многие, для подключения к своей корпоративной сети использовали VPN. А потом прочитали статью на Хабре и перешли к другой схеме – используем SSH с авторизацией по сертификатам.

Как это в целом работает?

  • Запускается SSH, он идет к нашему облачному провайдеру пользователей – мы, например, используем Okta.

  • Через OpenID Connect пользователь авторизуется, мы получаем ключик и дальше выписываем пользователю временный сертификат, по которому человек авторизуется через SSH. В статье подробно расписано, как это можно сделать.

  • Поскольку мы не публикуем напрямую в интернет IP-шники каждой машины, а пользуемся SSH-шлюзом, каждый пользователь подключается именно к своей машине, а не к общей сети.

  • И дальше внутри сети мы можем гибко управлять правами – к каким ресурсам внутри сети наши корпоративные пользователи имеют доступ.

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

  • Так как при подключении к SSH мы уже авторизовались, а на каждой виртуальной машине – один пользователь, дополнительной авторизации там не требуется.

  • Фактически мы сделали для пользователей один командный файл, который можно запустить, ввести логин-пароль и дальше через RDP-клиент работать на своей виртуальной машине.

 

На слайде я привел список ПО, которое мы ставим на машину – возможно, вам это будет полезно.

 

Шаг 2. Создания окружения для разработки

 

 

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

У нас есть такая сущность как эталонные базы:

  • Набор эталонных баз – это полный набор баз, необходимых для разработки и тестирования на данном проекте.

  • Эталонные базы уже содержат данные – они могут быть набиты вручную, либо это могут быть какие-то обрезанные копии рабочих баз.

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

Исходный код конфигураций и расширений мы храним в репозитории.

  • Для репозиториев мы используем GitHub и код храним в формате EDT.

  • Для каждого проекта есть специальный yaml-файл, где мы описываем, какие именно расширения и какая конфигурация относятся к какой эталонной базе. Например, у заказчика есть основная база, нам нужно поставить туда два расширения и обновить конфигурацию. В этом yaml-файле описывается связь между эталонными базами и конфигурациями/расширениями.

У нас используется изолированное окружение, которое содержит:

  • Отдельную копию всех эталонных баз, обновленных из репозитория.

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

Для тестирования разработанной функциональности мы пишем фичи и запускаем их на Vanessa Automation:

  • С помощью фич мы описываем BDD и интеграционные тесты на языке Gherkin.

  • Фичи у нас лежат в том же репозитории, где исходный код.

 

Расскажу подробнее про эталонные базы.

Для хранения эталонных баз мы используем Yandex object storage – это аналог S3 в Amazon.

  • Мы храним их в виде zip-архива с файловыми базами. На одном проекте у нас используется 6 баз, размер архива – 6 Гигабайт.

  • Чтобы получить эти базы на машину разработчика и, наоборот, измененные эталонные базы с машины разработчика загрузить назад в облако, нужно создать заявку в веб-интерфейсе Service Desk.

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

  • Например, у нас есть три теста «Заказ на эмиссию», «Печать марок» и «Отражение выпуска продукции». Мы могли бы выполнить эти тесты последовательно с одними и теми же марками, с одной и той же номенклатурой – они бы выполнились. Но это неудобно, потому что если нам нужно выполнить только второй тест или только третий, пришлось бы обязательно выполнять предварительные тесты.

  • Поэтому все эти три теста мы делаем с разными марками. А для этого предварительно вручную настраиваем эталонную базу – переводим эти марки в нужное состояние. В результате любой из этих тестов можно выполнить отдельно от других.

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

 

 

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

  • Здесь слева – общая структура. Обратите внимание, здесь много разных папочек, т.к. в репозитории лежит не только исходный код, но и внешние компоненты, фичи, CI-скрипты, скрипты для IIoT и т.д. Здесь весь исходный код, используемый на проекте – и 1С, и не 1С – все, что нужно.

  • Посередине – структура папки с 1С кодом. Тут куча каталогов – под все расширения и конфигурации, которые используются в проекте.

  • И справа – YAML-файл. В YAML-файле перечислены все конфигурации и расширения 1С, которые используются в проекте. И даны инструкции, как их собирать, на какие эталонные базы накатывать и так далее – вся структура проекта описана в виде YAML файла.

 

Про изолированное окружение.

Я уже сказал, что эталонные базы у нас лежат в S3 и там зафиксированы. А изолированное окружение – это отдельная копия эталонных баз, обновленная из Git, со всеми вспомогательными сервисами.

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

  • В состав изолированного окружения для наших проектов входят нужные базы 1С, отдельный vhost для RabbitMQ и отдельные лицензии для разных наших продуктов.

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

Зачем нам нужно «Изолированное окружение»?

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

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

Но есть ограничения:

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

 

Немного про сервисы и про наши основные этапы разработки.

У нас используются три этапа. Они же дублируются в Service Desk через заявки.

  • Первая заявка – создание изолированного окружения разработки.

  • Дальше разработчик в нем разрабатывает, помещает доработки из него в Git – это тоже отдельная заявка.

  • И отдельная заявка запускает тесты.

На слайде перечислены сервисы, которые мы сейчас используем.

  • База 1С для Service Desk – наш Service Desk с веб-интерфейсом, откуда все запускается.

  • Jenkins – наша основная рабочая лошадка.

  • GitHub – мы там храним весь наш исходный код.

  • Yandex Object Storage – мы там храним эталонные базы.

  • Yandex Compute Cloud – подключаем виртуальные машины для тестирования.

  • Виртуальные рабочие места, на которых работают наши сотрудники, мы арендуем в Selectel.

 

Вот так у нас выглядит заявка в Service Desk на создание окружения.

  • Указали проект.

  • Сказали, какие базы хотим дорабатывать.

  • Выбрали ветку, откуда хотим брать исходный код конфигурации и расширений для обновления.

  • Нажали кнопку и на рабочем месте сотрудника в списке баз появился набор баз по этой заявке – это скопированные эталонные базы, обновленные из той ветки, которую мы выбрали.

  • Дальше идем в конфигуратор и вносим нужные доработки в базу.

 

Шаг 3. Подходы к разработке

 

Расскажу, как у нас выглядят доработки типовых конфигураций:

  • Типовые конфигурации большие, и полная выгрузка-загрузка типовой конфигурации в исходные файлы может занимать много времени: для ERP, условно говоря – час.

  • У платформы есть возможность частичной выгрузки-загрузки, но она работает странно, не всегда и ненадежно.

  • Это и стало одним из основных препятствий к использованию EDT для доработки типовой конфигурации 1С:ERP.

Мы придумали несколько подходов, которые позволяют нам вообще не менять типовые конфигурации на ERP-шных проектах:

  • Это разработка в расширениях и использование «лысой» конфигурации – сейчас расскажу, что это такое.

  • И использование «типовых» расширений – мы сейчас на наших ERP-шных проектах типовую конфигурацию при разработке не меняем.

 

Первый прием – «лысая конфигурация».

  • Расширения сейчас пока не поддерживают добавление и изменение для всех объектов метаданных. Поддержку некоторых объектов метаданных в платформе 8.3.22 и 8.3.23 добавляют, но ERP пока еще в режиме совместимости с 8.3.16 (прим. ред. доклад от 6 октября 2022 года). Когда это дойдет до типовых – неизвестно, возможно, через три года.

  • Если мы все эти доработки будем вносить напрямую в ERP, то получим проблемы со скоростью разработки и обновляемостью.

В чем заключается подход?

  • Мы делаем отдельную чистую конфигурацию и делаем для нее XML-правила, которые можно выбрать в платформенном сравнении-объединении с типовой.

  • В эту «лысую» пустую конфигурацию мы добавляем:

    • свои новые объекты метаданных без реквизитов – это нужно, чтобы включить их в определяемые типы, которые в расширении мы пока менять не можем;

    • объекты, которые в расширении добавить нельзя – например, регламентные задания;

    • типовые объекты с реквизитами, содержащими определяемые типы, которые мы хотим расширить за счет своих объектов – для таких объектов в XML-файлике сравнения/объединения мы ставим режим «Объединять». В результате при сравнении/объединении с типовой состав типов будет объединен с типовым составом типов.

  • А весь код, формы и реквизиты мы уже добавляем в расширениях.

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

 

 

Конкретный пример – «лысая» конфигурация для проекта alcohol.

  • Мы в ней создали определяемый тип «ВерсионируемыеДанные» – он называется так же, как определяемый тип в типовой.

  • Добавили в этот определяемый тип свои объекты.

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

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

 

Следующий хитрый прием– это типовые расширения.

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

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

Чтобы это сделать, мы используем подход, очень похожий на логику построения БСП:

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

  • Если нам нужно какие-то функции переопределить, добавляем модуль адаптер_ИнтеграцияПроектный в проектном расширении.

  • Если мы хотим переопределить бизнес-логику не с точностью до модуля, а с точностью до процедуры, добавляем в модуль адаптер_ИнтеграцияПроектный одну специально названную процедуру ПриОпределенииМодулейСПодписками, которая возвращает список методов, переопределенных в проектном расширении относительно типового.

 

 

В конфигураторе это выглядит так.

  • внизу – проектное расширение ИСМПТ;

  • а вверху – типовое расширение БИТMDT.

В проектном расширении мы добавили модуль адаптер_ИнтеграцияПроектный, который переопределяет код из типового расширения.

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

 

Специальный слайд про EDT.

У нас сейчас есть два “геройских” сотрудника, которые полностью ведут разработку в EDT.

Поскольку использование двух подходов, о которых я рассказал, позволяет нам не менять типовую конфигурацию, обе главные проблемы использования EDT снимаются:

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

  • Одновременно это решает и проблему медленной работы EDT.

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

 

Шаг 4. Помещение изменений в GIT

 

Когда мы в изолированном окружении внесли изменения в конфигуратор по задаче, дальше нам нужно закоммитить эти изменения в Git.

Есть разные способы.

Можно выгружать в исходники, конвертировать в EDT и командами в Bash загружать в Git.

Но для наших обычных сотрудников мы сделали заявку в Service Desk, которая делает все то же самое автоматически:

  • сотрудник говорит путь к папке, где лежит окружение;

  • какие конфигурации или расширения он менял;

  • в какую ветку нужно положить;

  • и с каким комментарием.

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

Физически в этот момент на отдельной Jenkins-ноде запускается код, который копирует базу, из копии делает выгрузку в исходный код, конвертирует в формат EDT и коммитит в Git. Ничего сложного.

 

На слайде показано, как выглядит типичный коммит. Мы закоммитили код, на GitHub сразу видно, что получилось – в интерфейсе отображается дерево со структурой репозитория, очень удобно смотреть 1С-ные конфигурации.

По каждому коммиту мы, как правило, автоматически собираем релиз на GitHub Actions. Даже если это коммит в ветку, у нас собираются все CF, CFE, скрипты IIoT и прочее. Все, что относится к данному коммиту.

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

 

Шаг 5. Тестирование изменений

 

После того, как мы все закоммитили, запускаем тесты – про тесты я подробнее рассказал на митапе.

Тесты тоже запускаются по заявке в Service Desk – отчет по заявке с результатами тестов показан на экране.

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

  • Сценарии делятся по тегам. Плюс мы их запускаем в несколько попыток.

  • По каждому сценарию можно увидеть результаты, продолжительность.

  • Если нету «красных» итогов, значит, тесты прошли, и можно принимать.

Отсюда же открывается отчет Allure, который сгенерировала Vanessa Automation – там можно подробно посмотреть, где падало, и в чем была проблема.

 

Шаг 6. Пул-реквест

 

На слайде показано, как выглядит типичный pull request.

На что интересно обратить внимание.

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

 

Еще один типичный pull request – это пример с «лысой» конфигурацией alcohol.

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

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

Но поскольку репозиторий, где лежит эта «лысая» конфигурация и проектное расширение, общий, то и pull request тоже будет общий. И мы консистентно примем изменения – и в «лысой» конфигурации, и в расширении, где переопределен модуль из этой конфигурации.

 

Ключевые особенности

 

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

Первая особенность – сотрудники у нас разрабатывают на виртуальных машинах, а не на физических:

  • Эти виртуальные машины легко программно создавать и обновлять.

  • Кроме этого, мы можем выполнять код на этих машинах. Если бы разработчики у нас программировали на своих ноутбуках, мы бы не смогли выполнять код на их машинах – они не смогли бы делать через наш Service Desk такие заявки как «Создание окружения» или «Помещение в Git». А так как машинки виртуальные, то мы на них делаем, что хотим – можем сделать такую автоматизацию.

Мы используем Git и разрабатываем по подходу GitHub Flow – ветки develop у нас нет, у нас только feature-ветки и master.

  • С Git мы работаем либо напрямую, либо через заявки в Service Desk. Есть три основных способа.

    • Самый распространенный – это заявки в Service Desk.

    • Чуть более продвинутые товарищи работают в VS Code и оттуда коммитят.

    • И самые продвинутые товарищи работают в EDT, но их всего два человека.

  • Основная часть разработки у нас ведется в конфигураторе с использованием заявок.

Мы используем автосборку и автотесты.

  • Для автосборки – GitHub Actions, для автотестов – Vanessa Automation.

  • У нас есть возможность запускать тесты в любое время и в любом количестве.

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

Эти подходы мы используем на всех проектах – в том числе, на ERP-шных. Даже там, где есть интеграция с УПП.

  • Два простых приема доработки, о которых я рассказал, позволяют нам не исправлять типовую конфигурацию и не хранить ее исходный код в Git. Это сильно все ускоряет.

  • В Git мы храним только наши доработки.

 

Вопросы

 

Какие параметры у хостовых (железных) машин, которые у вас используются? И какие параметры у виртуальных машин, которые вы создаете для разработчика – сколько ядер и сколько зон выделяете на каждую рабочую машину?

Что касается машин разработчиков, то:

  • Когда у нас были виртуальные машины разработчика на Windows, у нас было 4 ядра на 16Гб оперативки.

  • Когда мы стали использовать виртуальные машины на Linux, у нас сейчас 4 ядра на 24 Гб оперативки, а для некоторых особо крутых разработчиков 4 ядра на 32 Гб – т.е. потребление памяти с переходом на Linux в полтора раза выросло.

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

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

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

А как вы решаете проблему с лицензиями, когда тестируете код на Vanessa Automation? Вы же когда подключаетесь к платформе, там должен быть ключ для пользователя и для менеджера тестирования.

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

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

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

А вы не боитесь хранить код в GitHub?

У нас приватные репозитории.

Я про другое. Вы не боитесь, что GitHub заблокирует российских пользователей?

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

Как вы решаете проблему кроссплатформенности? Вы сказали, что у вас вся архитектура на Linux. Но что вы делаете, когда возникают задачи, требующие использования внешних компонент, написанных на Windows, или COM-объектов – например, если нужно читать Excel, Word и т.д. Как такую проблематику решать?

Сейчас у нас такой проблемы нет, потому что мы – проектный офис, и количество проектов у нас ограничено. Когда мы беремся за какой-то проект, мы смотрим, есть ли возможность запустить его на Linux или нет – будут ли от этого какие-нибудь проблемы. И все эти проблемы мы обходим до того, как с ними сталкиваемся.

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

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

Как вы сейчас обновляете конфигурацию поставщика? Типовыми средствами через «дважды измененные»?

Мы не вносим изменения в конфигурацию поставщика. Чтобы получить конфигурацию, какая нам нужна, мы берем типовую, накатываем на нее «лысую» конфигурацию и применяем расширения.

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

Но если мы обновили конфигурацию вендора и накатываем на нее «лысую» конфигурацию, она же может не встать.

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

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

Это же вопрос не к нашему подходу, а к любому использованию расширений.

Очевидно, что когда мы в расширении переопределяем функцию с директивой &ЗаменаИКонтроль, в случае, если она поменялась, расширение не применится, и нам нужно будет что-то у себя менять.

Как вы проводите операцию сравнения/объединения расширения с конфигурацией вендора, чтобы понять, что нужно доработать?

А зачем их сравнивать / объединять? Мы контролируем применимость и проверяем тестами. Тестами мы покрываем всю нашу функциональность. Те проблемы, которые не выявились при проверке применимости – допустим, количество параметров поменялось – выявятся при тестах.

А дальнейшие действия какие? Разработчик должен сам проанализировать код расширения на совместимость с обновленной конфигурацией?

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

Как вы боретесь с пересечением расширений, когда одну процедуру заимствует несколько расширений? Случается ли у вас такое?

Мы стараемся так не делать. У нас, как правило, два расширения на проекте – типовое и проектное. Проектное расширение мы стараемся делать одно. Максимум, багфиксы еще делаем отдельным маленьким расширением, но потом их удаляем.

Мы не делаем много расширений на одном проекте – обычно два, а лучше одно вообще.

Вопрос по поводу «лысой» конфигурации. Каким образом вы автоматизируете создание конфигурационного файла для объединения?

Не автоматизируем. Он лежит в гите рядом с этой «лысой» конфигурацией. Разработчик, который объекты в «лысую» конфигурацию добавляет, он же и этот файл дорабатывает.

Там обычный XML-ный файл, который можно выгрузить в процессе платформенного сравнения/объединения – в нем можно перечислять не все объекты, а только отличия от того, что по умолчанию установится. Его вполне руками можно править.

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

Непонятно, в чем заключается ускорение? Например, мы, когда делаем новую ветку для разработки задачи, выполняем команду: git flow feature start. При этом загружается конфигурация и расширения. У нас сейчас основная проблема – это долгая загрузка основной конфигурации.

У нас есть эталонная база, где уже загружена основная конфигурация – она более-менее свежая, автоматически раз в день обновляется из ветки master.

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

Сравнение/объединение – это интерактивная история?

Можно и программно делать без интерактивных действий – через командную строку с вызовом конфигуратора и указанием XML-файла с настройками сравнения/объединения.

Сколько времени у вас занимает подъем одного такого рабочего места для новой задачи?

Минут 20.

Вы упоминали, что тестовые базы обрезаются для удобства и экономии места. Чем пользуетесь? Как обрезается база?

У нас нет единого набора инструментов и подхода – каждая проектная команда выбирает свой инструмент сама.

Критерии обрезки такие:

  • с одной стороны, нам нужно, чтобы в эталонных базах были все данные для проведения тестов;

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

А вариантов как обрезать – сколько угодно. Тут уж кто во что горазд – единого подхода нет.

 

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

Системы контроля версий для 1С-разработчиков.

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Платформа 1С v8.3 Платные (руб)

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    9391    78    4    

112

Обновляемый список последних статей Инфостарт для профиля Github

Групповая разработка (Git, хранилище) Бесплатно (free)

Не знаете, чем бы таким заполнить свой профиль Github? Заполните его своими статьями на Инфостарт! Этот простой workflow сам соберет список ваших последних статей и будет периодически обновлять его для актуализации данных.

08.04.2024    923    bayselonarrend    2    

31

Особенности национального Workflow: Github Actions и OneScript

Групповая разработка (Git, хранилище) OneScript Бесплатно (free)

Сегодня мы посмотрим на Github Actions - встроенный инструментарий Github для автоматизации рабочих процессов. Разберем, что это такое, зачем и причем тут OneScript.

25.03.2024    1570    bayselonarrend    3    

38

Автоматизация процесса разработки с помощью сервиса GitFlic

Групповая разработка (Git, хранилище) Бесплатно (free)

GitFlic – первая в России полностью самостоятельная реализация сервиса для хранения репозиториев с исходным кодом. За три года разработки сервис GitFlic стал полноценным инструментом, которым можно заменить GitLab, GitHub и BitBucket. Расскажем о том, как выстроить в GitFlic процесс автоматического тестирования, статического анализа кода и сборки приложений.

05.03.2024    2083    user1989937    6    

16

OpenYellow - рейтинг открытых GitHub репозиториев для платформы 1С:Предприятие

Групповая разработка (Git, хранилище) Бесплатно (free)

Обновляемый топ GitHub репозиториев для 1С по всем языкам программирования и еще немного рассуждений про open-source.

05.02.2024    4021    bayselonarrend    15    

63

Насколько глубок 1С-ный GitHub?

Групповая разработка (Git, хранилище) Бесплатно (free)

Open-source проекты - важная часть мира программного обеспечения. 1С привычно держится немного в стороне от глобальных трендов, но бросить холодный статистический взгляд на положение дел мне показалось небезынтересным.

22.01.2024    8061    bayselonarrend    50    

87

TCP прокси-сервер хранилища конфигурации 1С

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Платформа 1С v8.3 Бесплатно (free)

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    3013    kamisov    17    

60

Отдай корень! Библиотека OneScript для получения информации о захваченных объектах в хранилище

Групповая разработка (Git, хранилище) Бесплатно (free)

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

26.12.2023    1462    ardn    1    

27
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. comptr 31 03.04.24 07:23 Сейчас в теме
Как лучше организовать автоматическое изменение номера сборки в версии конфигурации?
Вот есть у нас расширение с версией конфигурации 1.2.3.4, разработка пока ведётся через хранилище, сделали выгрузку в гитлаб (GitSync) и запуск тестов (VA). В какой момент нужно менять номер сборки с 4 на 5? При каждом помещении в хранилище? При каждом запуске синхронизации с гитлабом? У кого какой опыт? Интересуют и технические детали (делать автоматический "коммит" в хранилище, который изменит номер сборки на +1 научился, но всё равно интересен сторонний опыт) и организационные аспекты.
2. Begemoth80 321 03.04.24 11:11 Сейчас в теме
А с какой целью нужно менять номер сборки с 4 на 5? Ну т.е. на выполнение тестов вроде это никак не влияет.
5. comptr 31 03.04.24 17:31 Сейчас в теме
(2) Так речь и не про тесты. У вас версия конфигурации расширения в процессе разработки не меняется? Всегда 1.0.1.1? А если меняется, то кто и когда её меняет? Вручную после успешного прогона тестов? После пулл-реквеста?
8. Begemoth80 321 03.04.24 20:55 Сейчас в теме
(5) Кажется, что в целом выгрузка конфигурации в GIT и запуск тестов никак не связаны с изменением версии конфигурации, т.е.
1. если у вас выгрузка в GIT и запуск тестов приводит к образованию релиза (который может быть скачен в т.ч. и пользователями) то версию можно менять автоматически в пайплайне сборки, но тогда возникает проблема, чтобы эта измененная версия не попала назад в вконтур разработки. Т.к. у нас (см.выше в презентации) помещение изменений в ГИТ, и получение базы для разработки автоматизировано через заявки, то мы при сборке инкрементировали версию, а при получении базы для разработки через заявку вырезали из номера последнюю "цифру" в номере. Т.е. грубо говоря в конфигурации у нас версия всегда 1.2.3.0, а в релизе 1.2.3.3546
2. если вы релизы собираете отдельно от ГИТ и тестов, то инкрементировать версию имеем смыл руками, тогда, когда это действительно надо (скажем перед выпуском релиза)
3. Dach 373 03.04.24 13:18 Сейчас в теме
(0) работал у вас на одном из проектов в качестве субподрядчика по описанной схеме.

Для разработчика все круто и удобно, схема работы по факту gitflow, но применительно к 1С очень много оверхэда.

С чем столкнулся лично:

- высокий порог вхождения в проект на этой схеме, особенно для тех сотрудников, кто никогда не работал с git, EDT и проч. У меня была коллега-девушка по той же схеме субподряда, поначалу приходилось много натаскивать ее и помогать;

- множество раз приходилось таскать cfe туда-сюда и дообновлять свою конфу со своей фича-бранчей, перед тем как пушить изменения в ветку, чтобы оформить корректный пулл-реквест. Потому что пока пилишь свою фичу - мастер успевает тебя обогнать. Как-то раз в течении дня три раз подряд пришлось этим заниматься, потому что пока я тащил свежий cfe из мастера в свою конфу - там принимали новый PR, проходила сборка и мастер снова меня обгонял. Проблему лично я для себя частично решил так: развернул локальный репо, через интерфейс гит-хаба нажимал кнопку обновления ветки (она доступна тогда, когда нет конфликтов между изменениями в ветке и мастером), затем спулливал в локальный репо эту ветку, из нее собирал cfe и накатывал на свою конфу (таким образом сохраняя и свои изменения и свежие из мастера). Но все это работает, только если можно без конфликтов в свою ветку подтащить изменения из мастера, той самой кнопкой в интерфейсе гит-хаба (ну или командой pull master ---> branch, которую она по факту и вызывает)

- вся команда работают через конфигуратор, но файлы в репо зачем-то хранятся в формате EDT. Зачем? Чтобы еще побольше оверхэда было? Чтобы собирать cfe из такой ветки - пришлось ставить EDT нужной версии и в него втыкать плагин edt.cf_builder;

- отдельный геморрой - это когда все-таки нельзя сделать доработку через все эти "хитрости" (по мне - так это не "хитрости", а "костыли" - называйте уж вещи своими именами) с расширениями, например проиндексировать типовой реквизит или измерение в любой таблице (справочник, РН, РС и т.д.). Всю боль описывать не буду, но у меня как-то раз ушло на это 1.5 (sic!!!) рабочих дня, хотя обычно это делается за 10 минут;

- вы хвастаетесь своими "удобными" ВМ, которые поднимаете для каждого разработчика, но по факту внутри ВМ стоит linux, на котором в конфигураторе работать ооочень неудобно (тормоза, глюки и некоторые баги, кто работал так - знает). Поэтому по факту абсолютно вся команда работает на своих локальных тачках, а на ВМ таскает только cfe-шки, чтобы была возможность через заявку запушить конфу в свою ветку по итогу разработки фичи;

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

- эти вечные сравнения-объединения после каждого "догоняния" мастера и такие же сравнения-объединения при помещении своих изменений в "нормальную" БД - несут дополнительный риск в виде человеческого фактора (когда кто-то что-то не до конца поместил и т.д.);

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

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

P.S. Как-то раз я сел и примерно подсчитал, насколько для конечного заказчика разработка по такой схеме будет дороже, чем через классические хранилища и подъем собственной инфраструктуры на своих мощностях. Получилось примерно 35-40% при прочих равных. А ведь еще надо учесть, что вся ваша инфраструктура расположена на арендованных облаках + у вас целый штат девопсеров, которые все это поддерживают и поднимают, когда оно падает (а оно таки иногда падает, что ВМ разрабов, что сборочные линии). Так что по факту там все 50%, а не 35%.

P.P.S Лично у меня сложилось впечатление, что вы шли примерно таким путем: "А давайте разрабатывать так, как это делают в больших командах, gitflow и все дела? А давайте! Давайте хранить исходники в гит-сервере и давайте хранить их в формате EDT, мы ведь через него будем с фича-бранчами работать, он же умеет это из коробки? А давайте!". А потом начались "нюансы" - оказалось что и основную конфу таких проектов как ERP хранить в гите очень дорого и что разрабатывать на самом EDT для большинства "обычных" 1С-ников (которые и являются ядром любой проектной команды) - тоже непросто, их учить надо и погружать во все нюансы такой разработки.

Итого, что имеем на выходе. Разработка через gitflow, плюсы: код-ревью, статический анализ кода перед принятием PR. Тут да, не поспорить, качество кода в таком проекте будет выше, чем при использовании классических хранилищ. Запуск тестов "на ветке" перед приемкой PR - тоже несомненный плюс (но уже не такой весомый, так как и в классических хранилищах тесты можно запускать хоть по расписанию, хоть по событию появления новой версии в хранилище). Ну и на этом, пожалуй, все (если смотреть с точки зрения конечного заказчика). Минусы, геморрой и оверхэд - все описал выше. Да, для разработчика все это круто, погрузиться в "современный мир" и т.д. и т.п. Но... сама платформа устроена так, что работать с большими конфигурациями через гит - удовольствие то еще... Для небольших - да, плюсы начинают перевешивать, причем существенно.

Все написанное - исключительно ИМХО. Решил, что раз уж вышла такая статья, то надо дать фидбэк как того человека, который в этой среде как следует поварился. В целом, лично мне, после привыкания (у меня это было примерно 2 недели, но только потому, что я ранее уже со всем инструментарием был знаком) - было комфортно так разрабатывать, а благодаря стат. анализу и код-ревью - я лично стал писать почище и ближе к стандартам, чем до вхождения на проект. То есть, в плюсы еще можно записать тот факт, что компетенции команды растут в процессе такой разработки.
Karras; Cyberhawk; prof-it60; Programador1C; amiralnar; Dimasik2007; roman72; Krio2; skeptik2105; glebushka; kotlovD; fancy; w.r.; kuntashov; artbear; partizand; dmnblg; triviumfan; kauksi; it_tungus; support; ardn; +22 Ответить
6. comptr 31 03.04.24 17:44 Сейчас в теме
(3)
ножество раз приходилось таскать cfe туда-сюда и дообновлять свою конфу со своей фича-бранчей, перед тем как пушить изменения в ветку, чтобы оформить корректный пулл-реквест. Потому что пока пилишь свою фичу - мастер успевает тебя обогнать

Что принципиально изменится, если разработка ведётся через хранилище? Вместо того, чтобы сравнивать конфигурацию перед PR, вы потратите временя на "а тебе ещё нужен ИмяМодуля, я в него хочу процедуру добавить? ой, а я там две процедуры поменял, щас закину в хранилище / сохраню цф себе, откачу модуль потом заново захвачу" или "не могу отдать объект, на него много завязано, а класть в хранилище рано, так как не доделано, а если положу, сломаю другой код".


(3)
по некоторым задачам, после их выполнения, например после добавления предопределенных элементов или каких-то данных, которые должны быть у всех (нетиповые добавленные настройки, например) - необходимо также еще сходить и обновить эталонную базу, чтобы все новые подъемы свежих "окружений" уже получили БД с наличием этих данных

При разработке через хранилище не нужно идти обновлять эталонную базу? Или всё тестируется в одной общей базе? Никто не запрещает тестировать в одной базе и при разработке через гит.
7. Dach 373 03.04.24 19:25 Сейчас в теме
(6)
вы потратите временя на "а тебе ещё нужен ИмяМодуля, я в него хочу процедуру добавить? ой, а я там две процедуры поменял, щас закину в хранилище / сохраню цф себе, откачу модуль потом заново захвачу" или "не могу отдать объект, на него много завязано, а класть в хранилище рано, так как не доделано, а если положу, сломаю другой код".


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

(6)
При разработке через хранилище не нужно идти обновлять эталонную базу? Или всё тестируется в одной общей базе?


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

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

Или так называемые "фантомные" изменения в файлах при выгрузке (обычно это на файлах ролей проявлялось). Это прям был бич того проекта. Вроде все делаешь правильно, по технологии - скачал свежий cfe из релизов, накатил на свою ИБ, выполнил разработку, перед пушем в ветку еще раз накатил cfe из мастера, на всякий случай сравнил-объединил по финалу - видишь в интерактиве только свои изменения. Пушишь в ветку, оформляешь PR и видишь в списке изменений относительно мастера не только свои, но еще и изменения на файлах ролей (какие-то теги внутри xml добавлены или удалены).

На самом деле лично мне самому очень нравится и концепция git и те возможности, которые дает gitflow.
Но применительно к 1С, а конкретно к крупным проектам - это все оказывается на деле существенно дороже классической разработки при том, что преимущества от gitflow не перекрывают это удорожание. Например на том проекте (а он был прям реально крупный) - крайне редко я встречал ситуации, когда 2 разработчика одновременно пилили один и тот же объект/модуль. Все основные конфликты всегда - на корне, то есть на файле описания метаданных. Из-за всего описанного оверхэда среднестатистический разработчик в такой среде тратит на 30-35% больше времени, чем если бы он делал все тоже самое, но через хранилище. Прибавьте сюда облака, штат спецов и трудозатраты на погружение-обучение новых разработчиков.

P.S. Кстати, статья немного устарела и на текущий момент github закрыл доступ к своим корп-фичам и корп-разработке для организаций из РФ. Поэтому нам в какой-то момент пришлось переезжать на собственный gitlab, который опять-таки - в облаке Яндекс.

Ну и по опыту, команда до 12-15 разработчиков может более-менее спокойно уживаться в одном хранилище без сильных конфликтов за объекты (а если таковые и возникают - то решаются административным регламентом).

Итого (имхо, повторюсь): gitflow в 1С - круто, стильно, модно, молодежно, но прям сильно дорого.

P.P.S Все сказанное не отменяет того факта, что команда BIT.ERP - одна из самых сильных на рынке. Качественно выше, чем большинство их проектных офисов. В том числе и сама инфраструктура и методология, мне например очень нравилось, что у них везде сквозная kerberos-авторизация, во всех сервисах. И удобный проектный мессенджер, импортозамещенный аналог Slack - Пачка
Также очень сильные аналитики и консультанты, костяк разработчиков тоже. Работать в такой команде - одно удовольствие, вспоминаю с теплом.
amiralnar; Dimasik2007; kuntashov; support; comptr; +5 Ответить
17. roman72 380 06.04.24 10:16 Сейчас в теме
(3) Статья отличная, а ваш коммент к ней ещё лучше :)
4. support 4485 03.04.24 14:46 Сейчас в теме
Безумству храбрых поем мы песню!
Молодцы! Главное, что это работает. Ждем продолжения.
9. kotlovD 87 04.04.24 09:58 Сейчас в теме
Я хотел в команде попробовать ввести разработку расширений, именно расширений, с гит версионированием. Не дошло даже до какие то тестов, все сломалось еще в процессе того как я прогонял схемы такой работы у себя локально.
1. выгрузка конфигурации в файлы - столкнулся с тем, что платформа могла тупо потерять модуль по дороге, обычно у меня это были модули менеджера, в конфигураторе он есть, смотришь в выгрузку - нет. Ну и соответственное если вовремя это не увидеть, то будет беда
2. мерж форм через гит то еще удовольствие и как правило автоматически корректно они не мержаться и после этого приходится руками приводить xml в порядок.
11. Dach 373 04.04.24 11:19 Сейчас в теме
(9)
Типовые формы так или иначе пилить надо только кодом. Хоть гит, хоть хранилище. На нетиповых рулить административно, не давать 2 разных задачи по одной и той же форме 2-м разным разрабам в одно и тоже время
12. kotlovD 87 04.04.24 11:45 Сейчас в теме
(11) да, само собой речь про не типовые формы.
Еще вспомнил момент, если 2 разработчика заимствуют один и тот же объект в расширение в разных ветках, то потом этом будет проблема при мерже, будет создано два одинаковых объекта в конфигурации раширения с разными идентификаторами.
В общем из всего этого есть только один выход, это использовать EDT или конфигуратор и ручное сравнение и объединение в качестве mergetool
13. Dach 373 04.04.24 12:22 Сейчас в теме
(12)
Ну даже если и проблема при мерже. Какой-то один PR все равно будет первым. И тогда второму разрабу придётся самому разрулить конфликт перед финальной просьбой принять его PR. Это и есть часть того самого оверхэда, о котором я столько букв уже написал. И тут ещё нужна внимательность как со стороны код-ревьюера, так и со стороны бранч-разраба, так как не всегда такие проблемы в интерфейсе MR или PR отображаются как конфликты
14. kotlovD 87 04.04.24 12:26 Сейчас в теме
(13) так как раз конфликта и не будет, неправильно выразился, сам мерж гит сделает на автомате, а вот когда загрузишь к себе такую смерженную конфу из файлов, получишь два одинаковых объекта с разыми уид и надо опять идти править xml руками
16. Dach 373 04.04.24 12:32 Сейчас в теме
(14)

Да, я понял, о чем речь. Ну об этом и говорю. Бранч-разраб второго PR и код-ревьюер, который этот PR принимает в мастер - должны это все увидеть. Поэтому, я например, всегда перед финальной просьбой о принятии моего PR еще визуально просматривал ВСЕ файлы (в том числе и xml) на предмет того, точно ли там только мои изменения...
Когда с хранилищем работаешь - таких лишних затрат мозготоплива и времени там нет.
10. gybson 04.04.24 10:33 Сейчас в теме
У нас почти как у коллег, только попроще =)
У меня на виндовом VDI развернут просто весь стэк.
Обычно конфликтов нет. Но если есть, то я прям без рефлексси git reset --hard, загрузка, сравнение объединение, выгрузка. В гите у нас воообще все, кроме пары конфигураций, которые хранилище+гит.
Интеграция с Jira очень удобная штука. При коммите, при мердже в релиз, все это комментарием к задаче указывается.

Еще могу запустить VS и просто открыть в нем репозиторий, там плагин BSL какие-нибудь гадости красным отметит, разок так увидел пропущенные параметр вызова процедуры.

В общем дело привычки. Не сказать чтобы это прям сильно мешало разработчику.
15. Begemoth80 321 04.04.24 12:27 Сейчас в теме
(4) Спасибо! Прошло 2 года, полет нормальный :-)
18. roman72 380 06.04.24 10:24 Сейчас в теме
Статья великолепная, предложенная технология мне вполне импонирует,
частично то или иное мне приходилось делать или хотя бы продумывать.

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

ЗЫ Касаемо изобретённого термина "лысая" конфигурация - ну зачем?
Был же хороший термин "конфигурация поставщика" - это же оно и есть.
А "лысое" оно лишь в течение первых 5 минут после создания конфы.
19. gybson 08.04.24 10:37 Сейчас в теме
(18) Где-то было исследовано, что оптимальный размер коммита - 50 строк. Думаю от этой цифры вполне можно отталкиваться. R&D конечно сложно укладывать в рамки обычно разработки и не надо это вообще делать.
20. Viktor_Ermakov 364 09.04.24 12:06 Сейчас в теме
Хочу воспользоваться опытом автора, и прийти к такому же обновлению доработанной типовой конфигурации.
В связи с чем, есть несколько вопросов:

1. Какой именно эффект дает "ЛЫСЫЕ" объекты в объединяемой конфигурации, почему там плохо хранить реквизиты, формы и модули? Я верю что так лучше, но никак не пойму в чем? Можете описать именно на какие грабли наступали, когда делали не "ЛЫСЫЕ" объекты?

2. Начал применять Вашу схему, и вот с чем столкнулся на формах объектов.
Если форма добавлена в расширении, то в ее командном интерфейсе ничего не видно, а так же в Команды - Глобальные команды нет параметризируемых команд.
21. Begemoth80 321 09.04.24 21:59 Сейчас в теме
(20)
почему там плохо хранить реквизиты, формы и модули?

По нескольким причинам:
1. Как правило доработки связны с доработками типовой конфигурации, а в отдельную конфигурацию не "наследуешь" объекты из основной конфигурации, как в расширение. Т.е. из этой отдельной конфигурации нельзя обращаться к объектам типовой, по этому реализовать там более-менее сложную логику нельзя.
2. При объединении этой отдельной конфигурации с типовой, объединение должно проходить автоматически (без участия человек), значит ее результат должен быть предсказуемым и без дважды измененных объектов
3. Чтобы на каждом проекте не искать где, находиться логика, принято решение об однотипном разделении для всех: в расширении вся логика, в отдельной конфигурации, то, то невозможно добавить в расширении. В одной из следующих версий от отдельной конфигурации можно будет отказаться (когда все научаться делать в расширении)

ничего не видно, а так же в Команды - Глобальные команды нет параметризируемых команд.

Ну так вроде для этого их тоже надо в расширение добавить
22. Viktor_Ermakov 364 09.04.24 22:42 Сейчас в теме
Уточняю вопрос, я имел ввиду объекты которые созданы нами с нуля, почему их формы, реквизиты и код нельзя оставить в отдельной конфигурации, ведь объединение с ними будет безболезненно.

На счет форм, вот команда создать на основании, она делается платформой, как ее заимствовать. И она не отображается так же.
23. Dach 373 10.04.24 09:59 Сейчас в теме
(22)

По поводу стандартных команд объекта - как раз довод в пользу создать объект в основной конфигурации, через её сравнение-объединение с "лысой". А вот формы этого объекта, макеты и реквизиты - да, можно уже в основном расширении (если применять эту технологию). Это касается хранимых сущностей. Всякие обработки и тд - можно спокойно добавлять в расширение сразу
24. Viktor_Ermakov 364 15.04.24 08:41 Сейчас в теме
(23)
Так вот, я на счет форм.
1 картинка это форма основной конфигурации, вкладка "командный интерфейс", как видно там есть команды перейти, Важное и создать на основании.
2 картинка это форма расширения того же объекта, там нет команд как на вкладке "командный интерфейс" так и нет глобальных параметризуемых команд, что бы их добавить. При этом все команды отображаются в предприятии, но настроить их отображение возможности нет.
Как Вы с этим боритесь?

И еще раз, почему если мы объект добавляем в лысую конфигурацию, форму этого объекта нужно добавлять в расширении а не туда же в лысую, чем это обусловлено?

P.S. Картинки почему то не загружаются в ответ, жду ответа от поддержки.
Оставьте свое сообщение