EDT и полный стек CI/CD

Я работаю с 1С уже около 15 лет. Участвовал в проектах для разных отраслей, на разных ролях. И всегда стараюсь изучать все новое.

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

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

Я представляю компанию «Финтех Решения», мы находимся в Северодвинске. Вся наша команда фактически распределенная – в частности, я живу в Калининграде, а так у нас вплоть до Читы и даже дальше команда работает.

Сегодня расскажу о том, что мы сделали, чтобы научить Jenkins работать с EDT. В том числе покажу, как у нас выглядит итоговый пайплайн Jenkins.

Как мы работаем сейчас

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

• Jenkins

• SonarQube

• плагины SonarQube – у нас оба плагина (и от Серебряной пули, и от сообщества 1C-Syntax)

• GitLab

• Jira

• журналы регистрации и технологические журналы мы перегоняем в Greylog и смотрим все это в Grafana

• сбоку к этому еще прикручен мониторинг с помощью Zabbix, но это уже чисто админские фишки

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

Основная разработка у нас сейчас ведется с использованием трех хранилищ – develop, prerelease и release.

• Develop – это когда мы кидаем все задачки в кучу.

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

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

Грубо говоря, в develop валится все, в предрелизе – чистый код. А в хранилище release каждая версия – это новый релиз.

Как при этом не сойти с ума? У нас достаточно большая команда, порядка 40 разработчиков. Если все кидать в develop, то как потом найти код, который ты закидывал? Нам в этом помогают:

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

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

• И третий пункт – собственные средства автоматизации. У нас есть небольшая утилита на OneScript, которая собирает все измененные объекты по номеру задачи. Разработчик пишет номер задачи, пишет хранилище, из которого нужно собрать изменения, а эта утилита выводит список объектов, захватывает их целевым образом в хранилище предрелиза и открывает в хранилище разработчика окно сравнения и объединения текущего состояния и выбранной версии. Разработчику это здорово облегчает задачу, ему не нужно вспоминать, что же он в рамках задачи менял. Это особенно актуально для долгоиграющих задач. И при переносе из предрелиза в релиз аналогично – работает эта же самая утилита, только у нее в качестве параметра передается уже не номер задачи, а номер релиза в Jira. Но собирает она то же самое. Это здорово нам помогает.

Порог качества SonarQube (качество кода + покрытие), как критерий принятия кода

И рядышком у нас еще крутится SonarQube.

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

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

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

• В релиз у нас идет только чистый новый код без замечаний вообще. Мы все замечания убираем.

По поводу правил – мы используем практически все правила, которые поставляются для 1С в SonarQube (и в коммерческом плагине, и в комьюнити-плагине). Какие-то совсем нерелевантные к нам правила мы исключаем. Таких правил немного – это единичные исключения. В основном, мы работаем на полном наборе правил.

Вот так у нас выглядит текущее состояние проекта в SonarQube в ветке разработки. Три новых ошибки за 21 день. И 127 дефектов кода. Это при размере проекта почти 800 тысяч строк в коде.

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

Но новые дефекты мы стараемся не генерить. Все эти замечания за 21 день – они переходящие, там нет ничего серьезного.

Разработка по гитфлоу с изолированием задач

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

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

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

• У нас есть даже ревью в бизнес-процессе – я его чуть позже покажу.

Но полноценно сделать гитфлоу можно только в рамках EDT.

Гитфлоу – это не просто какая-то волшебная технология, нам от гитфлоу нужны конкретные пять требований.

• Конечно же, это изоляция кода в рамках задачи.

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

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

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

• И следующий вопрос – перенос изменений между любым количеством веток. Сейчас у нас фактически используется три ветки – develop, prerelease, release. Но в будущем, возможно, появится больше веток, потому что у нас есть отдельные продукты, которые даже в рамках конфигурации имеют отличия друг от друга.

На слайде показан наш текущий процесс, как он выглядит в Jira. Мы видим, что здесь есть:

• отдельно – кодревью;

• отдельно – подготовка релиза (тот самый перенос в предрелиз);

• когда задача готова, все перенесено, выставляется признак «Релиз подготовлен»;

• а предыдущая проверка, доработка – это обычная работа разработчика.

Вот так у нас сейчас выглядят ветки в продукте, который разрабатывается в EDT.

Две основные ветки – master и develop – и четыре дополнительные ветки,

• Две из них сейчас активны, в них задачки решаются.

• Одна ветка уже замержена, но не удалена.

