ADR-0001: Use Log4brains to manage the ADRs
- Status: accepted
- Date: 2024-05-08
- Tags: dev-tools, doc
Context and Problem Statement
We want to record architectural decisions made in this project. Which tool(s) should we use to manage these records?
Considered Options
- Log4brains: architecture knowledge base (command-line + static site generator)
- ADR Tools: command-line to create ADRs
- ADR Tools Python: command-line to create ADRs
- adr-viewer: static site generator
- adr-log: command-line to create a TOC of ADRs
Decision Outcome
Chosen option: “Log4brains”, because it includes the features of all the other tools, and even more.
ADRs
You can view the ADRs by browsing this following list:
- ADR-0001: Use Log4brains to manage the ADR
- ADR-0002: Use Markdown Architectural Decision Records
- ADR-0003: VSecM Will Be Scoped to Work on Kubernetes Only
- ADR-0004: Be Practically Secure
- ADR-0005: Be Resilient by Default
- ADR-0006: Be Secure by Default
- ADR-0007: Document All Public Methods
- ADR-0008: Have a Minimal and Intuitive API
- ADR-0009: Have at Least 50% Test Coverage Across the Project
- ADR-0010: Keep Non-Public Function in Separate Files from the Public Functions
- ADR-0011: Keep Things Minimal: Do One Thing Well
- ADR-0012: All Files Shall Have a SPDX License Header
- ADR-0013: Scan the Codebase for Vulnerabilities and Code Smells Regularly
- ADR-0014: Get OpenSSF Best Practices Compliance
- ADR-0015: Keep Source Code Line Length Around 80 Characters
- ADR-0016: Centralize Magic Words, Numbers, and Configuration Constants in Common Modules
- ADR-0017: VSecM OIDC Resource Server Shall Be Secure by Default“
- ADR-0018: Use Asciinema for Use Case Examples in the Documentation“
- ADR-0019: Use RESTful APIs for Communication Between Components
- ADR-0020: VSecM will not enforce expiration and invalid before time for secrets
- ADR-0021: VSecM Shall Use Environment Variables for Configuration
- ADR-0022: VSecM Shall Use the Latest Stable Dependencies