Процесс разработки с использованием 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.

a3e52412cd0e9ba5955aaa995474074f.png

Приобретайте 1С:ERP в Инфостарт с бонусом 15%!

  • Бесплатное демо продукта и консультация
  • Команда экспертов 1С с опытом 10+ лет
  • Оценка проекта, четкий план работ, документация, обучение и поддержка

Закажите расчет внедрения ERP - получите дорожную карту в подарок!


См. также

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

Использования систем контроля версий — стандарт современной разработки. На курсе научимся использованию Хранилища 1С и GIT при разработке на 1С:Предприятие 8. Разберем подходы и приемы коллективной разработки, научимся самостоятельно настраивать системы и ориентироваться в них.

4900 руб.

29.06.2022    12062    104    4    

134

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

Когда в хранилище одновременно разрабатывают несколько команд, сортировка сделанного и несделанного при формировании релиза и проведение code review по задачам превращаются в непроходимый квест. В таких случаях нужен бранчинг. Расскажем об опыте перехода на новую схему хранения кода для ИТ-департамента.

23.09.2024    3156    kraynev-navi    2    

25

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

Называть Git новой технологией – уже смешно, но для многих 1С-ников это действительно «новое и неизведанное». Расскажем о плюсах и минусах двух главных систем контроля версий в мире 1С: Git и хранилища.

17.09.2024    7783    Golovanoff    69    

26

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

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

05.09.2024    2439    ardn    12    

15

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

Заказчики любят EDT+Git за прозрачность и контроль качества. А у разработчиков есть две основные причины не любить EDT – это тормоза и глюки. Расскажем о том, что нужно учесть команде при переходе на EDT+Git.

14.08.2024    7912    lekot    34    

8

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

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

05.08.2024    4749    sinichenko_alex    16    

25

Групповая разработка (Git, хранилище) Программист Руководитель проекта Стажер Бесплатно (free)

Про изменения и новинки в агрегаторе открытых проектов OpenYellow, которые появились с момента его создания: про портал, Github и Telegram

15.07.2024    3491    bayselonarrend    8    

24
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. comptr 35 03.04.24 07:23 Сейчас в теме
Как лучше организовать автоматическое изменение номера сборки в версии конфигурации?
Вот есть у нас расширение с версией конфигурации 1.2.3.4, разработка пока ведётся через хранилище, сделали выгрузку в гитлаб (GitSync) и запуск тестов (VA). В какой момент нужно менять номер сборки с 4 на 5? При каждом помещении в хранилище? При каждом запуске синхронизации с гитлабом? У кого какой опыт? Интересуют и технические детали (делать автоматический "коммит" в хранилище, который изменит номер сборки на +1 научился, но всё равно интересен сторонний опыт) и организационные аспекты.
2. Begemoth80 341 03.04.24 11:11 Сейчас в теме
А с какой целью нужно менять номер сборки с 4 на 5? Ну т.е. на выполнение тестов вроде это никак не влияет.
5. comptr 35 03.04.24 17:31 Сейчас в теме
(2) Так речь и не про тесты. У вас версия конфигурации расширения в процессе разработки не меняется? Всегда 1.0.1.1? А если меняется, то кто и когда её меняет? Вручную после успешного прогона тестов? После пулл-реквеста?
8. Begemoth80 341 03.04.24 20:55 Сейчас в теме
(5) Кажется, что в целом выгрузка конфигурации в GIT и запуск тестов никак не связаны с изменением версии конфигурации, т.е.
1. если у вас выгрузка в GIT и запуск тестов приводит к образованию релиза (который может быть скачен в т.ч. и пользователями) то версию можно менять автоматически в пайплайне сборки, но тогда возникает проблема, чтобы эта измененная версия не попала назад в вконтур разработки. Т.к. у нас (см.выше в презентации) помещение изменений в ГИТ, и получение базы для разработки автоматизировано через заявки, то мы при сборке инкрементировали версию, а при получении базы для разработки через заявку вырезали из номера последнюю "цифру" в номере. Т.е. грубо говоря в конфигурации у нас версия всегда 1.2.3.0, а в релизе 1.2.3.3546
2. если вы релизы собираете отдельно от ГИТ и тестов, то инкрементировать версию имеем смыл руками, тогда, когда это действительно надо (скажем перед выпуском релиза)
3. Dach 383 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 недели, но только потому, что я ранее уже со всем инструментарием был знаком) - было комфортно так разрабатывать, а благодаря стат. анализу и код-ревью - я лично стал писать почище и ближе к стандартам, чем до вхождения на проект. То есть, в плюсы еще можно записать тот факт, что компетенции команды растут в процессе такой разработки.
Alex17; nsirotkin@mail.ru; Дмитрий74Чел; dabu-dabu; user1147832; manlak; Karras; Cyberhawk; prof-it60; Programador1C; amiralnar; Dimasik2007; roman72; tulakin_s; skeptik2105; glebushka; kotlovD; fancy; w.r.; kuntashov; artbear; partizand; dmnblg; triviumfan; kauksi; it_tungus; support; ardn; +28 Ответить
6. comptr 35 03.04.24 17:44 Сейчас в теме
(3)
ножество раз приходилось таскать cfe туда-сюда и дообновлять свою конфу со своей фича-бранчей, перед тем как пушить изменения в ветку, чтобы оформить корректный пулл-реквест. Потому что пока пилишь свою фичу - мастер успевает тебя обогнать

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


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