• И на последней ветке в группе stale branches мы сейчас пытаемся сделать покрытие, затащить его в Jenkins и посчитать.

Анализ качества кода

При работе с EDT у нас есть:

• работа с SonarQube;

• кроме того, EDT само внутри себя имеет кучу проверок по качеству кода;

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

Сейчас я покажу, как это все у нас работает.

Вот так выглядит чистое прохождение мерж-реквеста при проверке SonarQube.

Наверняка вам уже знакомо такое окно, если вы раньше видели SonarQube.

Вот так выглядит ошибка прохождения порога качества – я ее сгенерировал специально.

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

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

Вот так выглядит сейчас у нас история мерж-реквестов в SonarQube. Такая вот красота.

И как это выглядит в EDT? В EDT у нас есть несколько механизмов проверок.

• Есть встроенные механизмы проверок, которые помечены на слайде красным подчеркиванием. Это сообщение: «Отделите знак пунктуации пробелом». EDT так реагирует на опечатку, он говорит: «Поставьте пробел».

• Есть замечательная связка с SonarLint. Она пока в бете, но ей тоже можно пользоваться – прямо из SonarQube сюда затягиваются ошибки.

• Есть еще плагин от Александра Капралова. Он в свое время написал замечательный плагин, который дотаскивал ошибки из BSL Language Server в EDT. Сейчас в подготовке следующая версия плагина, мы очень планируем на него перейти, как только он появится в более-менее стабильном виде.

Написание тестов

Отдельный вопрос – написание тестов.

При разработке в конфигураторе мы пишем тесты с помощью различных фреймворков – для ADD и BDD. Все это работает. Но делать это правильно и красиво не получается. Постоянно приходится делать это с какой-то болью.

Причем ни в конфигураторе, ни в EDT встроенной функциональности для запуска тестов нет. Но опять же, в EDT есть замечательный плагин написания модульных тестов от Александра Капралова. Он решает как минимум две задачи:

• Первая – это написание тестов и их прогон.

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

Мы для себя установили определенный порядок написания тестов в EDT:

• Создаем расширение.

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

• Огромный плюс написания тестов с помощью плагина Александра – это то, что тесты пишутся внутри EDT на родном всем нам языке 1С:Предприятие. То есть замечательные языки Gherkin и прочие учить не надо. Вы пишите так, как привыкли работать внутри 1С. Ничего не меняется. Есть просто технология написания тестов – т.е. к тесту есть требования, и вы их реализуете.

• После того как тесты написаны, не нужно ждать, пока Jenkins отработает или еще что-то. Можно тут же самому их запустить и проверить.

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

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

У нас есть отдельные общие модули с тестами на каждую функциональную подсистему. Есть даже небольшой тест на подсистему «Дополнительные отчеты и обработки», потому что мы вносили в нее небольшое исправление.

Вот так этот отдельный общий модуль выглядит в целом – это прямо целиком модуль тестирования подсистемы «Дополнительные отчеты и обработки». Тут есть тест на добавление команды и другие.

Основной ключ, который нужно написать для теста – это указать для него аннотацию @unit-test. Здесь – вся магия для программиста.

Вот такой код у нас внутри теста. Как видим, ничего сложного нет. Единственный нюанс – это условия: // Дано, // Когда и // Тогда

• Секция // Когда – это именно проверка того, что есть.

• Секция // Дано – это формирование контекста

• И секция // Тогда – собственно вызов того, что мы хотим проверить.

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

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

В реальности, конечно, времени уйдет побольше – пока запустится 1С, пока загрузятся описания тестов. Но само тестирование заняло две секунды. Конечно, чем больше тестов, тем больше будет времени.

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

• Мы увидим, что у нас случилось.

• Увидим, где у нас это вызывается, в каком тесте это случилось.

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

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

Вот таким образом у нас это работает.

Покрытие кода тестами

Следующий момент, который по-любому у вас возникнет, если вы начнете писать тесты: сколько тестов писать?

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

В EDT нет встроенных средств, чтобы показывать покрытие тестами, но они есть в Eclipse, на которой написано EDT. И опять же, плагин Александра Капралова, который позволяет писать юнит-тесты, он же и позволяет показывать покрытие тестами средствами Eclipse.

Буквально вот в один клик – запускаем тесты, получаем и результаты работы тестов (предыдущее окно), и вот такое окно. Я его взял у Александра из примеров, но у нас выглядит точно так же.

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

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

