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

Меня зовут Валерий Дыков, я расскажу о том, как можно разрабатывать для 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.