Upfront design CICD

[juanrferia]

Hello,

By having a repo containing a workspace is quite simple to keep diagrams up to date in Structurizr OnPremises / Cloud by creating a CICD pipeline running structurizr-cli to push it for any new change in the model. That covers a way to have the As-Is architecture up-to-date. So far so good. However, there are cases in which I need to work on upfront design to better communicate architecture vision. For those cases, I would like to create a feature branch (like /design/abc...) in a way every change I made in the model for that branch is reflected in diagrams for that design. To my understanding, the best approach to get it is by creating a separate workspace. I found some challenges for implementing this appraoch:

1. I didn't find a way to automate workspace creation as part of the pipeline when that is running in the context of a "design" branch.
2. Even if I could, the new workspace will require different API key and secret, so running structurizr-cli is not possible if I don't know them.

I would appreciate your suggestions / recommendations for the best way to generate diagrams when working on upfront design. Thanks.

[simonbrowndotje]

The problem with having a build pipeline create workspaces via an API is that the URL for that workspace will always be changing. So, for this reason, my recommendation would be to create a workspace via the UI for a specific branch, and configure your pipeline to always that particular workspace.

All of that said, the hosted cloud service does have a user API that you can use to create (but not delete) workspaces -> https://structurizr.com/help/user-api

The on-premises installation does not have this feature though (see structurizr/onpremises#45).

[juanrferia]

Hello Simon. Thanks for your inputs.

I am specially interested on Structurizr OnPremise.

As a manual process, I understand I would need to:

1. Create a workspace via UI for the specific branch. The UI will present the apikey and secret related to the new workspace
2. Configure the pipeline to always use that workspace id, key and secret for that specific branch, instead of the main one.
3. In case I have a reason to cancel the new design, I would need to delete the branch and also manually delete the workspace via UI and pipeline config.

If I try to find potential automation opporunities, this is what is coming to my mind:

• Having something like a User API you described, pipeline could first try to get the worskpace related to the branch. For that, it would be great if workspace supports tagging or properties, so I would apply a custom one like branch:master, branch:design/abc. For getting the Worskpace, it would be great to support searching by tag or property.
• When getting the workspace, it would require so also get metadata including API key and Secret in a secure manner, so we pipeline use it to push via structurizr-cli.
• In case there is no worskpace yet for the branch, pipeline would need to create a new workspace, applying the mentioned tag or property.
• If a branch is deleted, pipeline could delete the worskpace related.

What are your thoughts about it? Do you see it could make sense to have those required features in your roadmap? As a summary, 1) worskpaces tags/properties; 2) API for searching worspaces by tag/properties; 3) API for getting worskpace metadata; 4) API for creating worskpace (with tags/properties); 5) API for deleting a worskpace

Thanks,

[simonbrowndotje]

The on-premises installation now has an "admin API" for listing/creating/deleting workspaces. See https://structurizr.com/share/18571/documentation#admin-api for details.

[juanrferia]

Hello Simon. Apologies, I missed your message. Sounds great. Does it cover all the needs I exposed or maybe partially? Thanks