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

На вопросы журнала «Системный Администратор» отвечает руководитель корпоративной практики Департамента корпоративных информационных систем (ДКИС) ALP Group.

– Какие сервисы у вас используются? 

– У нас используется СУИ, как трекер задач, где заводятся различные обращения и инциденты, СУИ связан с GitLab, это второй сервис. GitLab представляет собой хранилище кода. Каждое помещение в GitLab либо в хранилище имеет свой номер задачи, и эта задача присутствует в СУИ, это то, что касается части 1С. Также есть Jira – это трекер задач, там точно такая же привязка к коду, который помещается в GitLab. Связка классическая, используется большинством компаний. В СУИ присутствует привязка, когда выпускается релиз, происходит обращение из СУИ к Jenkins. Получается Jenkins – еще один инструмент. С его помощью происходят различные сборки, обновления и так далее. Кроме того, Jenkins связывается еще с Jira точно таким же образом.

В Jira есть точно такая же сущность релиза, когда коллеги выпускают релиз, они передвигают, грубо говоря, карточку из одного раздела в базе в другой. Срабатывает Webhook, который перехватывает это событие, и после этого выпускаются задачи сборки в Jenkins, который делает то, что в задаче прописано. Jenkins – ключевой инструмент, который отвечает за автоматизацию большинства процессов, применительно к части 1С. Например, у нас есть ежедневные ночные сборки. Что они делают? Есть два основных сценария. Первый сценарий – когда при разработке используется хранилище 1С, в этом случае его необходимо загрузить в GitLab. Все новые изменения, помещенные в хранилище 1С, загружаются в GitLab. Далее на основании этих изменений происходит проверка статическими анализаторами, в частности SonarQube, также может быть использован АПК (это автоматизированная проверка конфигурации, написанная на языке 1С), она применяется не для всех проектов, потому что скорость проверки оставляет желать лучшего, и для тяжелых конфигураций пока мало применима. Далее, есть ряд технических шагов, которые необходимы для того, чтобы все работало, например, закачивается последняя стабильная версия инструмента тестирования. Для 1С это VanessaADD. В ее составе есть минимальный набор «дымовых» тестов «из коробки», которые проверяют на открытие форм, на валидность запросов в рамках СКД и так далее, они универсальны для любой конфигурации и настраиваются достаточно быстро. По сути вся процедура настройки этих тестов заключается в том, чтобы сформировать набор исключений, поскольку некоторые блоки кода в конфигурации могут падать. Второй вариант – когда добавляются какие-то исключения. Какие-то проверки невозможно совершить из-за ограничений инструмента либо когда, если говорить про открытие форм, данная форма – техническая и не относится к интерактивному открытию. На выходе мы получаем набор исключений, остаются только те тесты, которые должны выполняться в этой конфигурации, и они будут выполняться всегда, соответственно по итогам проверки будет формироваться отчет в определенном формате (формате Allure), который будет загружаться в Jenkins. 

По поводу инструмента VanessaADD = это общедоступный инструмент, он есть в GitHub репозитории https://github.com/vanessa-opensource/add, но в нем есть некие наши разработки, которые не были слиты в общий проект, по сути это форк (ответвление) проекта, содержащий ряд небольших изменений. Эти изменения не были слиты в основной проект потому, что они касаются особенностей работы с нашим заказчиком. В целом поддержкой этого форка ADD занимаются коллеги со стороны заказчика. При выходе новой версии родительского проекта доработки объединяются, устраняя противоречия между нашим функционалом и функционалом, вышедшем в родительском репозитории. Далее версия тестируется на нескольких проектах, если всё отлично, то VanessaADD промоутится как стабильная, которая в дальнейшем будет использоваться на всех остальных проектах при каждодневном запуске. Это если говорить про сценарий работы с хранилищем. Второй сценарий: работа с Git напрямую, когда все изменения, которые делает разработчик 1С, он помещает непосредственно в репозиторий GitLab. Ключевые верхнеуровневые отличия в том, что несколько иначе устроено хранение данных, они хранятся в разрезе репозиториев и веток, это надо понимать при работе. На что это повлияло с точки зрения процесса? Нет шага выгрузки хранилища в GitLab, на это время не тратится – для больших проектов это существенное время. И второе – это то, что ночные сборки по умолчанию выполняются на стабильной ветке, если разработчик сделал какие-то доработки, он может запустить весь процесс на своей ветке и получить результаты тестирования. Статический анализатор SonarQube – еще один сервис, который используется в процессе. Он отвечает за проверку на соответствие правилам разработки. В принципе у него достаточно большой пул различных проверок на различных языках, начиная от Java, на которой он был написан, и заканчивая 1С. Надо отметить, что перечень проверок для 1С языка поставляется в виде плагина. Есть два варианта поставки плагинов. Платный вариант – плагин поставляется по подписке от серебряной пули и бесплатный вариант – от комьюнити 1С. В нем значительно меньше правил проверки и работает он чуть дольше. Мы используем вариант поставки именно серебряной пули.

