Предисловие
В последнее время в среде разработчиков всё чаще стали встречаться термины TDD (Test Driven Development), BDD (Behavior Driven Development), CI (Continuous Integration), git и всё это в контексте тестирования 1С-конфигураций. Мало кто из разработчиков 1С представляет, а тем более, понимает, что это такое, зачем это нужно, как это использовать и как с этим жить. Особую актуальность эти технологии приобрели с выходом нового инструмента от 1С: EDT (Enterprise Development Tools), в котором 1С решила отказаться от использования хранилища конфигурации в пользу git.
С момента, когда я узнал о существовании альтернативных способов разработки 1С-конфигураций, тестирования и хранения кода, передо мной начала возникать масса вопросов, наверное, главными из которых были "почему?" и "как?". Например:
- Почему нужно использовать другую систему хранения кода?
- Почему выбран именно git в качестве системы хранения кода?
- Как git и CI помогут тестировать решение?
- Как организовать процесс разработки так, чтобы можно было применять данные технологии на практике?
- и т. д.
В силу того, что я начал знакомство с технологией CI практически с нуля, я, как мне кажется, смогу помочь разработчикам, начинающим знакомство с CI, получить ответы на эти и другие вопросы, поиск которых отнял у меня очень много сил и, тем самым, облегчить изучение новых практик.
В данной статье я опишу, откуда возникла потребность в CI и как можно осуществлять тестирование конфигураций 1С имеющимися средствами. Здесь я намеренно не буду описывать существующие инструменты проведения тестирования конфигураций, цель данной статьи: дать общее представление о механизмах, используемых в CI.
Благодарности
Хочу выразить благодарность участникам gitter-каналов oscript-library, vanessa-behavior, vanessa-runner, а также Андрееву Михаилу.
Отдельную благодарность выражаю Евгению Сосне за неоценимую помощь в практическом освоении инструментов CI.
Проблема
История развития методов разработки конфигураций 1С достаточно долгая, с самого начала практики разработки конфигураций прикладными разработчиками и до наших дней эти методы претерпели немало изменений. Изначально разработка конфигураций не предполагала коллективного участия, затем сложность конфигураций росла и потребовалось решать проблемы взаимодействия нескольких разработчиков. В результате чего появилось хранилище конфигурации. Итогом этого стало появление возможности создавать сложные решения, содержащие в себе многие тысячи строк кода. Их развитие стало нести определённые риски для уже реализованных частей продукта: доработки одних частей конфигурации могли "сломать" исправно работающие механизмы в других частях конфигурации. С другой стороны, степень доверия к 1С:Предприятию постоянно увеличивалось отчего 1С начала проникать в сферы деятельности компаний, требующие постоянной доступности предоставляемого сервиса. Критичность качества конфигураций и процесса обновления старых версий конфигураций на новые возросли пропорционально критичности решаемых при помощи 1С задач. Поэтому возникла задача обеспечения более качественной разработки и тестирования как самого продукта, так и процесса обновления эксплуатируемых баз данных.
В такой ситуации разработчикам целесообразно озаботиться тестированием разрабатываемого продукта, для чего требуются соответствующие инструменты. В этой статье я попытаюсь описать одно из решений, позволяющих осуществлять тестирование продуктов на базе платформы 1С:Предприятие.
Решение
Самое простое, что можно придумать, это разработать ряд специализированных обработок, предназначенных для тестирования тех или иных частей продукта. Обязать каждого разработчика запускать эти обработки при написании кода и выполнять их на конфигурации, подготовленной для обновления, перед самим обновлением.
Это, в принципе, годное решение, но несёт в себе ряд недостатков:
- Разработчики со временем забывают, что делают тестирующие обработки, а сами тестирующие обработки со временем устаревают. В итоге тестирование проводится неполно или некорректно.
- Запуск обработок требует отдельных усилий разработчика, непосредственно не связанных с созданием ПО, что сами разработчики встречают без особого энтузиазма. В итоге, без надлежащего контроля этот процесс имеет немалые шансы отмереть. Тестирование будет проводиться, в лучшем случае, перед обновлением и выявлять проблемы достаточно поздно, когда разработчик уже успешно забудет контекст задачи "поломавшей" продукт, если такую задачу вообще можно будет выявить.
В развитие этой технологии можно придумать ряд инструментов, позволяющих не заглохнуть процессу тестирования. Например, автоматический запуск тестирующих обработок. Вот только возникает вопрос, что и когда тестировать?
Давайте пока остановимся и попытаемся сформулировать основные требования к процессу тестирования:
- Тестирование должно производиться только тогда, когда разработчик произвёл логически законченные изменения кода, а не в произвольный момент, когда разработчику очевидно, что код в его текущем состоянии и так провалит тесты.
- Тестирование должно производиться автоматически, без участия разработчика, возможно даже в нерабочее время. Причём разработчику совершенно необязательно следить за результатами тестов, ему достаточно получать уведомления только при наличии не прошедших (упавших) тестов, причём, желательно, вызванных только его изменениями.
- Должна быть возможность проводить тестирование под управлением разных ОС и разных версий платформы 1С:Предприятие.
Теперь попытаемся понять, как можно удовлетворить вышеописанные требования в реалиях разработки.
Определение момента осуществления тестирования
Так как мы говорим о современной разработке средствами 1С, то предполагаем, что в процессе разработки используется хранилище конфигурации. Моментом начала тестирования может служить факт помещения кода в хранилище, других событий готовности кода к тестированию у платформы нет. Альтернативой может выступать только ручное "указание" разработчика на необходимость начала тестирования, но мы для себя определили, что процесс тестирования должен стартовать без его участия.
Отсюда следует, что для того, чтобы тестирование выявляло ошибки как можно раньше, разработчику необходимо как можно чаще помещать изменения в хранилище. Наверное? лишним будет напоминать, что помещаемый в хранилище код должен быть законченным и рабочим, по крайней мере по мнению самого разработчика, ведь результатом тут же могут воспользоваться его коллеги.
Порядок проведения тестирования
Теперь надо определиться с алгоритмом тестирования. На данный момент мы имеем:
- Конфигурацию в хранилище;
- Обработки, тестирующие нашу конфигурацию.
Первое, что нам нужно для тестирования, это сама конфигурация. Т. к. тестирование производится вне контекста разработчика, то, в общем случае, доступа к конфигурации разработчика нет, есть, как было сказано ранее, только хранилище конфигурации. Нужно каким-то образом достать из хранилища конфигурацию. Это можно сделать, например, запуская конфигуратор, используя ключ ConfigurationRepositoryDumpCfg.
Затем нужно получить тестовую базу, которую будем тестировать. Это, опять же, можно сделать при помощи запуска конфигуратора с ключом LoadCfg, которой в качестве параметра указать только что полученный файл конфигурации.
Также можно просто создать базу данных, подключенную к хранилищу и проводить тестирование на ней.
На этот момент мы имеем базу данных с актуальной конфигурацией, но она не готова для тестирования, т. к. сначала надо провести начальное заполнение этой базы тестовыми данными (создать пользователей, заполнить константы и справочники, и прочее). Для этого можно написать ещё одну обработку и запускать её после создания тестовой базы, а можно выполнять загрузку конфигурации в уже подготовленную базу данных. Выбор способа подготовки тестовой базы зависит от сложности выполнения инициализации базы для тестирования, а также ваших предпочтений.
Наконец, можно запускать тесты. Запуск тестов можно выполнять также штатным способом, используя запуск 1С:Предприятия с ключом Execute.
Результаты тестирования обработка может записывать в какой-нибудь файл, который впоследствии можно анализировать и, в результате, выполнять определённые действия, например рассылать почтовые уведомления.
Запуск тестирования
Далее нужно понять, как автоматически стартовать сам процесс тестирования.
Самый простой и очевидный способ: попробовать создать сценарий (bat/sh) и запускать его по расписанию. Для этого можно использовать cron, планировщик задач windows или какое-либо другое средство запуска задач по расписанию. Этот способ имеет ряд недостатков в виде недостаточной визуализации результатов работы запускаемых скриптов, сложности администрирования и обеспечения работы и взаимодействия скриптов на разных компьютерах сети.
Для преодоления этих недостатков можно разработать набор инструментов, которые позволят легко управлять задачами на разных компьютерах и отображать результат их работы, но, на самом деле, такие инструменты уже есть и достаточно популярны. Вообще, описываемая технология тестирования называется CI (Continuous Integration -- Непрерывная Интеграция) и используется практически везде, при разработке программного обеспечения и то, что эта технология не используется при разработке решений на платформе 1С:Предприятие, скорее недоработка, чем особенность. Идея CI заключается в том, что сборка разрабатываемого продукта (компиляция, тестирование, публикация) осуществляется одновременно с разработкой. После очередного помещения изменений в хранилище кода продукта автоматически запускается сборка. За все операции ответственен сервер CI, осуществляющий мониторинг событий, выполнение скриптов, публикацию результатов сборок, рассылку уведомлений и прочие необходимые действия. Помимо этого, скрипты могут выполняться не на самом сервере CI, а на любом компьютере сети, что позволяет распараллелить процесс сборки продукта.
Также серверы CI позволяют разграничивать доступ к настройкам сборки различных продуктов, имеют собственные языки описания сценариев выполнения задач, богатые средства вывода отчётов о сборках и массу других полезных вещей. Другими словами, развернув сервер CI, вы избавите себя от реализации множества насколько полезных, настолько трудоёмких возможностей.
Существует большое количество серверов CI, например здесь можно посмотреть сравнительную таблицу серверов CI. Но от себя хочу сказать, что, наверное, наиболее распространённым является jenkins в силу богатства возможностей за счет наличия огромного количество плагинов, и, что самое главное, его бесплатности.
Jenkins
В сети можно найти огромное количество материалов с описанием jenkins, инструкций по его установке и использованию, поэтому я не буду здесь повторять эту информацию, а лишь опишу способы использования jenkins для организации сборки продукта на платформе 1С:Предприятие.
По сути jenkins представляет собой достаточно продвинутый шедуллер запуска задач на любых доступных компьютерах. Возможность управления задачами на разных компьютерах сети в jenkins реализовано при помощи следующей архитектуры: В сети выделяется компьютер, на который устанавливается управляющий сервер jenkins. Этот компьютер называется главным, или мастер-узлом (master-node), всё управление jenkins'ом осуществляется при помощи web-интерфейса, предоставляемого этим сервером. Далее, на любой компьютер сети может быть установлена отдельная служба jenkins, который сделает этот компьютер дочерним узлом (slave-node). Эта служба необходима для того, чтобы jenkins мог выполнять код на этом компьютере.
В общем случае, задача, созданная на jenkins'е не привязана к какому-либо конкретному узлу и может быть выполнена на любом доступном узле. При помощи меток узлов в задаче можно сократить количество доступных для выполнения задачи узлов. Мало того, возможно выполнение разных частей одной задачи на разных узлах.
Результатом выполнения задачи может быть просто статус её выполнения, а может быть ещё и определённый набор файлов, называемый артефактом сборки. Эти артефакты могут быть использованы в других задачах или выкладываться в общий доступ, в зависимости от назначения. В любом случае, логикой выполнения задачи управляет разработчик и он же определяет, что будет являться результатом выполнения задачи.
Сборка
Итак, располагая имеющейся информацией, уже можно осуществить сборку и тестирование продукта по определённому ранее алгоритму:
- На компьютере, где развернута платформа 1С:Предприятие нужно развернуть дочерний узел jenkins, задать ему метку, обозначающую наличие на узле платформы 1С определённой версии.
- Создать задачу, в которой указать, что она должна выполняться на узле с необходимой версией платформы. В задаче выполнить запуск конфигуратора с операциями:
- создания пустой базы данных;
- сохранения конфигурации из хранилища в файл;
- запуск обработки, производящей первичное заполнение базы данными;
- запуск обработки, производящей тестирование конфигурации;
- анализа результатов тестирования и установки статуса сборки;
- при желании здесь же можно осуществлять формирование комплектов поставки, развертывание релиза на рабочей базе и другие необходимые действия.
Задание меток у узлов и их указание в задачах необходимо по причине того, что задача может быть выполнена на любом узле jenkins, в том числе и том, где платформа 1С не установлена.
Каталог с хранилищем конфигурации должен быть доступен по сети или хранилище должно предоставляться сервером хранилища конфигурации. Запуск задания можно осуществлять по факту изменения файла базы хранилища конфигурации.
Обработки, выполняющие заполнение базы данными и тестирование можно выложить на общедоступный ресурс сети и брать их оттуда. Анализ результатов можно проводить любым доступным вам способом. Главное помнить, что "правильного" решения не существует, каждый случай уникальный, а архитектура решения для каждого случая разрабатывается своя.
На этом, пожалуй, можно и остановиться, мы, почти в режиме реального времени, видим состояние нашего продукта и можем принимать решение по дальнейшим действиям, например подготовке комплекта поставки для последующего развёртывания. Это, на данный момент, не главное, главное то, что мы получаем чуть больше уверенности, в том, что продукт находится в рабочем состоянии и обновление рабочих баз не повлечёт за собой незапланированных простоев или потери данных.
Итоги
Описанный здесь процесс сборки и тестирования продукта можно использовать на практике и сейчас, однако есть уже готовые средства, которые существенно облегчают техническую реализацию этого процесса. В любом случае, дальнейшее описание процесса CI, будет основываться на описанных здесь базовых принципах. В следующих статьях я опишу используемые инструменты для тестирования продуктов на базе 1С:Предприятие, расскажу про использование git в процессе разработки и остановлюсь чуть подробнее на автоматизации процесса посредством jenkins.
Ссылки
Первая часть: Введение в CI для 1С
Вторая часть: Использование git при разработке на 1С
