<!-- .element: data-state="first-slide" --> ### Lightweight Architecture Decision Records  #### Plus jamais ça 🥺 #### LADR késako ? > Les LADRs sont de courts documents décrivant des choix techniques effectués sur des projets informatiques. > Leur but est de documenter les décisions prises, afin d'en constituer un historique. > Ils permettent également de partager la connaissance au sein d'une équipe, ainsi que de clarifier les choix de compromis effectués. Note: cet historique permet plus tard de prendre de nouvelles décisions d'architecture en pleine connaissance du contexte initial #### Motivations pour mettre ça en place - aide à la prise de décision "éclairée" <br><small>_Autres outils :_ une étude, un [2 pager](https://medium.com/@inowland/using-6-page-and-2-page-documents-to-make-organizational-decisions-3216badde909)</small> - faciliter la montée en compétence des nouveaux <br><small>_Autres outils :_ guide du nouvel arrivant, explications orales des _sachants_</small> - garder une trace de l'historique: contexte, choix <br><small>_Autres outils :_ commentaires dans le code & historique git... 😞</small> #### Un vieux concept remis au goût du jour [Request For Comments](https://fr.wikipedia.org/wiki/Request_for_comments) since 1969 : - [RFC 5424](https://tools.ietf.org/html/rfc5424) - [RFC 6202](https://tools.ietf.org/html/rfc6202) - les drôles : [RFC 2324](https://tools.ietf.org/html/rfc2324), [RFC 1149](https://rfc1149.net/rfc1149.html) #### Quelques principes de base - `git` friendly - édition / relecture en **asynchrone** - status & décision final <u>clairs</u> - contexte & conséquences <u>détaillées</u> Note: Markdown #### [LADR @ Hesperides](https://github.com/voyages-sncf-technologies/hesperides/tree/master/documentation/lightweight-architecture-decision-records) Morceaux choisis : - [Points d'accès dépréciés](https://github.com/voyages-sncf-technologies/hesperides/blob/master/documentation/lightweight-architecture-decision-records/deprecated_endpoints.md) - [Notre stratégie de tests](https://github.com/voyages-sncf-technologies/hesperides/blob/master/documentation/lightweight-architecture-decision-records/tests_strategy.md) - [Casse des identifiants dans l'API REST](https://github.com/voyages-sncf-technologies/hesperides/blob/master/documentation/lightweight-architecture-decision-records/letter_case_sensitivity_in_rest_api.md) - [Access control](https://github.com/voyages-sncf-technologies/hesperides/blob/master/documentation/lightweight-architecture-decision-records/access_control.md) #### LADR @ Avengers Mon équipe actuelle, en charge de l'usine logicielle. Ces LADRs ne sont pas publics, mais voici quelques-uns de leurs sujets : - Purge des buckets MinIO - définition de nos SLAs - working around DockerHub rate limit - Vault AppRole management \+ 🎉 inclu un template & une FAQ ! #### REX personnel - clarifie ++ les raisons des choix techniques - facilite le traitement différé de l'étude et de la réalisation des sujets - peu de recul encore sur l'aspect historisation Note: - moins de pert de temps du au _context switching_ & permet + facilement à qq1 d'autre de faire la réal - consensus Lead Techs : aucun point négatif #### Quelques conseils - un LADR n'est pas toujours plus efficace qu'une discussion d'équipe pour approfondir ou trancher un sujet - avoir un _process_ **clair** de traitement des LADRs - n'hésitez pas à glisser un peu d'humour / légèreté 😉 Note: - l'async a des limites, parfois une bonne vieille discussion orale est plus efficace - ex de process clair: MR avec 2 approvals & rôle du reviewer explicité #### C'est fini 😙 <small>Lucas Cimon - Octobre 2020</small> Article complémentaire : [Les ADR pour garder une trace de tous les choix d'architecture (Stack Labs)](https://blog.stack-labs.com/code/adr-to-remember-past-archiectural-decisions/)