1С, СППР и Архитектура как код

01.02.24

Разработка - DevOps и автоматизация разработки

Можно ли идеи подхода «Архитектура как код» положить на 1С или иную платформу, чтобы не изобретать ещё какой-то язык и сразу получить множество готовых библиотек функций и инструмент достижения главной цели подхода AaC.

1С, СППР и Архитектура как код

 

Сейчас набирает популярность подход «Архитектура как код» (AaC).

Происхождением он обязан практикам devops «Инфраструктура как код» (IaC).

Идея подхода «Архитектура как код» состоит в том, что объекты архитектуры выражаются в виде формализованных структур со связями, что позволяет, создав некоторый язык программирования, управлять модификацией архитектуры программным кодом. Ну и, конечно, зажать архитектуру в некоторый унифицированный формат описания.

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

Формализация объектов архитектуры производится в виде простого текста в формате YAML, где объект представлен своими именем и реквизитами. Формат YAML позволяет привести проектирование архитектуры к подходам программирования, в т.ч. к контролю версий объектов наподобие git. Формализация объектов архитектуры вместе с их реквизитами позволяет рассматривать (и автоматизировано обрабатывать!) не только функциональные, но и нефункциональные требования.

Сейчас явно выделяются несколько независимых течений в сфере AaC, со своими форматами, языками и графическими движками. Очевидно, в ходе конкурирующего развития, останутся не все. Что-то станет общеуниверсальным стандартом. Или идея AaC заглохнет, либо маргинализуется среди небольшого числе последователей, хотя бы потому, что выгоды от выделения среди программистов кодеров, кодирующих для других кодеров, чтобы они понимали, что им кодировать, не вполне очевидны.

Какую цель преследует формализация архитектуры как кода? Точнее, какую должна преследовать?

Такой целью должна быть возможность автоматической проверки, соответствует ли системная реализация архитектурному замыслу.  Для этого необходимо, чтобы нормы AaC, как разновидность языка описания архитектуры (ADL), были интегрированы в жизненный цикл программного обеспечения.

У меня возникла мысль, а можно ли идеи  подхода «Архитектура как код» положить на 1С или иную платформу, чтобы не изобретать ещё какой-то язык и сразу получить множество готовых библиотек функций и инструмент достижения главной цели подхода AaC.

Вообще-то, специалисты признают, что «Архитектура как код» это маркетинговый слоган, теоретически и идеологически правильно называть этот подход «Архитектура как данные», но он, считается, менее понтово звучит. Тем не менее, в этом контексте близость AaC и 1С становится ещё сильнее.

Смотрим внимательно на AaC и видим, что объект+реквизиты это вообще-то стандартные метаданные 1С. По сути, архитектор-кодер даёт имя сущности (объекту) и даёт ему набор реквизитов и их значений. В этом контексте «описать объект архитектуры» означает:

 

 

  • дать объекту имя;
  • определить список его реквизитов;
  • заполнить реквизиты значениями;
  • определить связи объекта.

Ничего не напоминает?

Да, напоминает, если мы зададим объект как Документ, т.е. метаданное конфигурации 1С. Тогда, создав вид документа в конфигураторе и задав ему реквизиты, мы получаем интерфейс для объекта архитектуры. Переходим в платформу и можем описывать объекты архитектуры документами и заполнять реквизиты документа значениями.

Ну и где тут YAML?

Помним, что конфигурация 1С выгружается в XML-файлы по каждому объекту метаданных?

А что документы платформы могут выгружаться в тот же формат XML со значениями реквизитов?

Ну а YAML считается таким же форматом разметки, как XML, хотя и специально сильно упрощённым. Конвертер YAML/XML не вопрос сделать.

Что мы получаем при таком подходе?

  1. Язык обработки архитектуры.
    1. Это язык 1С.
      1. Хочешь - строй и модифицируй на нём объекты метаданных, хочешь - заполняй и меняй реквизиты объекта, хочешь - строй правила проверки архитектуры, объединяй виды объектов архитектуры в слои/структуры.
    2. Готовых специалистов по AaC со знанием языка.
  2. Готовый функционал управления разработкой архитектуры и кода разработки по аналогии с обычным кодингом для 1С на git-технологиях или в привычном конфигураторе/EDT.
    1. Возможность многопользовательской разработки архитектуры;
    2. Хронологические срезы состояния архитектуры как релизы.
  3. Готовый функционал платформы для обработки архитектуры.
    1. Версионирование (история данных) – аналог ветвей git для данных;
    2. Выгрузка прототипов (схем) YAML в виде XML из конфигурации;
    3. Планы обмена для выгрузки данных архитектуры в другие системы в XML(YAML) или для графической отрисовки;
    4. Импорт архитектурных описаний и списков универсальных архитектурных объектов/реквизитов из других систем через тот же план обмена;
    5. Документирование через поля комментариев и/или справку;
    6. Резервное копирование;
    7. Механизм ввода на основании, как связь между объектами архитектуры, лежащими в одном горизонтальном слое. В платформе это будет наследование реквизитов с обработкой или без обработки их значений;
    8. Механизм дополнительных свойств для описания вертикальных связей объектов архитектуры.
    9. Отчёты для обзора архитектуры и её данных.
  4. Выгрузка в СППР для увязки требований к архитектуре с её описанием.
  5. Возможность описания архитектуры не1С-систем в 1С в едином массиве с конфигурациями 1С.
    1. Ведь для описания архитектуры важно имя сущности, а не  что она заключена в стандартный 1С объект метаданных «Документ».