• Первое условие «Если РезультатТеста» выполнилось полностью и покрыто, код зашел внутрь. Когда условие покрыто, оно горит зелененьким.

• Условие «Если ИмяСобытия» не покрыто тестом – оно горит красненьким.

• И следующее «Иначе» горит.

Вы видите полностью – что у вас выполнилось, что не выполнилось, какие условия.

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

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

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

Тот же SonarQube предлагает в качестве метрики 80%,

• Мы понимаем, что 100% – недостижимый идеал и совсем хорошо.

• 90% – замечательно, прекрасно и огонь.

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

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

• Это собственно проверка кода средствами EDT и SonarQube. Сейчас, наверное, будем отказываться в пайплайне от встроенной проверки EDT – смысла нет, SonarQube достаточно плотно покрывает. Раньше в коммерческом плагине от «Серебряной пули» проверка формата EDT не поддерживалась. Сейчас начала поддерживаться. Поэтому мы, наверное, выпилим проверку средствами EDT, а будем полагаться на SonarQube и работу внутри.

• Затем сборка конфигурации и расширения для тестов.

• Непосредственный прогон тестов.

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

Вот так выглядит пайплайн. Он достаточно длинный, но основное, что у нас работает, это:

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

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

Сейчас мы хотим немного поменять – у нас SonarQube будет последним шагом перед формированием файла поставки и сборки дистрибутива.

Для понимания количества: у нас сейчас на достаточно небольшой конфигурации имеется уже порядка 50 с лишним тестов. Я чуть позже покажу – они покрывают порядка четверти всего кода.

Добавление номера сборки в релизный cf

Отдельно у нас стоял вопрос сборки и номера релиза. Одним из требований, которые мы предъявляли к EDT и работе – это то, что каждый прогон задания Jenkins должен формировать уникальный CF-ник.

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

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

Этот номер сборки проставляется системой CI – в данном случае Jenkins – непосредственно при сборке. Мы меняем номер версии внутри файла configuration.mdo небольшой регуляркой. После этого запускается сборка, и всегда в итоге у нас имеется уникальный CF-ник с уникальной версией.

Вот так это выглядит.

• На первом скриншоте видно, как выглядит номер версии внутри EDT (в конфигураторе то же самое).

• Ниже – кусочек, написанный на groovy, который меняет номер сборки внутри пайплайна. Наверное, для большего понимания все-таки лучше этот кусочек переписать на OneScript, но пока он у нас работает так. Будет совсем хорошо, если эту часть вынесут в ring – реализуют команду ring edt set version. Если добавят либо сделают возможность добавления этого непосредственно внутри EDT каким-то образом, вообще будет огонь. Но это, наверное, из пожеланий.

• Внизу в «Branch master» видим, что был собран артефакт для ветки master. Всегда идет такой номер сборки – сейчас у нас версия 1.0.10.24.

• И справа на черном фоне видно, как проставляется текущий номер при коммите. Теги мы пока пишем вручную, тег непосредственно в GitLab не проставляется. Мы видим, что номер сборки начинается с версии 1.0.1.1, потом мы запустили 1.0.2.1, 1.0.3.2, 1.0.4.4, 1.0.5.5, потом 1.0.5.6. То есть у нас пока не было необходимости сбрасывать номер сборки, поэтому они возрастают последовательно. Фактически номер релиза – это номер сборки. А номер релиза отвечает за наличие новой функциональности. Т.е. если вы посмотрите релиз 1.0.8, то увидите, что у него было три исправительных сборки – формирование релиза и два баг-фикса, в которых мы что-то чинили.

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

Планы

В ближайших планах:

• реализовать покрытие кода тестами в рамках CI/CD;

• вынести все три направления: проверка кода, прохождение тестов и результаты покрытия – в SonarQube;

• и использовать порог качества SonarQube как интегральный показатель успешности сборки.

Сейчас тестовая ветка feature-coverage у нас покрыта кодом на 25%. Причем это покрытие всего проекта (не нового). Мы от всего проекта уже покрыли четверть, хотя только недавно начали его разрабатывать и писать к нему тесты.

Вопросы

Проверка коммита в конфигурации на 800 тысяч строк у вас занимает 25 минут. Это полная проверка или частичная?

Это полная проверка платформенной выгрузки CF-ника средствами SonarQube.

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

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

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

Статья написана по итогам доклада (видео), прочитанного на митапе «1C:EDT Опыт использования».