Командная разработка облачных продуктов, используя 1С:EDT

Владислав: Меня зовут Владислав Маковеев, я выступаю вместе с моим коллегой Виталием Черкасовым.

Расскажем о том, как мы разрабатываем: что к нам пришло вместе с EDT, как мы вообще пытаемся адаптироваться в этом мире.

Владислав: Особенность нашей разработки в том, что мы дорабатываем облачные решения, поэтому все наши информационные базы обязательно должны быть опубликованы на сервере 1C и взаимодействовать между собой.

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

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

Владислав: Мы вывели несколько подходов к тому, как можно с этим работать.

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

• Второй – когда свой стенд есть у каждого разработчика.

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

Мы выбрали первые два подхода и сейчас про них расскажем.

Распределение серверных стендов: когда под каждый технический проект выделяется отдельный стенд разработки

Виталий: Наша команда разработки пошла по первому пути – у нас на один стенд назначен один технический проект.

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

Схема работает следующим образом:

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

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

• Когда разработка завершена, разработчик выполняет слияние с веткой master, которая находится на основном стенде.

• И потом изменения в ветке master, в свою очередь, вливаются в общий с заказчиком репозиторий.

Виталий: Схема сама по себе достаточно простая, но хочется затронуть ее недостатки:

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

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

Виталий: Теперь о плюсах.

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

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

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

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

Схема достаточно простая, и она нас сейчас полностью устраивает.

Но что делать в том случае, если сложность технических проектов возрастет и уже не получится распределить задачи таким образом, чтобы каждый разработчик сидел в своей конфигурации?

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

• добавляются локальные базы, где разработчики добавляют свою функциональность;

• после чего они делают мерж-реквест в ветку, которая привязана к основному тестовому стенду;

• и опять-таки выполняется слияние с мастер-веткой.

Распределение серверных стендов: когда отдельный стенд разработки выделяется под каждого разработчика

Владислав: Теперь о порядке разработки в нашей команде.

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

• первый – для разработки, Dev;

• и второй – тестовый сервер, TSN (Test Server N).

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

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

Владислав: Поэтапно пройдемся по этой схеме:

• У нас появился стенд RC (Release Candidate), на котором содержится самая актуальная версия, выпущенная в релиз.

• Также используются стенды DM (Develop Master) и TM (Test Master). На них также находится актуальная версия, но уже с внесенными доработками, исправлениями ошибок и прочим – с тем, что войдет в будущий релиз.

• И далее к этим стендам уже присоединяются стенды DevN, которые относятся к конкретным разработчикам. Разработчики делают на них фиксы, фичи и потом отправляют мерж-реквест, чтобы влить это в Develop Master. Таких стендов может быть несколько, потому что разработчиков у нас много, и их количество может увеличиваться.

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

Владислав: Таким образом, мы столкнулись со следующими недостатками.

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

• Исходя из первого минуса, появляется второй. Если мы замещаем конфигурацию, у нас и данные могут удалиться – у нас же на разных проектах объекты метаданных в большинстве случае будут меняться. А при изменении метаданных данные в информационной базе могут очищаться. Чтобы обойти этот эффект, мы пока что используем внешнюю обработку «Выгрузка и загрузка данных XML» и выгружаем нужные данные в XML, а потом при необходимости загружаем обратно. Но также думаем, как вообще можно оптимизировать данный шаг.

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

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

Владислав: Но было бы грустно закончить на недостатках, поэтому поговорим про преимущества данного подхода.

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

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

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

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

  • Первое – на стенде всегда должны быть валидные тестовые данные. Например, недопустимо, чтобы в справочнике «Контрагенты» элементы назывались просто «Тест1» и «Тест2».

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

  • И последнее – нужно писать код так, чтобы не ушатать сервер.

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

Работа с ветками Git. Вариант доработанного GitFlow

Владислав: Теперь немного поговорим про Git. В нашей команде разработки мы используем методологию GitFlow. Выглядит она примерно так, как на слайде, но с небольшими изменениями.

Владислав: Изменения состоят в том, что из веток future и веток HotFix у нас создаются дополнительные ветки. Они нужны, поскольку у нас есть джуниор-разработчики, которые иногда не понимают, как правильно писать код и допускают ошибки в оптимизации.

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

Для этих веток есть некоторый регламент:

• они должны называться так же, как и основная ветка;

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

  • когда ветка не прошла мерж-реквест – тогда в нее сначала нужно внести исправления, а потом снова вливать;

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