- Зачем этот инструмент используется? 

- В каждом языке есть свой набор правил, которые позволяют автоматизировано проверять весь новый код на их соответствие, если обнаружены какие-то несоответствия правилам, разработчику выставляются замечания, он эти замечания устраняет либо обосновывает почему их устранить не может. Стоить отметить, что есть инструмент Artifactory для хранения артефактов, в частности, он используется для хранения CF-файлов (файл поставки конфигурации в 1С), которые в дальнейшем накатываются на тестовые и продуктивные зоны. Есть три зоны – develop, test и prod. Соответственно в зоне develop разработчик имеет права, близкие к административным, он может сделать, что захочет, но при этом работает на обезличенных данных. Как происходит поставка в тестовую, а в дальнейшем и продуктивную среду? Разработчик готовит CF в develop-зоне, далее CF передается коллегам из поддержки, которые имеют доступ к средам test и prod. В зоне test они обновляют тестовую базу, проводят тестирование функционала. В случае успешного тестирование производится обновление в prod-зоне. Соответственно вместо них всё это делает Jenkins. Используется такая схема – при обновлении баз Jenkins берет CF из Artifactory, из той зоны, к которой относится база. Перемещение между зонами происходит в рамках релизного цикла.

Разработчик подготовил релиз, в СУИ продвинул бизнес-процесс на проверку файла поставки (CF-файла) в службу информационной безопасности. Она проверяет, если нет вопросов, бизнес-процесс движется дальше и СF автоматически попадает в Artifactory, в соответствующую зону, из которой возможно деплоить в базы тестового и продуктивного сегмента.



– Как используются виртуальная система, СУБД, система контроля версий?

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

– Как построен рабочий процесс?

– Процесс можно разделить на разработку и сборку билда, поставку билда на различные зоны (develop, test, prod). В части 1С есть две рабочие схемы разработки и сборки билда: это разработка с использованием хранилища и без использования хранилища. Если используется хранилище 1С, то процесс разработки происходит так: каждая база (а в 1С разработку вести без базы нельзя) подключена к хранилищу. В этом случае все изменения помещаются в это хранилище, но есть две ключевые особенности. Ты работаешь с конкретными объектами. В терминологии 1С есть определенные объекты метаданных, когда ты работаешь с этими объектами, ты их должен захватывать. Ты должен захватить объект монопольно, внести изменения, поместить их в хранилище, отпустить объект. Здесь версия хранилища всегда последняя, и ты, работая с каким-то объектом, всегда работаешь с его последней актуальной версией. Это накладывает ограничение на сборки стабильного билда. Пример. Есть хранилище разработок, куда подключены условно 10 разработчиков. Каждый вносит свои изменения, если им нужно внести один и тот же объект, они ждут, пока закончит работать другой разработчик. Все это помещается в единое хранилище. Далее необходимо сделать сборку стабильного билда (получить cf-файл), для того чтобы его протестировать и выпустить в качестве релиза. Ты должен взять эти изменения и перенести из хранилища разработки (develop) в хранилище релиза (release). Этот перенос может осуществляться только вручную человеком. Потому что с учетом монопольности изменений достаточно сложно выдернуть автоматизировано какие-то изменения, которые нам не нужны. Сценарий, – когда один разработчик согласно своей задаче поместил изменения, а потом поверх этого второй разработчик поместил свои изменения, а нам в процессе сборки нужны изменения только первого разработчика, – возможно разрешить только вручную.

Примечание

Основная проблема в том, чтобы класть код, который написал разработчик непосредственно в GitLab. Но мало разработчиков 1С умеют работать с Git’ом. Поэтому был создан инструмент с UI для взаимодействия с Git, где вся логика взаимодействия с Git’ом продумана за разработчика и имеет своим границы. По сути это некий продукт, который позволяет разработчику начинать работу над задачей, помещать изменения в хранилище и, если надо, продолжать работу, возвращаться к какой-то старой задаче, которую он ранее не закончил. По большому счету это просто набор скриптов, которые разработчикам позволяют взаимодействовать с GitLab.

