mirror of
https://github.com/SAP/jenkins-library.git
synced 2024-12-14 11:03:09 +02:00
e44aaf86e4
* chore: prepare setup for future ADRs * Update build-adr.yml
1.9 KiB
1.9 KiB
Use Markdown Architectural Decision Records
- Status: accepted
- Date: 2022-10-03
- Tags: doc
Context and Problem Statement
We want to record architectural decisions made in this project. Which format and structure should these records follow?
Considered Options
- MADR 2.1.2 with Log4brains patch
- MADR 2.1.2 – The original Markdown Architectural Decision Records
- Michael Nygard's template – The first incarnation of the term "ADR"
- Sustainable Architectural Decisions – The Y-Statements
- Other templates listed at https://github.com/joelparkerhenderson/architecture_decision_record
- Formless – No conventions for file format and structure
Decision Outcome
Chosen option: "MADR 2.1.2 with Log4brains patch", because
- Implicit assumptions should be made explicit. Design documentation is important to enable people understanding the decisions later on. See also A rational design process: How and why to fake it.
- The MADR format is lean and fits our development style.
- The MADR structure is comprehensible and facilitates usage & maintenance.
- The MADR project is vivid.
- Version 2.1.2 is the latest one available when starting to document ADRs.
- The Log4brains patch adds more features, like tags.
The "Log4brains patch" performs the following modifications to the original template:
- Change the ADR filenames format (
NNN-adr-name
becomesYYYYMMDD-adr-name
), to avoid conflicts during Git merges. - Add a
draft
status, to enable collaborative writing. - Add a
Tags
field.
Links
- Relates to Use Log4brains to manage the ADRs