На подобных код-ревью мы джуниоров обучаем и не допускаем, чтобы они пушили в основные ветки (у них на это нет прав).

Владислав: Для трека задач мы используем Jira – в ней удобно работать, и у нее есть интеграция с Git-сервером:

• можно использовать Bitbucket;

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

После настройки такой интеграции в карточке задачи появляется возможность «Создать ветку». При ее нажатии появляется окошко, где мы можем выбрать, какое приложение запустить, чтобы развернуть ветку.

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

Интеграция автоматически подставляет наименование этих веток с единственным отличием:

• в GitLab имя ветки пишется транслитом на латинице и полностью;

• а в Bitbucket имя ветки пишется на кириллице, но при этом вставляется не полностью.

Эти особенности разворачивания следует учитывать.

Владислав: В GitLab интеграция с Jira тоже встроена – там в коммитах можно указывать ссылки на задачи. При этом неважно, откуда вы сделаете коммит – из EDT или из консоли. Мы в коммите GitLab можем нажать на ссылочку, а дальше нас перекинет на карточку задачи.

Владислав: Настроить такие интеграции в самом GitLab можно на вкладке «Интеграции». Если на стороне Jira интеграция настроена, там появится зеленая галочка, что все окей, и вы сможете указывать в коммитах ссылки на задачи.

Работа с ветками Git. Вариант доработанного GitHub Flow

Виталий: Теперь про использование Git в нашем отделе.

Мы используем методологию GitHub Flow, только немного измененную. Причем мы используем GitHub Flow для GitLab.

Особенность нашего GitHub Flow в том, что мы не делаем мерж-реквесты в мастер-ветку, а делаем слияние в ветку разработки – почему мы так делаем, я расскажу чуть позже.

У нас есть небольшой регламент по наименованию веток для техпроектов:

• сначала идет feature – то есть мы добавляем что-то новое;

• дальше идет код технического проекта в СППР;

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

CI/CD. Подход через полный переход на EDT и Git

Владислав: Пока мы разбирались с EDT и разворачивали Git, нам пришла мысль: почему бы нам не организовать у себя CI/CD?

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

Владислав: Пока что у нас CI полностью не реализован, но я с вами поделюсь планами, каким он будет:

• Первое, что у нас происходит – это push либо merge request. Таким образом, мы сначала что-то мержим.

• Далее у нас запускаются ранеры от GitLab, которые у нас развернуты на сервере, и эти ранеры уже начинают запускать скрипты Jenkins.

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

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

• И далее уже по исходу у нас приходит сообщение от специального telegram-бота, что мерж-реквест успешно прошел автотест, его можно заливать.

• Или, если все плохо, то он пишет, какие ошибки есть, их количество. В будущем потом это можно будет посмотреть в отчете Allure либо в СППР.

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

CI/CD Подход с использованием хранилищ и 1С:ГитКонвертер

Виталий: Теперь немного про CI/CD в нашем отделе.

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

• Исходя из этого, у нас вытекает второй пункт – мы используем 1С:ГитКонвертер, чтобы выполнять синхронизацию наших репозиториев в Git и хранилищ.

• Третий пункт – разработку мы выполняем с помощью EDT в рамках технических проектов. Hotfix выполняем с помощью расширений с прямой установкой на прод руками и помещением напрямую в хранилище.

• Четвертый пункт – как я уже говорил в блоке про Git, слияние мы выполняем не в мастер-ветку, а в ветку разработки. Это важно, чтобы использовать полную функциональность EDT для разрешения конфликтов Git – мы сначала делаем слияние, затем получаем итоговую конфигурацию, выгружаем ее, и дальше уже выполняется стандартная работа по перемещению доработок в хранилище.

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

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

• У него есть фильтр по автору ошибки – это работает, когда SonarQube используется в связке с Git.

• У него есть большое количество проверок – там есть проверки как на сам код, так и на восприятие (когнитивная и цикломатическая сложность)

• И в SonarQube достаточно удобный просмотр замечаний – они выполнены в виде карусельки.

Виталий: Выглядит это так как на слайде. У нас есть проект SonarQube. В левом нижнем углу выделен блок с отбором по автору, который выводит в основную область мои косяки.

Виталий: Когда мы уже попадаем в само замечание, мы видим код с подсветкой синтаксиса, где можно оценить, какие ошибки у нас были допущены.

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

Разработка в 1С:EDT. Плагины

Виталий: Теперь хочу поделиться опытом разработки непосредственно в EDT:

