Template for ADRs
Decision
We write ADRs in English.
Problems
Currently, there is no good way in which we can monitor our systems in real time. This makes harder to check if the deployed systems are working as expected and because of this, is hard quickly to react when there are errors in our servers.
Context
We already tried to enhance our testing pipeline by using this package which proved not to be reliable due to some memory-leak issues. The package and implementation were introduced here: PR
Options
The following packages were considered
Reasoning
We decided for this framework, because it is the only one that everyone on the team is already familiar with.
Consequences
How do we implement this change?
We currently have 120 controller classes which need to be upgraded to the new structure. We plan to support both implementations until this ADR is full implemented so we can release the changes in small iterations. Here is an example of how a controller will be migrated:
... some code example ...
Additionally, we need to move all the controllers to a new folder: /path/to/folder.
Who will implement the change?
The Deliver team will move the parameter file to TypeScript as part of their
current work on the parameter file, and share their learnings afterwards.
How do we teach this change?
Tim will run a workshop on this new library at the next Learning Friday
What could go wrong?
Not having an extensive central review for each dependency leaves us open to some software supply chain attacks.
What do we do if something goes wrong?
Since the plan is to only deprecate the current APIs, and remove it after 3 months after the new library is added and used everywhere, reverting the changes would mean to switch back to the deprecated API. If we roll back after the deprecated API is deleted, then we revert the commits that removed it and use it again.
What is still unclear?
Do we need different types of ADRs with more specific questions, e.g. new frameworks vs. new processes?