Чего не хватает?

  1. Не хватает графического описания архитектуры.  У 1С с этим бедно. Можно воспользоваться отрисовкой IDEF0 в СППР, ER диаграммой в EDT. Можно попытаться приспособить табличные или графические отчёты. Но, скорее всего, лучшим решением будет выгрузка для отрисовки в DocHub или Archimate или аналогичный продукт/сервис.
  1. Не хватает функционала по осуществлению главной функции AaC – проверке соответствия архитектуры её исполнению.

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

Буду признателен за обратную связь.

Архитектура проектирование код AaC СППР

См. также

Автотесты для типовых конфигураций ERP Управление предприятием 2 и Комплексная автоматизация 2 (для vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Комплексная автоматизация 2.х Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарии возможно использовать как для vanessa-automation, так и для СППР. Поддерживаемые версии конфигураций ERP2 и КА2: 2.5.15.111.

2220 руб.

04.07.2022    7064    26    1    

24

Управление сборкой. Расширение для конфигурации СППР

DevOps и автоматизация разработки Платформа 1С v8.3 Конфигурации 1cv8 1С:Франчайзи, автоматизация бизнеса Платные (руб)

Подсистема «Управление сборкой GLI» предназначена для динамического формирования сборочных линий Gitlab и отслеживания процесса доработок систем на базе1С:Предприятия Позволяет упростить выпуск новых релизов системы, подготовить описание доработок системы. Интегрируется с GitLab API по событиям Push, Merge-request, Pipeline. Уведомляет пользователей о результатах сборки/тестирования сборочных конвейеров через СВ, либо при её недоступности или отсутствию по E-Mail. Поможет при отправке исправлений ошибок в общую базу тестирования, сформирует запросы на слияние в ветку версии только по протестированному и подтверждённому функционалу. Подсистема рассчитана исключительно на клиент - серверную архитектуру тестовых ИБ. Поддерживаемая версии СППР 2.0.4.15, платформа не ниже 8.3.17.1549, 2.0.7.3 / не ниже 8.3.21.1664, начиная с релиза 1.0.4.30 требуется платформа не ниже 8.3.23 рекомендуемый релиз 8.3.23.1997

7000 руб.

26.08.2022    11017    8    5    

31

Системы контроля версий для 1С-разработчиков.

1С-программирование DevOps и автоматизация разработки Групповая разработка (Git, хранилище) DevOps для 1С Платформа 1С v8.3 Платные (руб)

Основы командной разработки на 1С. Использование систем контроля версий при разработке на платформе 1С:Предприятие 8

4900 руб.

29.06.2022    9652    79    4    

113

Автоматическое подтверждение легальности обновления базы или как обновить 100 типовых баз 1С за 5 часов

DevOps и автоматизация разработки Обновление 1С Платформа 1С v8.3 Конфигурации 1cv8 1С:Бухгалтерия 3.0 1С:Зарплата и Управление Персоналом 3.x Абонемент ($m)

Расширение для конфигураций 1С для автоматического подтверждения легальности обновления и выполнения обработчиков обновления при пакетном автоматическом обновлении большого числа баз 1С. А также сам модуль обработки по автоматическому обновлению баз.

2 стартмани

08.05.2019    24633    58    VPanin56    26    

28

Автотесты для типовых конфигураций Бухгалтерия предприятия КОРП 3.0 и Бухгалтерия предприятия 3.0 (vanessa automation)

Тестирование QA DevOps и автоматизация разработки Платформа 1С v8.3 1С:Бухгалтерия 3.0 Россия Бухгалтерский учет Налоговый учет Платные (руб)

Готовые тестовые сценарии, предназначенные для регресс-тестирования функционала конфигурации после обновления типовым релизом. Сценарии проверяют интерактивное заполнение форм документов, справочников и результат проведения документов. Сценарий – feature-файл, разработанный с помощью vanessa-automation. Запуск сценария выполняется интерактивно с помощью vanessa-automation или с помощью vanessa-runner в CI-системах. Доступно тестирование тонкого клиента. Поддерживаемые версии конфигураций 1С:Бухгалтерия предприятие 3.0 и версии КОРП: 3.0.152.28.

1728 руб.

20.01.2022    6808    11    0    

10

TCP прокси-сервер хранилища конфигурации 1С

DevOps и автоматизация разработки Групповая разработка (Git, хранилище) OneScript Платформа 1С v8.3 Бесплатно (free)

Продолжение истории с прокси хранилища, но уже не на HTTP, а на TCP и без падений по памяти веб-сервера. Проверяем комментарии хранилища, вызываем веб-хуки, старты пайплайнов, gitsync по событию помещения версии в хранилище. И все это полностью на знакомом и понятном OneScript.

17.01.2024    3306    kamisov    19    

61

Infrastructure as code: кнопка «Сделать всё», или Упаковываем наше окружение в 5 кБ текста

DevOps и автоматизация разработки Бесплатно (free)

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

01.11.2023    1511    Libelle    5    

14

Обработка для подготовки файла настройки дымовых тестов измененных объектов конфигурации

DevOps и автоматизация разработки Тестирование QA Россия Абонемент ($m)

В статье приведен пример обработки, которая на основании измененных файлов git-репозитория готовит специальный файл настройки xUnitParams.json для последующего выполнения дымовых тестов (xUnitFor1C/add) только для измененных объектов конфигурации

1 стартмани

09.10.2023    832    5    ICL-Soft    1    

4
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. oleshko_alexey 2 01.02.24 15:18 Сейчас в теме
У меня возникла мысль, а можно ли идеи подхода «Архитектура как код» положить на 1С или иную платформу, чтобы не изобретать ещё какой-то язык и сразу получить множество готовых библиотек функций и инструмент достижения главной цели подхода AaC

А зачем здесь 1С?
Dochub в git все хранит, картинки рисует , а в 1С нужно весь стек переписывать

Алексей Лустин экспериментировал использовать OScript для обертки С4 Model -
Для 1Сников в эту сторону стоит копать.



OScript Enterprise Architect (OMyGod)
DRAFT - отлаживаю концепцию по работе, структурирую API

имплементация языка проектирования 4-рёх уровней архитектуры в стиле O-AAA

Ключевой момент Я российский архитектор, проектирую архитектуру для российского заказчика, и если код команды программистов буду писать на янглийском, то уж техническое задание по ГОСТу мне придется писать точно на русском. Поэтому и архитектуру я должен описывать на русском.
2. roman72 381 01.02.24 16:42 Сейчас в теме
(1) И как в этих решениях с ответом на главный вопрос - как автоматизированно проверить соответствие архитектурных задумок фактическому воплолещению?

В git хранятся версии архитектурных описаний всего лишь...
5. investec 01.02.24 21:58 Сейчас в теме
(1)
OScript Enterprise Architect (OMyGod)


Какова судьба "OScript Enterprise Architect (OMyGod)"?
6. oleshko_alexey 2 02.02.24 11:52 Сейчас в теме
(5) Алексей убрал из доступа проект на github (убрал вообще все публикации, видео и соц. сети)

судя по тому что он активен в Jazz на DocHub вебинарах - OMyGod - не актуален.
8. roman72 381 03.02.24 12:26 Сейчас в теме
(6) И в чём причина этого?
3. oleshko_alexey 2 01.02.24 19:12 Сейчас в теме
В августе Сберфакторинг рассказывал в видео как они восстанавливали архитектуру рабочего проекта по данным логов, которые добавили в каждый сервис. И затем все изменения по логам отслеживаются

С большим удовольствием делюсь с вами записью митапа "Архитектурная руда" от Сбербанк Факторинг состоявшегося 9 августа 2023г.

https://www.youtube.com/watch?v=yp4PgZUYBZY

Большое спасибо Юле за доклад!
4. oleshko_alexey 2 01.02.24 19:16 Сейчас в теме
1, 2, 3 Из "Руды"
Прикрепленные файлы:
7. user-z99999 68 02.02.24 12:26 Сейчас в теме
Когда уборщицы будут визуально программировать,
сама программа будет терять в скорости работы.
Но если покупать всё мощнее и мощнее железо для этих игр, то почему бы нет)))

Если разве что, для аналитиков. Что-то очень быстро накидать, прикинуть, показать.
А для хорошей скорости программы, услуги программистов всегда будут востребованы.
9. roman72 381 03.02.24 12:31 Сейчас в теме
(7) Никто речь не ведёт о том чтобы избавиться от программистов через автоматизацию описания архитектуры.
Архитектура касается не только программного кода, но и иных операций,
например:
нужно описать интеграцию между несколькими системами, определить список интгерируемых данных, направления обмена, нагрузк уна каналы обмена.
Кода ещё никакого нет, а архитектура уже есть. И её описание весьма трудоёмко. Поэтому нужна автоматизация уже здесь.

А что касается архитектуры непосредстенно ПО - программистам нужен внятный и понятный вектор "как работать, в какую сторону писать код, как и что связано на функицональном уровне в зависимости от кода" - архитектура как такой вектор весьма необходима.
Оставьте свое сообщение