При разработке через хранилище не нужно идти обновлять эталонную базу? Или всё тестируется в одной общей базе? Никто не запрещает тестировать в одной базе и при разработке через гит.
7. Dach 383 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 390 06.04.24 10:16 Сейчас в теме
(3) Статья отличная, а ваш коммент к ней ещё лучше :)
4. support 4453 03.04.24 14:46 Сейчас в теме
Безумству храбрых поем мы песню!
Молодцы! Главное, что это работает. Ждем продолжения.
9. kotlovD 88 04.04.24 09:58 Сейчас в теме
Я хотел в команде попробовать ввести разработку расширений, именно расширений, с гит версионированием. Не дошло даже до какие то тестов, все сломалось еще в процессе того как я прогонял схемы такой работы у себя локально.
1. выгрузка конфигурации в файлы - столкнулся с тем, что платформа могла тупо потерять модуль по дороге, обычно у меня это были модули менеджера, в конфигураторе он есть, смотришь в выгрузку - нет. Ну и соответственное если вовремя это не увидеть, то будет беда
2. мерж форм через гит то еще удовольствие и как правило автоматически корректно они не мержаться и после этого приходится руками приводить xml в порядок.
11. Dach 383 04.04.24 11:19 Сейчас в теме
(9)
Типовые формы так или иначе пилить надо только кодом. Хоть гит, хоть хранилище. На нетиповых рулить административно, не давать 2 разных задачи по одной и той же форме 2-м разным разрабам в одно и тоже время
12. kotlovD 88 04.04.24 11:45 Сейчас в теме
(11) да, само собой речь про не типовые формы.
Еще вспомнил момент, если 2 разработчика заимствуют один и тот же объект в расширение в разных ветках, то потом этом будет проблема при мерже, будет создано два одинаковых объекта в конфигурации раширения с разными идентификаторами.
В общем из всего этого есть только один выход, это использовать EDT или конфигуратор и ручное сравнение и объединение в качестве mergetool
13. Dach 383 04.04.24 12:22 Сейчас в теме
(12)
Ну даже если и проблема при мерже. Какой-то один PR все равно будет первым. И тогда второму разрабу придётся самому разрулить конфликт перед финальной просьбой принять его PR. Это и есть часть того самого оверхэда, о котором я столько букв уже написал. И тут ещё нужна внимательность как со стороны код-ревьюера, так и со стороны бранч-разраба, так как не всегда такие проблемы в интерфейсе MR или PR отображаются как конфликты
14. kotlovD 88 04.04.24 12:26 Сейчас в теме
(13) так как раз конфликта и не будет, неправильно выразился, сам мерж гит сделает на автомате, а вот когда загрузишь к себе такую смерженную конфу из файлов, получишь два одинаковых объекта с разыми уид и надо опять идти править xml руками
16. Dach 383 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 341 04.04.24 12:27 Сейчас в теме
(4) Спасибо! Прошло 2 года, полет нормальный :-)
18. roman72 390 06.04.24 10:24 Сейчас в теме
Статья великолепная, предложенная технология мне вполне импонирует,
частично то или иное мне приходилось делать или хотя бы продумывать.

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

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

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

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

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

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

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

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

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

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

P.S. Картинки почему то не загружаются в ответ, жду ответа от поддержки.
25. user1171014 01.08.24 13:05 Сейчас в теме
Подскажите пожалуйста как Вы решаете вопрос ссылок на объекты которые отсутствуют в "лысой" конфигурации?
и как собираете .cf чтобы при переносе в основную конфигурацию не терялись ссылки?
Например если в Вашем справочнике "НовыйСправочник" тип реквизита "СправочникСсылка.Номенклатура", а справочника "Номенклатура" в "лысой" конфигурации нет, он в основной.
26. Begemoth80 341 02.08.24 10:12 Сейчас в теме
(25)
"Номенклатура" в "лысой" конфигурации нет


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