c4k section decission
This commit is contained in:
parent
0fee2119a1
commit
6de8bd841d
3 changed files with 57 additions and 10 deletions
BIN
adr-c4k/project-section-artifact.png
Normal file
BIN
adr-c4k/project-section-artifact.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 22 KiB |
25
adr-c4k/project-section-artifact.puml
Normal file
25
adr-c4k/project-section-artifact.puml
Normal file
|
@ -0,0 +1,25 @@
|
||||||
|
@startuml
|
||||||
|
artifact common [
|
||||||
|
<b>c4k-common
|
||||||
|
---
|
||||||
|
contains commonly used stuff for Convention4Kubernetes modules.
|
||||||
|
===
|
||||||
|
|
||||||
|
predicates, config handling with aero, gopass resolution, yaml serialization and encoding.
|
||||||
|
]
|
||||||
|
|
||||||
|
artifact mbot [
|
||||||
|
<b>c4k-mastodon-bot
|
||||||
|
---
|
||||||
|
Module generating k8s deployments for mastodon-bot.
|
||||||
|
]
|
||||||
|
mbot -> common
|
||||||
|
|
||||||
|
artifact kc [
|
||||||
|
<b>c4k-keycloak
|
||||||
|
---
|
||||||
|
Module generating k8s deployments for keycloak.
|
||||||
|
]
|
||||||
|
kc -> common
|
||||||
|
@enduml
|
||||||
|
|
|
@ -1,23 +1,45 @@
|
||||||
# How is the c4k-project section?
|
# How is the c4k-project section?
|
||||||
|
|
||||||
|
|
||||||
This is the template in [Documenting architecture decisions - Michael Nygard](http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions).
|
|
||||||
You can use [adr-tools](https://github.com/npryce/adr-tools) for managing the ADR files.
|
|
||||||
|
|
||||||
In each ADR file, write these sections:
|
|
||||||
|
|
||||||
## Status
|
## Status
|
||||||
|
|
||||||
What is the status, such as proposed, accepted, rejected, deprecated, superseded, etc.?
|
accepted
|
||||||
|
|
||||||
## Context
|
## Context
|
||||||
|
|
||||||
What is the issue that we're seeing that is motivating this decision or change?
|
We need some place to collect common used code for our Convention4Kubernetes modules.
|
||||||
|
|
||||||
|
Discussion about project-section in general
|
||||||
|
* Value
|
||||||
|
* Smaller modules make it easier to cope with systems complexity
|
||||||
|
* test code seperately
|
||||||
|
* fewer people work on the same repo -> less merging
|
||||||
|
* Increase consistency by reusing code instead of creating redundancy
|
||||||
|
* enforces clearer architectur (decisions)
|
||||||
|
* separation of code along the different development velocities border.
|
||||||
|
* enforces architectural section
|
||||||
|
* Cost
|
||||||
|
* increase of systems complexity
|
||||||
|
* Dependency Hell / transitive dependencies
|
||||||
|
* Section requires good documentation
|
||||||
|
* more artifacts
|
||||||
|
* Worse Developer Experience
|
||||||
|
* Refactoring across multiple modules is hard to handle
|
||||||
|
* Debugging of seperate modules my be time-consuming (multiple layers)
|
||||||
|
* some coding tools (e.g. jump to definition) do not work over multiple repositories
|
||||||
|
* slower development roundtrip (e.g. when using repl)
|
||||||
|
* less awarness of what co-workes are commiting/working on
|
||||||
|
* Danger of naive projcet section
|
||||||
|
|
||||||
## Decision
|
## Decision
|
||||||
|
|
||||||
What is the change that we're proposing and/or doing?
|
[](project-section-artifact.png)
|
||||||
|
|
||||||
|
1. We move common used code (predicates for spec, config handling with aero, gopass resolution, yaml serialization and encoding) to c4k-common project.
|
||||||
|
2. For cli & web frontend code we accept redundancy till we've a clearer picture on how to extract commons
|
||||||
|
3. For postgres deployments we accept redundancy till we've a clearer picture on how to extract commons
|
||||||
|
|
||||||
## Consequences
|
## Consequences
|
||||||
|
|
||||||
What becomes easier or more difficult to do because of this change?
|
1. We can use described code in common.
|
||||||
|
2. After more experience we will decide about a changed section.
|
||||||
|
|
||||||
|
|
Loading…
Reference in a new issue