Назад
Как показывает опыт, многие компании (в том числе крупные) традиционно ведут разработку с использованием хранилища, планируя при этом внедрение современных инструментов, исходя их того, что «другие же внедряют, все об этом говорят и нужно не отставать». То есть хотят внедрять, потому что «это модно и наверняка будет полезно».
Однако, на наш взгляд, внедрение ради внедрения не принесет ожидаемого результата. Необходимо, прежде всего, четко понимать, какие задачи будут решать внедряемые практики и их ценность не только для команды, но и для бизнеса в целом.
Именно об этих аспектах и пойдет речь в этой статья. Надеемся, она будет интересна компаниям, планирующим внедрение современных инструментов и практик в разработке 1С.
Поговорим о плюсах, которые несет Git для команды (даже при отсутствии разнообразных конвейеров) сразу после установки в базовой версии, например, в составе EDT.
1. Уменьшается конкуренция за объекты метаданных, являющихся «узким метом»
Известно, что, если в конфигурации есть объекты метаданных, то за них при работе с хранилищем конкурируют разработчики. Внедрение Git позволяет значительно снизить эту конкуренцию.
Давайте рассмотрим подробнее. Узкими местами могут являться, например, общие модули на десятки тысяч строк. Причины появления подобных модулей и архитектурные предпосылки их возникновения — отдельный вопрос, однако на практике такие модули часто встречаются во многих legacy-конфигурациях присутствуют, могут выглядеть примерно так – ОсновныеПроцессыСервер, где собраны методы на все случаи жизни.
Обычно изменения в таких модулях происходят каждый релиз, что сопровождается появлением очереди из разработчиков, желающих захватить этот модуль для внесения изменений.
Git позволяет такие конфликты (именно в коде) решать в большинстве случаев автоматически: если изменения внесены, например, в разных концах модуля далеко друг от друга, то ошибок слияния не будет. Таким образом, скорость внесения изменений в репозиторий повышается, что в целом благоприятно влияет на процесс разработки.
2. Пулреквесты (запросы на помещение кода в прод)
Пулреквест (или мержреквест) – это (в терминологии Git) запрос на помещение кода в рабочий репозиторий. Отметим, то при стандартной работе с хранилищем этот этап отсутствует, поскольку разработчик просто помещает свои изменения, указав текстовый комментарий. При этом не предусмотрено никакой проверки, обсуждения кода и т.д.
В Git эти возможности доступны сразу «из коробки». При настройке определенных параметров репозитория изменения разработчиков нельзя поместить в master-ветку (аналог рабочего хранилища) напрямую без пулреквеста, который, в свою очередь, обязательно проверяется и акцептируется (в терминах Git «апрув») старшими разработчиками, у которых на это есть права.
В пулреквесте четко видны все изменения, вносимые разработчиком по своей задаче:
Пулреквест – это инструмент, который в базе позволяет запустить важнейший для качества кода процесс – ревью. И ничего удобнее пулреквестов для проведения ревью на текущий момент нет.
3. Гибкий поиск изменений в коде
Git позволяет выполнять гибкий поиск по репозиторию: по номеру задачи (ветки) или по строке кода, причем он в отличие от глобального поиска в конфигураторе работает очень быстро. Git дает увидеть историю изменений любого файла, даже любой строчки кода: когда, кем, по какой задаче (ветке). Такие возможности поиска помогают не только разработчикам, но и аналитикам в оперативном определении ошибок.
1. Пулреквесты
В связке с конвейерами функционал пулреквестов становится еще более полезным – к ним можно присоединить различные проверки:
2. Интеграция статуса задачи с трекерами и мессенджерами
С помощью devops-инструментов можно настроить связь ветки (которая в большинстве случаев представляет задачу на разработку) Git и задачи в трекере. В этом случае появляется возможность отслеживать статус разработки по задаче в трекере, не задавая лишних вопросов разработчику. Аналитику, который ожидает от разработчика выполнение задачи, теперь не требуется узнавать у разработчика на каком тот этапе, поскольку все теперь видно из задач, например:
Если у команды есть определенные рабочие мессенджеры для коммуникации по процессу разработки, то можно гибким образом настроить уведомления об изменении статуса пулреквестов/веток. Например, аналитику может быть полезно узнать о том, что некая задача, которую он должен проверить, разработчиком завершена.
Может показаться, что Git нужен всем и каждому, раз о нем так много говорят. Но применительно к миру 1С, можно выделить некоторые случаи, когда внедрение Git может принести и некоторые неудобства.
1. С конфигурацией работает много разработчиков
В этом случае повышается конкуренция за объекты метаданных, увеличивается время простоя разработчиков, которые ожидают освобождения объектов. Повышается количество конфликтов в программных модулях, когда разработчикам приходится вручную соединять изменения в коде. Если в конфигурации есть «узкие места», то конкуренция разработчиков при работе с хранилищем усугубляется.
2. Есть необходимость в полноценном CI/CD контуре
Если в ИТ-отделе встречаются следующие факторы:
то внедрение CI/CD конвейеров, скорее всего, значительно облегчит работу ИТ-команды. А организовать CI/CD конвейер проще, имея Git-репозиторий, потому что большая часть написанных уже devops-скриптов в сообществе 1С предполагает работу именно с Git-репозиторием.
Конечно, необходимость внедрения CI/CD может быть обусловлена и желанием команды внедрять современные процессы в разработке, улучшать контроль за этим процессом.
1. Много изменений в основной конфигурации
Часто бывает, что ИТ-отдел унаследовал на поддержку типовую конфигурацию с большим количеством модификаций (причем непосредственно в основной конфигурации, а также в свойствах метаданных, например, когда типовые формы изменены напрямую, не программно.
Git довольно хорошо умеет решать конфликты кода в программных модулях, но конфликты в файлах репозитория, описывающих объекты метаданных, Git-у позволять решать нельзя, иначе конфигурация может потом даже «не собраться». Если сильно кастомизированная типовая форма доработана программно, то с ней может работать одновременно много разработчиков. С большой вероятностью Git правильно разрулит конфликты их кода автоматически; но, если все изменения выполняются непосредственно на форме, то в любом случае работа с формой должна быть организована последовательно. Git никаких преимуществ не даст. Более того, если мы используем не EDT, который бы отобразил изменения в форме аналогично хранилищу, а некий самописный конвейер по работе с Git, то процесс будет значительно дольше.
2. Большой репозиторий
Конвейеры CI/CD и EDT довольно быстро работают с небольшими репозиториями, и, наоборот, все становится сильно дольше, если в репозитории лежит полностью большая конфигурация, такая как ERP. Конечно, нельзя сказать, что мы не можем поместить в репозиторий всю конфигурацию ERP. Можем, но требования к ресурсам машин разработчиков, работающих на EDT, времени работы CI/CD-пайплайнов (автоматизированных цепочек сборки, проверки и доставки изменений) существенно возрастают.
Мы кратко обсудили плюсы использования Git применительно к разработке на 1С. Теперь давайте рассмотрим варианты выбора среды разработки, которые позволяют использовать Git.
1. Конфигуратор+хранилище+Git (сбоку)
Данный вариант является самым простым и безопасным, если мы хотим минимальными усилиями начать использовать некоторые преимущества Git, не меняя основной процесс разработки (с хранилищем). Существуют утилиты (gitsync или 1С:ГитКонвертер), которые позволяют автоматически заливать изменения, помещенные в хранилище, в репозиторий Git.
В этом случае команда разработки продолжает работать как она привыкла, процессы не меняются. Но появляется возможность постепенно знакомиться с плюсами Git без каких-либо рисков «сломать процесс».
К сожалению, есть и минусы – изменения будут попадать в репозиторий напрямую в ветку master, без использования механики пулреквестов.
2. EDT + Git
EDT содержит довольно много полезных для разработчика инструментов: например, для отладки или обновления конфигурации. Кроме того, EDT содержит встроенный Git-клиент.
EDT удобен при работе с небольшими конфигурациями. В этом случае не так заметна его требовательность к аппаратным ресурсам, долгий цикл развертывания проекта. Кроме того, если процесс разработки похож на продуктовую разработку, т.е. когда день за днем разработчик работает с одним и тем же проектом, то работа с EDT будет вполне комфортна.
Но если разработчику приходится часто разворачивать различные окружения для отладки и поиска/исправления ошибок, решать интеграционные задачи и т.д., если конфигурация большая, то в этом случае работа с EDT может вызвать трудности, так как любое действие будет занимать длительное время.
Также необходимо отметить, что, к сожалению, работа в EDT не отличается высокой стабильностью даже на текущий момент: время от времени, судя по отзывам клиентов, «ломаться» могут даже стандартные и выверенные действия, которые в конфигураторе не вызвали бы никаких трудностей.
3. Конфигуратор+Git (+ EDT)
С помощью devops-инструментов можно решить задачу извлечения изменений из конфигурации, которая дорабатывается в конфигураторе, и помещения их в Git-репозиторий. В данном случае разработчик может работать над задачей в привычном ему режиме с конфигуратором, а когда работа выполнена – вызывать определенную команду CI/CD контура, которая сделает все «за него» сама: получит изменения, сравнит их с master, поместит их в определенную ветку (по задаче), создаст пулреквест, может быть даже сразу выполнит некоторые проверки качества кода.
Если выбран формат файлов репозитория EDT, то дополнительно здесь же мы можем использовать в том числе и EDT при работе с одним и тем же репозиторием, просто devops-скриптам придется в некоторых случаях выполнять конвертацию файлов из формата конфигуратора в формат EDT. Таким образом, такая среда является наиболее универсальной и позволяет командам удовлетворить как амбициозных молодых специалистов, которые хотят работать в EDT, так и разработчиков со стажем, которые, обычно, не стремятся менять проверенный временем конфигуратор на что-то другое.
Такую среду довольно сложно внедрить: без серьезного вовлечения devops-специалистов не обойтись.
Как показывает опыт, к сожалению, для многих команд плюсы использования практики «ревью» в разработке не очевидны. Этот процесс воспринимается как инструмент контроля разработчиков друг за другом (но это лишь отчасти так). Более того, многие считают, что ревью и SonarQube – это где-то рядом или почти одно и тоже. Поэтому давайте разберем плюсы ревью кода: некоторые из них не столь очевидны.
Плюсы ревью:
1. Существенно повышается качество кода
При ревью разработчики выявляют в коде проблемы совершенно другого уровня, чем при использовании статического анализа кода (SonarQube). Если ревью выполняет разработчик высокого уровня – а именно таких и наделяют данной ролью обычно – он замечает проблемы иного порядка: архитектурные и функциональные.
2. Повышается уровень разработки всей команды
Код-ревью всегда сопровождается обсуждением кода — будь то комментарии в pull request’е или разговор на созвоне. В этом процессе разработчики объясняют свои решения и аргументируют выбранные подходы, и в результате почти всегда происходит обмен знаниями. Кто-то узнаёт новое и повышает свою квалификацию.
Важно, что учится не только автор кода. Нередко ревьюер, задав вопрос из-за непонимания реализации, получает ответ, который открывает для него новый аспект разработки. Именно поэтому код-ревью — это не просто проверка, а двусторонний процесс обучения и профессионального роста.
3. Повышается осведомленность команды об архитектуре проекта
Как многие знают, одно из основных правил написания «чистого кода» гласит: do not repeat yourself – не следует в нескольких местах писать код, который делает примерно одно и тоже – потому что в случае изменений по процессу, правки придется вносить не в одно место, а во многие. Но на практике каждый разработчик зачастую работает со своими функциональными блоками: определенными объектами метаданных и программными модулями. Он не знает, какой код и где пишут его коллеги, он этим не интересуется. Если ему для решения своей задачи требуется написать некий запрос или простую функцию, которая получает определенные данные, то он просто напишет новый метод и не будет искать существующие методы других разработчиков, которые можно использовать.
Ревью повышает осведомленность разработчиков о программном интерфейсе модулей и библиотеках коллег. Да, вероятно, потребуется сделать имеющийся метод более универсальными и параметризуемым, но это более правильный путь с точки зрения последующей масштабируемости и поддержки конфигурации, нежели заниматься дублированием.
4. Улучшается архитектура решений
Знать все, конечно, невозможно – даже опытнейшие программисты постоянно открывают для себя что-то новое: неиспользуемые ранее методы БСП или свежие приемы дизайна кода, которые его коллега успел подсмотреть в новом релизе типовой. Ревью дает возможность коллегам делиться новшествами по архитектуре и дизайну кода, подсказывать коллегам, как можно ту или иную задачу решить проще и быстрее. Таким образом вся команда в курсе лучше практик, архитектура решения сильно выигрывает.
5. Развитие культуры решений
В наше время команды разработки в основном распределенные. Гибридный формат, когда часть специалистов работает в офисе, а часть удаленно – это тоже распределенная команда, им все равно приходится коммуницировать в электронном формате. При этом уровень коммуникаций, к сожалению, может быть на низком уровне. Но команды должны быть эффективными, ведь от этого зависят архитектурные решения и работоспособность системы. Если коллеги не могут общаться и решать вопросы – страдать будет система.
Ревью заставляет технических специалистов общаться кратно больше и учиться четко формулировать свои мысли, вести аргументированное обсуждение, что отражается и на остальных деловых коммуникациях в целом. Если тимлид контролирует процесс и направляет коллег в русло эффективной деловой беседы, то результат будет намного выше.
6. Снижается зависимость команды от ключевых разработчиков
Зачастую определенные разработчики с высокими компетенциями замыкают на себе поддержку и модификацию определенных функциональных блоков. До некоторого времени это кажется очень удобным – у нас есть единая точка входа и спроса по некоторым процессам. Но когда такой чудо-сотрудник решает уволиться… внезапно оказывается, что «передать» функциональные блоки за пару недель попросту невозможно.
Ревью заставляет разработчиков хотя бы поверхностно интересоваться функциональными блоками своих коллег, запоминать, какие использованы в них объекты метаданных и программные модули, с какими сложностями встречался автор и как их решал. Конечно, не до деталей, но бэкграунд будет. При ревью естественным образом члены команды в курсе работы друг друга, и, если один из членов ее покидает, другим легче подхватить его блоки.
7. Неизбежно вырабатывается устраивающий всю команду дизайн кода
У каждого мидла и выше, как правило, есть свое представление о том, как должен выглядеть идеальный код. Зачастую, образ идеального форматирования кода конкретного разработчика не обоснован никакими аргументами: просто у него такое чувство прекрасного – например, не использовать отступы строк и писать весь код единым блоком или именовать все таблицы в запросах «Т1» и «Т2». Наверное, в каждой команде встречается такой. При этом разработчик весьма квалифицированный и противоречить ему рискнет не каждый коллега. Но и иметь дело с его кодом тоже не хочет никто. Такие случаи – отдельный фактор закрепления функциональных блоков за конкретными программистами, потому что внутри его блоков код выглядит так, как ему нравится. Понятно,что с точки зрения управления командой эта ситуация плохая.
Ревью неизбежно заставит разработчиков выработать единый подход к дизайну кода. Да, они будут спорить, но, если не оставлять этот процесс на самотек, а возглавить и помочь достичь соглашения, то будет выработан и зафиксирован тот стиль, который устраивает большинство разработчиков в команде, и никто не будет избегать работы с кодом, который не нравится визуально.
8. "Могу писать качественный код, но мне лень"
Зачастую среди разработчиков встречается парадокс – ведущий программист, опыт и компетенции которого не вызывают никаких вопросов, пишет кривой код. Причины могут быть разные:
Ревью поможет в решении такой проблемы. Если процесс организован публично – например, в Git, когда все пулреквесты команды находятся «на виду», к обсуждению кода на ревью привлекаются многие члены команды, периодически устраиваются митапы по наиболее часто встречаемым в коде проблемам – в этом случае каждый разработчик будет стараться писать код «красиво» сразу. Далеко не факт, что его код будут изучать под микроскопом при проведении ревью, но технически такая возможность есть – при возникновении определенных обстоятельств его код может увидеть и обсудить вся команда вместе с тимлидом. И, просто понимая это, имея такое обстоятельство в голове, разработчик высокого уровня просто не позволит себе писать плохой код – ведь это может стать достоянием общественности/
Если ревью, не часть процесса, а опция «по желанию» конкретных перфекционистов в команде, работать ревью не будет. Давайте подумаем над теми факторами, которые помогут этой практике стать по-настоящему эффективной частью процесса.
1. Инструментарий
Процесс ревью должен быть удобным. Нельзя назвать удобным процесс ревью, когда один разработчик зовет другого в офисе посмотреть его код, показывая конфигуратор. И управлять таким процессом тоже непонятно как. На текущий момент единственным работающим по-настоящему инструментом являются пулреквесты Git, где можно комментировать как код, так и свойства метаданных – вообще все, что изменяется в конфигурации при разработке по задаче. Можно привлекать к обсуждению других членов команды в спорных ситуациях, можно делиться ссылками на строки кода в рабочем мессенджере. Используя современный мессенджер, можно распределить коммуникации команды разработки по каналам и тредам, сделав процесс публичным и прозрачным, что позволит постепенно сделать процесс обсуждения кода по-настоящему командным, эффективным и даже интересным (Git и Slack (или аналог) в каком-то роде заменяют разработчикам социальную сеть).
2. Обязательность ревью
Если инструментарий позволяет сделать ревью удобным образом, то ревью должен стать обязательным, частью процесса разработки. Только в этом случае от практики будет эффект. Любой разработчик технически не должен иметь возможность поместить код в master, не получив апрув от коллеги. И именно Git предоставляет такую опцию «из коробки».
3. Проведение организационных мероприятия с командой
Для того, чтобы ревью не воспринимался лишь как инструмент контроля, который мешает разработчикам делать свое дело, необходимо организовывать периодические встречи с командой, на которых следует рассказывать о причинах внедрения данной практики, о пользе, которую она несет не только для качества кода, но и для каждого разработчика в частности. Необходимо заранее поработать с возражениями.
Но и после успешного запуска ревью оставлять разработчиков наедине друг с другом нельзя. Необходимо следить за этим процессом, за качеством коммуникации разработчиков: какие вопросы и требования звучат, как аргументируются.
Со временем команда друг к другу «притрется», каждый поймет кто на что обращает внимание на ревью, какие аргументы хочет услышать и т.д., и процесс пойдет быстро и без конфликтов.
4. Ответственность за ревью
Если уровень разработчиков в команде высокий, то ревью может выполнять любой разработчик. Но желательно назначать на эту роль члена команды, который либо знаком с дорабатываемым функционалом, либо с технической областью. Если уровень разработчиков низкий, то выполнять ревью могут либо ведущие разработчики, либо тимлид. Но в любом случае ответственный за ревью, должен зафиксировать факт проведения ревью и его итоги. Если в прод попадет плохой с архитектурной или иной точки зрения код, то вопросы будут адресованы не только основному разработчику, но и ответственному за проверку.
Git и механизм пулреквестов предоставляют возможность «из коробки» указать в качестве ревьювера назначенных разработчиков, а они, в свою очередь, могут поставить флаг Approve, обозначающий проверку кода. Сохранение этой отметки в истории репозитория позволит проследить все шаги работы по коду и их приемку.
Когда за проведение ревью появляется ответственность, когда есть прозрачная техническая возможность найти ответственного за проблемный код, именно тогда процесс ревью перестает быть фиктивным.
5. Наличие статического анализа кода в дополнение
Статический анализ кода, который имеет возможность «прикручиваться» к проверяемому по задаче коду, существенно облегчает задачу проведения ревью. Разработчик в этом случае сначала отрабатывает «косметические» замечания SonarQube и лишь затем приглашает для ревью ведущего разработчика.
Хотелось бы отметить, что, как показывает практика, много времени тратится на ревью только в самом начале внедрения этого процесса. Когда члены команды «притерлись» друг к другу, поняли частые требования по модификации и выверили эффективный способ обсуждения кода, прошли ревью (и выполнили сами) по 10 раз, после этого процесс значительно ускоряется. Ревью многих задач можно провести буквально за минуты. Задачи, ревью которых можно выполнять в течение часа, довольно редки. Обычно такие задачи реализовываются несколько недель, и в этом случае время, потраченное на ревью, будет занимать не больше 5% от трудозатрат на их реализацию.
Давайте подведем итог. Да, ревью занимает время. Но если процесс выстроен грамотно, то это время незначительное. Существенное время ревью может занимать в том случае, когда его выполняет кто-то один за всей остальной командой. Но, как показывает практика, эти затраты окупаются многократно в дальнейшем при эксплуатации и сопровождении разработанного кода, который будет иметь существенно больший потенциал к масштабированию в сравнении с отсутствием ревью.
Многие воспринимают статический анализ кода как источник «избыточных» проверок, мешающий командам и разработчикам делать свою работу, и как инструмент контроля. Это лишь отчасти инструмент контроля, он приносит много пользы и самим разработчикам – если использовать его вдумчиво. Разберем плюсы статического анализа кода на примере SonarQube.
1. Снимается нагрузка с разработчиков при ревью
Чтобы ревью проходил существенно быстрее, чтобы ведущие разработчики не тратили время на написание комментариев по оформлению кода и прочим мелочам, перед ревью лучше проходить проверку с помощью SonarQube
2. Не нужно спорить о максимальной длине строки в 120 символов
Зачастую в командах присутствуют вечные споры о простых правилах дизайна кода, которые нельзя определить однозначно. Имея SonarQube с возможностью влиять на состав проверок, мы получаем дополнительно зафиксированный свод правил для команды о том, как должен оформляться тот или иной аспект в коде, разработчикам больше не требуется об этом спорить.
3. Технический долг накапливается в разрезе проектов и программистов
SonarQube предоставляет возможность проверять не только код по текущей задаче «в моменте», но также и накапливать технический долг в разрезе программистов и проектов. Это позволяет тимлидам оценивать работу разработчиков на длинных отрезках времени. Ошибки дифференцируются по критичности: bugs, smells.
Появляются дополнительные маркеры оценки качества целых команд программистов.
4. Подстраховка от глупых ошибок
Даже самые опытные разработчики время от времени совершают ошибки. Но если у разработчика есть возможность прогнать статический анализ до всех остальных проверок, то он вовремя заметит ошибку, исключив ее попадание в прод.
5. Контроль качества кода за внешними разработчиками
Довольно часто внешние разработчики работают над отдельными функциональными блоками, и никто внутри основной команды ИТ-отдела не контролирует их код. Происходит это по разным причинам. А если внешнему подрядчику и указывают на отступление от стандартов при оформлении кода по выполненным задачам, то он обычно не спешит тратить время на исправление. Заниматься рефакторингом в этом случае придется внутренним разработчиком когда-нибудь потом.
Правила и стандарты, зафиксированные в SonarQube командой, могут быть использованы как приложение к договору оказания услуг внешним подрядчиком, быть обязательны к исполнению для подписания акта выполненных работ. В этом случае подрядчик получает мотивацию делать с первого раза качественный код, иначе он не получит денег по обоснованным и прописанным причинам – SonarQube отправит тимлиду команды разработки отчет с критичными ошибками, допущенными программистами внешнего подрядчика.
1. Инструментарий
Процесс статического анализа кода должен быть удобным не только для тимлида, но, прежде всего, для самого разработчика, чтобы иметь возможность проверять самого себя. Один из популярных вариантов использования SonarQube – это отложенная проверка кода разработчиков по коммитам, помещенным в хранилище за определенный период, и рассылка им уведомлений о техническом долге. Разработчик мог выполнить задачу уже неделю назад, забыть о ней, переключиться на другую, а ему приходится заниматься ликвидацией технического долга по старой задаче. Причем он не имеет возможности один раз исправить код и убедиться тут же, что его рефакторинг ликвидировал 100% проблем, он вынужден ждать следующего письма с детализацией технического долга. Такой вариант использования негативно воспринимается разработчиками и действительно похож на инструмент контроля и наказания, нежели на помощника по поиску недочетов в твоем коде.
Ответственный разработчик сам хочет писать качественный код, ему нужно лишь помочь подсветить ошибки для последующего исправления. И, конечно, разумно это делать в конце работы по задаче. Поэтому удобным будет вариант использования SonarQube, который позволит программисту запустить проверку его кода по запросу и самостоятельно отработать ошибки. Идеально это выглядит в связке с пулреквестами Git, когда к запросу на слияние привязывается отчет по неисправленным ошибкам SonarQube.
2. Проведение организационных мероприятий
С командой требуется обсуждать ценность использования статического анализа кода, не допускать их зацикливания на мысли о «контроле» за ними. Необходимо пояснить, что, в первую очередь, это помощник для самих разработчиков. Если команда единогласно будет настроена против некоторых правил, которые, по их мнению, им мешают, а не помогают, то необходимо это обсуждать: либо аргументированно доказывать ценность проверок, либо выключить их. Необходимо вместе с командой прийти к перечню выполняемых проверок, среди которых нет тех, на которые можно закрыть глаза. Если из 100 проверок хотя бы 10 являются теми, на которые можно не обращать внимания, то инструмент из обязательного превращается в «по желанию».
Очень важно добиться, чтобы статический анализ кода воспринимался всей командой не как «прикольная штука», а именно как обязательный к исполнению свод проверок, который нельзя игнорировать.
Выше в статье много раз упоминалась фраза «в связке с CI/CD конвейерами». Под этим подразумевался некий интерфейс, реализующий набор команд управления разработкой. Под капотом таких интерфейсов обычно прячется набор скриптов OneScript, «1С:Исполнитель», Jenkins и т.д. Состав же команд обычно индивидуален для каждой компании. Такие решения на текущий момент всегда самописные. Тем не менее, общий тренд чаще всего реализуемых команд конвейеров отследить можно.
Основные задачи, решаемые CI/CD конвейерами:
1. Развертка рабочих машин разработчиков
Если в компании большой штат разработчиков и они работают не на физических компьютерах, а на виртуальных машинах, то автоматические создание машины «по клику» для очередного разработчика с определенными аппаратными мощностями и предустановленным софтом – будет полезным.
2. Установка софта на машине разработчика
Установка наиболее часто запрашиваемого софта можно автоматизировать:
3. Развертка баз
Как зачастую начинается работа над очередной задачей? Сначала разработчик хочет получить определенную копию базы, снятую с некой другой копии или прода, а также конфигурационные файлы, предпочтительно взятые из прода или близких к проду копий. Сначала он будет ждать, пока админ реализует для него первую часть, а потом будет ждать, пока освободится конфигуратор той базы, откуда можно получить свежие конфигурационные файлы. При неблагоприятном стечении обстоятельств подготовка базы для начала работы над задачей может растянуться на целый день.
Некоторые компании автоматизировали этот процесс, реализовав в CI/CD команду развертки базы, которой могут воспользоваться разработчики или аналитики. Опции могут быть следующие:
4. Прогон автотестов
Сценарные автотесты – прекрасный инструмент для выявления ошибок в том функционале, который ломаться не должен ни при каких обстоятельствах. Этот инструмент становится еще эффективнее, когда запуск происходит не в ночь перед релизом на проверяемой конфигурации (если найдены ошибки, то релиз придется отложить), а для проверки работоспособности функционала после реализации каждой задачи, когда у разработчика есть достаточно времени для исправления возникших ошибок. И такую возможность предоставляет CI/CD контур: при нажатии на команду могут быть развернуты виртуальные (или физические) машины, на которых в свою очередь развернется тестовое окружение 1С; обновятся базы на тестируемые конфигурации, запустятся сценарные автотесты и вернут Allure-отчет в качестве результата своей работы.
Для команды запуска сценарных автотестов могут быть заданы дополнительные параметры:
Подробнее о внедрении автотестов в статье на нашем сайте "Какого размера должен быть автотест?"
5. Прочие функции
Реализация управления CI/CD конвейерами
Рассмотрим наиболее частые реализации интерфейсов CI/CD конвейеров в командах 1С.
1. Самописная конфигурация 1С
Конфигурация 1С, которая предоставляет сотрудникам набор инфраструктурных и CI/CD команд. В этом же интерфейсе специалисты могут следить за ходом выполнения команд. Самописные отчеты могут отображать ход и результаты прогона автотестов, запуска различных проверок, статистику по активности разработчиков и т.д. Сама конфигурация обеспечивает управление командами, реализация которых выполнена через скрипты на смежных языках (OneScript, Jenkins и др.). Данная база может быть развернута в веб-интерфейсе, чтобы предоставить сотрудникам доступ к командам в браузере даже с телефона.
2. Доработка СППР или Итилиум
СППР и Итилиум – наиболее используемые конфигурации для управления задачами в разработке 1С. Их же зачастую дорабатывают для реализации функционала CI/CD. И это удобно – имея форму задачи мы можем удобным нам образом расположить на ней этапы процесса разработки:
5. Прочие варианты
Внедрение Git, CI/CD, статического анализа и практики ревью кода позволяет существенно повысить эффективность разработки 1С, улучшить качество решений и обеспечить прозрачность процессов. Однако эти инструменты должны внедряться последовательно и осознанно, с учётом масштаба проекта, зрелости команды и доступной инфраструктуры. Грамотный подход позволяет избежать лишних рисков и добиться стабильного, прогнозируемого и управляемого процесса разработки.
На практике мы часто видим, что командам сложно пройти этот путь самостоятельно — не из-за отсутствия желания, а из-за нехватки времени, опыта внедрения или понимания, с чего именно начать. В таких случаях компания «1С-Премиум» поможет пройти путь внедрения поэтапно и безболезненно:
Такой подход позволяет не просто «внедрить инструменты», а получить измеримый результат: снижение количества ошибок, ускорение релизов и рост качества кода без перегрузки команды.
Если вы только задумываетесь о внедрении или уже столкнулись с трудностями на этом пути, надеемся, что эта статья поможет избежать типичных ошибок и принять взвешенные решения.
VV