Add organizational implementation and best practices documentation#552
Add organizational implementation and best practices documentation#552sofusalbertsen wants to merge 1 commit intomainfrom
Conversation
dangrondahl
left a comment
dangrondahl
left a comment
There was a problem hiding this comment.
Left some comments on "Best practice"
| * CD part: name your flow "release-name" | ||
| * Trail: | ||
| * Default to SHA | ||
| * Others could be release version (Git tag), merge number etc. |
There was a problem hiding this comment.
Could also be covered by Semantic Versioning, e.g:
v1.0.0-[build]+[sha]
|
|
||
| Centralized pipelines means that you will get a lot of flows based on the same template. | ||
|
|
||
| Solution; Add tags to your flows so that all with the same "template" will have the same tag. In that way you do not need to know the name, but can evaluate based on tags. |
There was a problem hiding this comment.
We could consider if tagging should have it's own section or page, since it spans different resources (envs, flows, etc.).
Only page I find on tagging is:
https://docs.kosli.com/client_reference/kosli_tag/
Which is more CLI reference than conceptual. Also reported this small bug on the page:
#553
|
|
||
| An example of that would be the Cyber-Dojo environment policy repository on [Github](https://github.com/cyber-dojo/kosli-environment-policies). | ||
|
|
||
| In that repository we have four poilicices attached: |
There was a problem hiding this comment.
| In that repository we have four poilicices attached: | |
| In that repository we have four policices attached: |
|
|
||
| When creating policies, we have found it best to split up policies into their logical units. That way, it is easier to maintain and understand the logical connection between requirements. | ||
|
|
||
| An example of that would be the Cyber-Dojo environment policy repository on [Github](https://github.com/cyber-dojo/kosli-environment-policies). |
There was a problem hiding this comment.
Idea for future considerations:
- Create a
kosli-dev/policy-storerepo - Store has templates for common policies (Go templating)
- A functionality (in the CLI) to point to a template and interactively create policy from input.
There was a problem hiding this comment.
This is something I'd like to discuss - we need a way to "promote" custom attestation types we see again and again to be more built in - without needing to do CLI/Server development.
There was a problem hiding this comment.
@sofusalbertsen have also mentioned Rego/OPA for this. This will perhaps standardize policy definitions, which I see as a good thing. From what I've heard (haven't tried it much myself), Rego has a somewhat steep learning curve.
So it still might make sense to provide common policies (in this format), in some kind of store, for customers to consume?
| ## Naming convention | ||
|
|
||
| * Flows: | ||
| * CI part: name your flows like "repo"/"application". |
There was a problem hiding this comment.
/ is not allowed in flow names.
There was a problem hiding this comment.
in cyber-dojo, Jon has been using a -ci suffix for now
|
@sofusalbertsen Seems like this PR went stale, should it just be closed or rethought given new structure? |
3 participants
No description provided.