Есть практика перевода команд на такой процесс работы с GitLab напрямую. Перевод на этот процесс подразумевает изменения процесса разработки – если раньше мы монопольно слали изменения в хранилище, потом выдергивали их вручную, то сейчас все изменения помещаются в отдельную ветку по задаче. Это так называемый gitflow, когда на каждую задачу разработчика создается отдельная ветка. Всё, что надо разработчику, это указать номер задачи, с которой он работает. Этот номер связан с соответствующим номером в трекере задач, напомню, трекером задач является либо СУИ, либо Jira. Из трекеров можно напрямую провалиться в Git и посмотреть, какой код был изменен разработчиком, что было сделано, какие объекты изменились и так далее. Касательно процесса, разработчик, получая задачу, создает отдельную ветку с помощью нашего инструмента, то же можно сделать вручную с помощью команды git’а. 

Он создает отдельную ветку, все изменения, которые он кладет в нее, изолированы от других доработок. Разработчик кладет все изменения в ветку, в ней происходит тестирование статистическим анализатором. Как только поставленная задача сделана, передана на тестирование, и оно завершено, эта ветка готова к тому, чтобы ее слить в релизную ветку, в которой собирается релиз. Когда мы готовим релиз, у нас есть набор веток. Допустим, у нас 10 задач, которые были сделаны десятью разработчиками. Мы сливаем эти ветки в основную ветку, и при слиянии у нас могут возникать конфликты в случае двухстороннего изменения одних и тех же объектов или строк. Конфликты устраняются вручную, как и в любом другом языке. Таких случаев надо стараться избегать, это вопрос к планированию деятельности разработчиков, чтобы изменения одного и того же объекта не попадали разработчикам в две разные задачи. В целом ситуация достаточно штатная, и если что-то произойдет, ничего страшного нет, единственное, что в 1С есть ряд особенностей по слиянию, поскольку сам принцип программирования 1С отличается от обычных языков. Могу сказать, что особенности учтены при слиянии различных объектов, мы это тоже отслеживаем. В результате получается стабильный билд, который может выступать в качестве релизного. Далее, в рамках процесса, который ведется в трекере задач Jira либо СУИ, этот билд помещается в хранилище артефактов Artifactory в зону develop и по мере продвижения процесса появляется в test и prod зоне, из которой происходит обновление соответствующих баз.

– Какая используется система заявок?

– Используются Jira и СУИ, если говорить про заявки, касающиеся работы команды DevOps или поддержки среды разработки.

– Как ведется база знаний? Кто и как в нее пишет? 

– База знаний ведется в confluence. Она разделена на две части – закрытую и открытую. В закрытой хранятся конфиденциальные данные, внутренние инструкции, перечень IP-серверов, то есть рабочий материал. Открытая часть используется для того, чтобы любой, кто сталкивается с DevOps, мог знакомиться с информацией на тему. Также есть ряд статей, рассказывающих о том, что необходимо для того, чтобы начать пользоваться DevOps. Их пишет вся команда.

– Кто ведет документацию по проекту? Как построен процесс документирования?

 – Мы не вмешиваемся в работу команд разработки и не диктуем, как им писать документацию, это исключительно их договорные отношения с их заказчиком. Процесс документирования в целом не автоматизирован, если говорить именно о классической документации. Почему не автоматизирован? В 1С есть возможность создавать видеоинструкции на основе feature-файлов (заготовок под сценарные тесты), однако не очень понятен потребитель этих видеоинструкций. Кроме того, чтобы видеоинструкция была достаточно хороша, нужно потратить столько времени, сколько уходит и на написание обычной инструкции. По этим двум причинам мы пока отказались от какой-то видеодокументации.

– Как организуется процесс обучения?

– У нас уже эта схема отработана. Когда любая команда хочет войти в процесс CI/CD и получить какие-то преференции от него, вначале происходят установочные онлайн-встречи, на которых рассказывается, какие преференции это дает, какие требования диктует и что для этого надо. Для процесса поставки мы договариваемся, как она будетосуществляться, какие контролирующие лица будут в процессе поставки. Команда поддержки и разработки должна понимать, что происходит на каждом этапе. Сначала мы выстраиваем процесс – объясняем все необходимые шаги, затем делаем пробную поставку на тестовую зону, когда тестовая зона откатана, всё уже понятно, мы переходим к production. В момент первой автоматизированной поставки один из инженеров DevOps страхует сборки, то есть мы понимаем, когда у нас осуществляется поставка и в этот день подстраховываем первый раз процесс выполнения этой поставки. Для процесса разработки есть два варианта: работа с хранилищем и работа непосредственно с гитом. В зависимости от выбранного варианта мы помогаем команде выстраивать целевой процесс. Рассказываем о том, как он происходит, какие шаги должны быть выполнены. Получаем данные по базе в среде разработки, учетные записи, если есть хранилище 1С, то данные учетной записи в хранилище 1С, чтобы настроить типовой pipeline, который позволит базу обновлять. Дальше настраиваем им проект в SonarQube, чтобы сделать первично прогон всей конфигурации на соответствие общим правилам разработки. Проводим обучение по тому, как пользоваться SonarQube, какие есть замечания, какие классификации у этих замечаний, какая степень критичности, чем степень критичности отличается, какие правила в принципе присутствуют. 

