Если вы тоже параллельно работаете сразу в нескольких несвязанных между собой системах, то знаете, какая это головная боль. Мы долго мучились, и в конце концов придумали схему, по которой можно объединить «необъединимое»: системы Confluence, СППР2 и Jira. Практическая инструкция по интеграции инструментов (а также ответ на вопрос «Зачем вам всё это понадобилось?») — под катом. Никакой воды — всё строго по делу.

Предпосылки реализации (зачем «плодить сущности»)

Привет, Хабр! Меня зовут Артем Вожаков, и я работаю архитектором информационных систем в IBS. Наша команда реализует сложные информационные системы, состоящие из множества отдельных программных решений на различных платформах, преимущественно 1С.

Вот классические проблемы, с которыми может столкнуться команда при работе над крупным «долгостроем»:

Такого рода проблемы типичны для проектов по комплексной автоматизации крупного бизнеса, которыми занимается наша команда. Очевидно, что крайне важно с самого начала любого ИТ-проекта организовать работу таким образом, чтобы обеспечить максимальную прослеживаемость и прогнозируемость результатов. Чтобы проект завершился успешно (да даже просто — завершился), необходимо предвидеть типичные проблемы, исключать их возникновение или выявлять их как можно раньше и минимизировать последствия.

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

1. Jira — для трекинга работ, учета трудозатрат и контроля лимитов на всех стадиях проекта.

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

3. СППР2 (продукт Фирмы «1С») — для проектирования разрабатываемых (дорабатываемых) конфигураций 1С, организации процессов разработки, создания системы распределения прав доступа и построения системы регрессионного тестирования конфигураций и расширений.

Каждый из перечисленных инструментов частично дублирует функциональность двух других (особенно Confluence и СППР2), что часто приводит к желанию отказаться от одного из инструментов или даже двух из трех при реализации проектов. Так почему же нельзя обойтись одной системой? Каждый из инструментов обладает уникальными функциями, использование которых (под наши цели) является целесообразным. Так, например, СППР2 описывает только отдельные конфигурации 1С. Описание комплексных проектов, соответствие объектов метаданных, интеграции не покрываются функционалом СППР2. Для этих задач требуются доработки или же использование дополнительных инструментов.

Мы решили не лишать себя преимуществ разных систем, останавливаясь на каком-то одном продукте, а вместо этого придумать, как доработать СППР2 и создать наборы интеграций с Confluence и Jira — причем так, чтобы избежать дублирования информации в системах.

Плюсы подхода:

1. Для каждой прикладной задачи используется лучший инструмент для ее решения, данные между системами передаются автоматически.

2. На выходе из проекта заказчик получает базу СППР2, в которой в структурированном виде хранится вся информация о проекте: функционально-технические требования, реестры бизнес-процессов, проектные решения, задания на разработку (технические проекты), задачи разработки, объекты метаданных (с привязкой к задачам разработки), исходный код доработок.

3. На выходе из проекта IBS забирает для повторного использования свою копию базы СППР2, которая содержит всю информацию, включая выгрузки из Confluence и Jira, где хранятся исходные данные для проекта.

4. Необходимость ручного ввода данных в СППР2 сведена к минимуму, вносятся только дополнительные данные по решению команды: шаги процессов, описание функций системы, автотесты и т. д. При этом на 100% исключен двойной ввод информации в разные системы.

Основные объекты этапа проектирования

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

Приведем перечень основных объектов, учитываемых в проекте:

Распределение функциональности по системам

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

Интеграция инструментов

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

В проектах IBS разработка, как правило, выполняется в среде заказчика, причем зачастую через VPN-подключение. Confluence и Jira используются внутри компании. Получается, что команде необходимо одновременно работать и в сети заказчика и в сети IBS. Исходя из целей обеспечения информационной безопасности одновременная регистрация в двух VPN запрещена. Таким образом, прямая интеграция систем среды разработки и IBS крайне затруднена. Исходя из этого мы планируем использовать интеграцию, основанную на передаче файлов, которые можно копировать в среду заказчика любым доступным способом, в том числе по электронной почте.

СППР2 → Confluence

Для подготовки различных документов в Confluence может потребоваться информация, хранящаяся в СППР2, такая как:

1. Бизнес-роли пользователей (Профили доступа).

2. Матрица доступа (состав ролей профилей доступа).

3. Функции системы для сценария тестирования и ПМИ (если ведется в СППР2).

4. Ключевые операции (для программы нагрузочного тестирования).

5. Прочая техническая информация.

Для выгрузки данных из СППР2 в Confluence используется простая выгрузка документов Excel из СППР2 и дальнейшая вставка этих данных в Confluence. Таким образом обратных интеграционных потоков создавать не требуется.

Confluence → Jira

Интеграция Confluence – Jira является бесшовной и детально описана на официальном сайте Atlassian.

Confluence → СППР2

Наиболее трудоемкой и связанной системой с Confluence является СППР2. Требуется разработка инструментов интеграции для объектов, представленных в таблице.

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

Даже если СППР2 на проекте не используется, интеграция может использоваться для передачи исходной технической информации Confluence заказчику.

Jira → СППР2

Ограничения СППР для использования в комплексных проектах

