Relationship missing from deployment environments

[beffge]

In the deployment views, I get the relationships defined "globally" in the model (like expected). For the relationships of the deploymentEnvironments, only get the 4prod on the Production deployment view but not the 4dev on the Development deployment view. Is it me?

workspace {
    model {
        softwareSystem "system" {
            c1 = container "testContainer1"
            c2 = container "testContainer2"
            c3 = container "testContainer3"
        }
        c1 -> c2 "4all"
        deploymentEnvironment "Development" {
            deploymentNode "Node2" {
                ci1 = containerInstance c1
                ci2 = containerInstance c2
                ci3 = containerInstance c3
            }
            c2 -> c3 "4dev"
        }
        deploymentEnvironment "Production" {
            deploymentNode "Node1" {
                ci4 = containerInstance c1
                ci5 = containerInstance c2
                ci6 = containerInstance c3
            }
            c1 -> c3 "4prod"
        }
    }
    views {
        theme default
    }
}

[simonbrowndotje]

The order of lines is important with the DSL, and you're creating the the 4dev relationship after you've created the deployment environment, causing the relationship between ci2 and ci3 not to be created.

[beffge]

Ohhh, this makes sense now 🙈 I played a bit around with it and it's not how I envisioned it to work. So I guess this is a Layer 8 problem on my side 😉

I thought you can do deployment environment specific relationships i.e. 4all is on all deployment views, 4dev only on the development environment deployment view and 4prod only on the production environment deployment view.

[beffge]

Are deployment environment specific relationships possible?

[simonbrowndotje]

Not between container instances.

[beffge]

OK, I was able to get it done via tags (see below). Is it maybe worth thinking about including such a feature? Maybe realtionshipInstances as a pendant to containerInstances and systemInstances?

workspace {
    model {
        s1 = softwareSystem "system" {
            c1 = container "testContainer1"
            c2 = container "testContainer2"
            c3 = container "testContainer3"
        }
        c1 -> c2 "4all"
        c2 -> c3 "4dev" "" "dev"
        c1 -> c3 "4prod" "" "prod"
        // <identifier> -> <identifier> [description] [technology] [tags] { */
        deploymentEnvironment "Development" {
            deploymentNode "Node2" {
                ci1 = containerInstance c1
                ci2 = containerInstance c2
                ci3 = containerInstance c3
            }
        }
        deploymentEnvironment "Production" {
            deploymentNode "Node1" {
                ci4 = containerInstance c1
                ci5 = containerInstance c2
                ci6 = containerInstance c3
            }
        }
    }
    views {
        deployment s1 "Development" {
            include *
            exclude relationship.tag==prod
            autoLayout
        }
        deployment s1 "Production" {
            include *
            exclude relationship.tag==dev
            autoLayout
        }
        theme default
    }
}

[simonbrowndotje]

Is it maybe worth thinking about including such a feature? Maybe realtionshipInstances as a pendant to containerInstances and systemInstances?

Do you have a good real-world example of why this is needed? If I have two apps that can communicate at runtime, does that change depending on the deployment environment?

[beffge]

Sure. My idea is to showcase the current architecture of a system. Since the system evolves over time and different relationships are being developed, tested and finally go-live into production, those relationships might exist already on the development environment but not yet on the live/production environment.

For example, currently there might not yet be an integration of the App with Google as SSO provider but it's being developed and tested already. Therefore I'd add Google as SSO provider in the model but only want to see it and the relationship to it on the dev & testing environment but not yet in production.

I hope this helps 😇

[simonbrowndotje]

It does, and I'd recommend (1) tags as the way to deal with showing current state/future state (hiding/showing as needed), or (2) you have two versions of your workspace (e.g. on branches); one for current state, one for future state.

[beffge]

👍 thanks

I guess then I'll use tags. With regards to (2), doesn't this contradict the "model as code" (at least how I understood it) i.e. what is on your main page of Structurizr?

[...]allowing you to create multiple diagrams from a single model[...]

[simonbrowndotje]

doesn't this contradict the "model as code"

Not really. If a team is using branches for feature development, it may also make sense for them to include the documentation on those branches too, so the on-branch docs describe the on-branch code. Similarly, if you only have a main branch, you have to make a decision as to whether your documentation matches (1) what's in development, (2) what's in production, or (3) both. In all cases you're still creating multiple diagrams from a single model.

[beffge]

True. I guess you can see this as similar to the environment config in the repo with the code that should be deployed.

I can very much relate with this for teams having matching branches to the different deployment environments.

Other teams have all deployment environment in the main branch and the CD pipeline takes care on taking the correct configs and deploying the correct artefact. What I mean is, the code is always the same but the config changes depending on the environment. If we look at the c4model representing the documentation of the code, it should be one as well.

Nevertheless, both is valid and there is not one size fits all.

Thanks for the help and the discussion. Have a nice weekend!