• Первое – наша команда для проверок внутри EDT использует проект v8-code-style, который встроен в EDT, начиная с версии 2021.2 и выше. Плюс v8-code-style в том, что он проверяет соответствие стандартам не только кода, но и еще метаданных.

• Второй плагин, который мы используем активно, это 1C:SSL – он хорошо помогает при работе с БСП.

• Мы отказались от «Коннектора BSLLS для 1С:EDT», потому что он достаточно сильно тормозил систему и не всегда адекватно реагировал на исправление. Джунов это иногда вводило ступор – они бежали, спрашивали: «Что у меня произошло? Я ошибку исправил, она не исправляется». Смотрю – действительно, ошибка исправлена, но все равно помечено, что осталась.

• И четвертый плагин – Open Editors. Он хорошо помогает, когда есть много открытых вкладок.

Владислав: Мы используем те же самые плагины. За исключением того, что у нас в отделе пока что пользуется спросом «Коннектор BSLLS для EDT», и на v8-code-style мы не перешли – но это на самом деле вопрос времени.

Также я пробовал использовать разные плагины для работы с GitLab, чтобы можно было внутри EDT автоматически проводить мерж-реквесты и не переходить при этом в отдельное приложение – не запускать ради проверки браузер. Но подходящего плагина пока что под себя не нашел и возможно в будущем уже сам напишу для себя плагин, при помощи которого можно будет выполнять мерж-реквесты внутри EDT.

Боли использования 1С:EDT

Виталий: Теперь про сам опыт.

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

• каталог программной среды;

• каталог с локальными репозиториями;

• и workspace.

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

Владислав: А второе – это то, что при работе с EDT могут происходить ошибки, которые вообще не очевидны.

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

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

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

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

Владислав: Третий пункт – это добавить в конфигурацию Git параметры, которые предоставлены на слайде.

Немного о самих параметрах.

• Первый – это core.quotePath в значении false. Он нужен, если используется команда Git, которая выводит какие-то пути, где используется кириллица. В мире 1С кириллица используется почти всегда, а Git по умолчанию преобразует символы кириллицы в нечитаемый вид.

• Следующий параметр – это core.autocrlf в значении true. Очень помогает, если есть разработчики на разных операционных системах. Этот параметр преобразует все окончания строк в единый вид.

• Следующий параметр – это core.safecrlf в значении true. Он работает в связке с параметром core.autocrlf и выполняет отмену. Когда у Git не получается выполнить преобразование окончаний строк, он делает откат.

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

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

Еще из общих моментов хочу сказать, что в EDT:

• пока достаточно тяжело работать с макетами табличных данных;

• и достаточно тяжелая отладка при больших конфигурациях.

Вопросы

В каком интерфейсе разработчик делает запрос на мерж-реквест? В GitLab заходит?

Владислав: Да, заходит в GitLab.

И ответственный за мерж-реквест выполняет это код-ревью тоже в интерфейсе GitLab?

Владислав: У нас это можно трекать либо в задаче Jira, либо он проводит код-ревью в интерфейсе GitLab.

А не было идеи, чтобы все это было в Jira – чтобы в Jira можно было и запрос сделать, и получить задачу на выполнение?

Владислав: Идеи были. Но мы сейчас с Jira работаем как с экспериментальным продуктом, потому что все равно пользуемся СППР. Нам удобно дорабатывать СППР под свои нужды при необходимости.

А Jira для нас пока – не обследованный до конца объект, мы там пока что нарабатываем опыт и улучшаем процессы. Возможно, позже, как вариант, реализуем.

Поделитесь опытом, как много времени нужно, чтобы перевести разработку из конфигуратора на EDT? В масштабе одного разработчика.

Владислав: Я не буду говорить о масштабе одного разработчика. У нас все же целая команда, и если мы переходим, то все.

В нашей команде мы разрабатываем облачный продукт, и я его смог перевести на EDT полностью за две недели. В это входил импорт исходников из хранилища в Git с помощью 1С:ГитКонвертер.

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

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

Мы занимаемся проектами, и у нас, как правило, разработка идет на среде заказчика – мы разрабатываем чисто в хранилищах. Что можно предложить заказчику, чтобы мы на его среде разрабатывали с использованием CI/CD-технологий?

Виталий: Тут можно использовать переходную схему работы EDT, когда хранилища остаются, а 1С:ГитКонвертер конвертирует хранилища в Git. Тогда и заказчик остается со своими хранилищами, и вы организуете CI/CD на основе исходников в Git.

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

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