Question: how to manage local overrides?

[amacleay-cohere]

I think the intended lifecycle for hosting and managing an internal maturity model is:

• Fork DevSecOps-MaturityModel-data and DevSecOps-MaturityModel
• Put local changes to activity definitions for default activities in a corresponding custom activity; eg overrides to src/assets/YAML/default/BuildAndDeployment/Build.yaml go in src/assets/YAML/custom/BuildAndDeployment/Build.yaml
• Put local changes to team structure in src/assets/YAML/meta.yaml
• Put a build-and-publish workflow around DevSecOps-MaturityModel-data
• Put a build-and-publish workflow around DevSecOps-MaturityModel that grabs meta.yaml and generated.yaml from DevSecOps-MaturityModel-data and mounts/copies them into the site

Please correct if that doesn't seem ideal.

This still leaves me with some questions:

• Evidence is explicitly removed from the YAML file generation: https://github.com/devsecopsmaturitymodel/DevSecOps-MaturityModel-data/blame/f028130/yaml-generation/functions.php#L85 - What asset should one use to track this? Just in the default YAML files?
• It seems a little bit odd that meta.yaml doesn't have a build process and is just identically copied into the site - am I misunderstanding the intended lifecycle for that asset?

Thanks in advance!

[amacleay-cohere]

I just saw you opened https://github.com/devsecopsmaturitymodel/DevSecOps-MaturityModel/issues/314 - this question seems to overlap quite a lot so feel free to close if you think that's going to be addressed another way @wurstbrot

Thanks!

[wurstbrot]

@amacleay-cohere the workflow is correct. The first question is answered with the ticket. @0x41head is about to implement it in the next couple of weeks (not guarantee as it is OpenSource).

Regarding the second question: Ideally, you add the teams to meta.yaml and mount it to your container. What workflow would you pref.?

[amacleay-cohere]

Regarding customizations to meta.yaml - I might expect a similar workflow with a default meta.yaml that gets merged with a custom meta.yaml.

I actually don't have any real preference, it is just a bit confusing to navigate as there are multiple checked in meta.yaml files (in the -data project and the site project) and, as a consumer, it's hard to know if there is a reason to prefer managing changes in one or the other. I think the answer is "there's more than one way to do it", and that's totally fine.

Thanks for the responses and the great work!