любой

он же должен достаточно легко визуализироваться кмк

Как любой граф )

Впрочем, есть тонкости. В YAML можно делать include. Может быть DSL, который добавляет параметры, условия и циклы.

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

я не помню, сколько возможных паттернов в ямле, но их много, порядка пары сотен. Я сомневаюсь, что "вообще любой" ямл можно _просто_ преобразовать в граф (скажем, графвиз)

если наложить какие-то ограничения - то, наверное, можно

вообще не очень понятно по описанию "визуализировать yaml", о чём это
можно позанудствовать и сказать что вот в редакторе открыть это тоже визуализация

Вот что, а расскажи, что именно тебе важно видеть в этом описании инфраструктуры?

С какой задачей ты пойдёшь его смотреть?

Есть группы хостов поделенные по проектам,  средам, ролям

Инвентори

Всем привет,
кто нибудь сталкивался с задачей разработки требований под готовое "коробочное" API ? Вот есть платформа, которая позволяет на своей основе создавать интернет магазины / букинг сервисы / сервис для аренты чего угодно и пр.
Нужно написать требования под бизнес идею клиента. Я в лёгком тупике и не знаю, от чего отталкиваться.

привет! У меня была похожая задача, но на упрощенном уровне когда-то, когда еще пилил интернет-магазины или сайтики на wordpress.
Если ты эксперт в этой системе и хорошо знаешь API, структуру хранения, то можно ввязываться в такое. При этом нужно понимать, что какие-то поля ты будешь использовать не по назначению, скорее всего и это решится только докой к твоему решению... В общем, мое мнение, что надо быть экспертом.

ок, спасибо
я не эксперт в этой системе, но придётся разбираться

По идеи, знать API не нужно. Нужно написать требования так, будто система умеет все, потом отдать разработчикам, а они дадут feedback чего есть в API, чего нет, чтобы можно было скорректировать. Да, здесь есть элемент "двойной работы", но без этого не получиться. Я бы, если совсем нет знаний о системе, собрала бы для начала use cases, провалидировала с клиентом, опеделила MVP, а потом пошла бы к разработке.

Нужно написать требования так, будто система умеет все, потом отдать разработчикам, а они дадут feedback чего есть в API

вот здесь можно очень грубо промахнуться и придётся переписывать 90%

Нужно написать требования так, будто система умеет все, потом отдать разработчикам, а они дадут feedback чего есть в API

Возможно, я не понимаю сути задачи, но требования диктуются бизнесом, и если 90% из них нереализуемо на этом API - до свидания, API =)

как бы да, но если я заинтересован в конечном успехе проекта, то все равно придётся при написании документации ориентироваться на API, хотя бы в общих чертах

Э неееет.)))) Вот это как подгонка решения задачи под ответ в конце учебника.))) Если Вы заинтересованы, то есть смысл честно дать клиенту то, что вы можете. Пусть меньше, но лучше...Ну, если только у Вас не госзаказ, в который воды надо налить 😁 Но тут я точно не эксперт.)