Надо отметить, что SonarQube позволяет создавать свой набор правил, с разным уровнем «строгости». У нас используется ряд общепринятых правил, который урезан до уровня musthave-проверок, мы демонстрируем, какие правила есть. Рассказываем, как работать с замечаниями, как их устранять, какие уведомления приходят, мы находимся на связи, после того как всё это им расскажем. Далее настройка дымового тестирования; от команды мы получаем перечень исключений, перед этим рассказываем, как этот инструмент работает, как запускать его в интерактивном режиме, как он в дальнейшем будет встроен в конвейер. Кроме того, есть набор инструкций, который позволит обратиться после обучения к интересующему вопросу. Также есть набор видеоинструкций, который можно пересмотреть. Следующий шаг – это сценарное тестирование. Рассказываем, что такое сценарные тесты, как пользоваться этим инструментарием, как писать тесты, начиная с самых простых, просим команду написать парочку простых, в процессе отвечаем. Поскольку это достаточно небыстрый процесс, мы находимся на связи с командой и рассказываем, советуем, какие шаги использовать, как реализовать ту или иную проверку и так далее.

В целом я бы сказал так, что сначала выстраивается процесс – ночные билды, проверки дымовыми тестами, сценарными тестами. После того как develop-часть готова, мы переходим к тому, как осуществлять правильно поставку. Как правило, это всё происходит параллельно, но в общем мы стараемся сначала выстраивать работу в среде develop, а потом уже переходить к поставкам.

– Работают ли люди из разных регионов удаленно или все находятся в офисе?

– Поскольку у нас крупные заказчики, у них есть своя защищенная корпоративная среда, доступ в которую осуществляется через средства криптозащиты. Процесс получения доступа проходит через ряд согласований, в том числе через службу безопасности. После того как доступ получен, сотрудник получает возможность входа в гостевой сегмент корпоративной среды, из которой он может попасть в среду разработки (develop), среду тестирования (test) или продуктивную среду (prod). Между этими средами ограничено взаимодействие на уровне сетевых доступов. Связующим звеном между средами выступают инструменты DevOps.

Вся разработка ведется в среде разработки (develop) на обезличенных данных. Разработчик имеет права на эту среду, близкие к административным. В этой среде подготовлена вся необходимая инфраструктура и сервисы, которые могут понадобиться в процессе разработки. Стоит отметить, что доступ к этой среде возможен как из гостевой среды, или ВАРМ, так и со стационарных рабочих мест. В среде тестирования (test) осуществляется тестирование на продуктивных данных поставляемых релизов. На базы в тестовом сегменте могут быть установлены релизы, прошедшие проверку со стороны информационной безопасности. На базы продуктивной среды (prod) могут быть установлены релизы, прошедшие проверку информационной безопасностью и успешно протестированные. Кроме того, возможен сценарий, когда весь процесс разработки организован где-то за пределами защищенной корпоративной среды. В этом случае команда помещает все изменения в защищенный репозиторий GitHub (или, как вариант, Bitbucket), который зеркалируется на постоянной основе с репозиторием в корпоративном GitLab. Далее всё то, что ранее описывал, применимо, начиная от проверки сценарных тестов, заканчивая поставкой в базы.

– Как решаются «шероховатости» во взаимодействии отдела разработки и DevOps?

– Сейчас основная проблема – перегруженность команд разработки бизнес-задачами. В результате этого задачи, относящиеся к DevOps, переносятся. Это основная проблема в любом enterprise, потому что команда разработки должна, в первую очередь, решать бизнес-задачи. И хотя со своей стороны мы помогаем командам выстраивать процесс поставки, а иногда и процесс разработки, но мы не можем делать это без участия команд разработки и поддержки. Ведь только сами команды знают их продукт. И если команда хочет получить все выгоды от процесса CI/CD, она должна принимать в этом активное участие. Мы, как команда DevOps, стараемся со своей стороны просто доносить до них необходимость этого и взаимодействовать с владельцами системы, если это надо.

– Как делаются резервные копии?

 – С учетом синхронизации хранилищ 1С с GitLab, бэкап делается только GitLab. Если говорить о хранении каких-то стабильных билдов, то есть Artifactory, который позволяет хранить версии стабильных билдов. Кроме того, присутствует резервное копирование баз данных, в которых осуществляется разработка. На ряд файловых ресурсов настроено shadow copy.