Le dépôt fait foi
Les faits vivent dans des fichiers simples, à côté du code qu’ils décrivent. Pas de base de données, pas de service de catalogue. Les modèles dans le dépôt, les données là où elles doivent être.
Les connaissances de l’organisation, maintenues exactes par un compilateur.
Qui est responsable de quel service. Qu’est-ce qui dépend de quoi. Le knowledge as code place ces faits dans git, les fait relire dans des pull requests et laisse un compilateur rejeter ceux qui cessent d’être vrais. Il rend les faits modélisés plus faciles à relire et à maintenir dans le temps.
Cette approche est mise en œuvre dans Cueto, open source sur GitHub. Cueto est un système que Stratorys a construit pour son propre usage, et non dans le cadre d’une mission client. Cette étude documente donc une conception et ne contient ni données ni noms de clients.
Personne n’a menti. Les faits sont simplement devenus obsolètes.
Un wiki peut indiquer qu’Alice est responsable du service de facturation longtemps après son départ. Écrivez cette responsabilité comme une référence typée plutôt que comme une chaîne de caractères, et la référence peut être vérifiée par rapport aux personnes enregistrées dans le système. Retirez-la de cet enregistrement, et le build peut échouer dans la même pull request.
Comment fonctionne le knowledge as code.
Six éléments qui transforment des faits dispersés en un référentiel dont un compilateur peut garantir la cohérence.
Votre vocabulaire
Vous décidez de ce qui existe dans votre monde : équipes, services, jeux de données. Rien n’est imposé, car les équipes n’entretiennent que les schémas dont elles sont propriétaires.
Composition
Les packages de différentes équipes fusionnent en une vue unifiée, sans coordinateur central. La vue de l’organisation entière est dérivée, jamais écrite à la main.
La membrane
La CI valide chaque changement. Les références sont typées par rapport à ce qui existe réellement, de sorte qu’un changement qui en casse une est rejeté à l’entrée.
Pipelines
Les imports provenant des systèmes RH, des wikis et des entrepôts convergent vers le dépôt et passent les mêmes vérifications que toute modification humaine.
Historique et relecture
Git est l’archive, la pull request est la relecture. Il n’était pas nécessaire de réinventer le versioning.
Des connaissances vérifiées à chaque changement.
Les vérifications s’exécutent sur chaque changement proposé. Les agents et les humains très sollicités continuent d’ajouter des faits, et les références modélisées qui deviennent invalides peuvent faire échouer le build au lieu de dériver silencieusement.
Adopter le knowledge as code.
L’adoption est incrémentale, et chaque étape se justifie d’elle-même.
01
Commencer par un domaine
Choisissez les faits qui deviennent obsolètes le plus vite, généralement la responsabilité des services, et n’encodez que ceux-là. Un domaine, quelques fichiers.
02
Activer la membrane
La CI vérifie chaque pull request dès le premier jour. La dérive cesse de s’accumuler dès l’exécution de la première vérification.
03
Connecter les sources
Les pipelines peuvent importer depuis les systèmes que vous utilisez déjà, tandis que les changements restent soumis aux mêmes vérifications.
Encoder les connaissances sous forme de code est un travail concret que nous réalisons dans le cadre de missions de réalisation . Pour découvrir un autre système que nous avons conçu et livré, consultez l’étude de conception PR Triage .
Vous vous demandez si cela convient à votre organisation ?
Nous examinerons où vivent vos connaissances aujourd’hui et où leur encodage serait le plus utile en premier.