При обозначенной выше схеме интеграции остается ряд концептуальных проблем, требующих решения при практической реализации. Я опишу, как к ним решили подступиться в IBS. Предлагайте альтернативные решения в комментариях ;)

1. Проектирование конфигураций с расширениями в СППР2.

Поскольку использование расширений становится основной практикой на проектах, необходимо встроить их в логическую модель описания создаваемых в рамках проектов решений. Проблема в том, что конфигурация с расширениями работает как одна, но по факту представляет собой несколько объектов — в СППР2 это не учитывается. Отсюда проистекает ряд вопросов:

• Как будут связаны расширения и основные конфигурации?

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

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

• Возможно ли автоматизировать получение текущего состояния объектов метаданных конфигурации и всех расширений на регулярной основе? Какие доработки для этого потребуются? Объем?

Возможное решение:

• Проект в СППР2 — это конфигурация в реальном мире. База с несколькими так называемыми проектами — это проект в реальном мире. Можно переименовать синоним у справочника «Проекты» в «Конфигурации, расширения, смежные системы», чтобы никого больше никогда не путать.

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

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

• Загрузка объектов метаданных по расписанию есть в «коробке».

2. Проектирование интеграций в СППР2.

Вопросы:

• Как следует учитывать интеграции между системами в СППР2? Какие доработки потребуются для включения интеграций в логическую модель описания?

• Нет инструментов для проектирования интеграций между конфигурациями; у интеграции минимум две стороны — каждая находится в отдельном проекте. Как видеть интеграции как цельный механизм?

Решение:

Каждая сторона интеграции как отдельная конфигурация. Считаем, что сама с собой база через интеграцию не общается.

3. Механизм загрузки метаданных из ИБ.

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

Есть предложения по решению: https://infostart.ru/public/1585975/; https://infostart.ru/1c/articles/1585833/.

4. Механизм связи между изменениями в хранилище и задачами разработки.

Есть потребность в автоматизации формирования базы СППР2 на основании изменений исходного кода конфигураций и расширений. Идея заключается в том, что каждый коммит хранилища привязывается к идентификатору задачи разработки (например, в поле Комментарий или другим способом). Необходимо создать инструмент, который бы автоматически привязывал объекты метаданных к задачам разработки и техническим проектам. Также нелишним будет хранить и исходный код доработок. На одном из проектов мои коллеги решили эту задачу с помощью интеграции с git. Ввиду этого есть ряд вопросов:

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

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

• Возможно ли развернуть git на серверах заказчика на существующем проекте?

Решение:

На основании анализа коммитов хранилища можно бы было автоматически привязывать метаданные к задачам разработки и исходный код доработок — без этого ценность использования СППР2 сильно снижается.

Каждый коммит хранилища имеет комментарий, в котором указан код задачи Jira, по которой происходила доработка. Система могла бы сама проанализировать коммит, чтобы определить набор использованных метаданных. Задачи разработки привязаны к техпроектам в СППР2, на основании коммита можно бы было заполнить объекты метаданных техпроекта автоматически, плюс сохранить исходный код коммита в приложении к техпроекту. Это бы дало максимально полную информацию о доработках в СППР2. При этом для получения информации никакого ручного труда не требуется.

Перечень доработок прикладных решений

Итак, какие доработки в итоге требуются:

1. Интеграция Confluence – СППР2: две мини-конфигурации для выгрузки в XML и загрузки из XML; готовое API Confluence.

2. Интеграция Jira – СППР2: две мини-конфигурации для выгрузки в XML и загрузки из XML; готовое API Jira.

3. Доработка СППР2 для работы с объектами логической модели (документы, роли, функции и т. д.): проектирование структуры объектов, связи и отчеты.

4. Доработка СППР2 для работы с расширениями, мультипроектами, проектированием интеграций: добавление новых объектов, модификация механизмов загрузки метаданных, изменение метаданных, доработка интерфейсов.

5. Создание инструментов загрузки коммитов из хранилища, привязки метаданных к задачам разработки и техпроектам: существует несколько вариантов реализации — через интеграцию с git или путем парсинга файлов хранилища.

6. Доработка СППР2 в части учета изменения метаданных с историей задач разработки.

Заключение

Сейчас наша команда реализовала пилотный проект, где интеграция сделана в полуручном режиме. В ближайшее время мы планируем реализовать внутренний проект по доработке СППР2 и созданию компонентов интеграции, необходимых для полноценного использования инструментов с максимальной эффективностью. Мы видим живой интерес от заказчиков в получении структурированной базы знаний по результатам проекта, и СППР2 идеально подходит для этой цели — информационная база полностью отчуждаемая, содержит всю основную информацию о проекте, туда же можно дозагрузить всю техническую документацию проекта. Таким образом заказчик в результате проекта получает не только работающую систему и пачку документации, но еще и эффективный инструмент для сопровождения системы и ее развития собственными силами или же силами других подрядчиков.

Со временем, Confluence и Jira могут быть заменены на импортонезависимые решения, без изменения подхода к работе, — осталось только дождаться полноценных отечественных аналогов данных инструментов. Скорее всего, созданный продукт не будет выпущен на рынок в виде коробочного решения, но его использование будет включено в стандарт реализации проектов IBS и предлагаться заказчикам как один из значимых результатов проекта.