Suivi efficace des modifications de la configuration du développeur au prod

Cette question prend un service Spring Boot comme exemple, mais il peut s'agir de n'importe quelle technologie.

En supposant ce qui suit:

• Les environnements (dev / QA / prod) appartiennent à différentes équipes. Cela signifie que le développeur ne doit pas avoir accès à la configuration de prod.
• La configuration (disons application.properties) est externalisée, c'est-à-dire qu'elle ne fait pas partie du binaire
• Le même binaire / package (disons service.jar) est déployé dans chaque environnement et contrôlé par un déploiement automatisé

Alors que les modifications apportées à l'artefact binaire (service.jar) sont automatiquement propagées à chaque environnement, les modifications de configuration nécessitent toujours une intervention manuelle, qui finit inévitablement par être désynchronisée dans chaque environnement.

Par exemple, supposons que l'équipe de développement ajoute quelques paires clé-valeur à application.properties dans leur environnement. Quelle serait la meilleure façon d'enregistrer ces nouvelles clés, afin que lorsque le déploiement se produit dans l'équipe des opérations, elles sachent exactement quelles clés ajouter, de sorte que le risque de démarrer le nouveau service et de le voir échouer en raison d'une clé manquante soit minimisé?

Je sais qu'il y aura des étapes manuelles impliquées, mais j'aimerais savoir comment les gens gèrent cela et trouver le moyen le plus efficace.

Il s'agit principalement d'un problème de communication, mais vous pouvez faire des erreurs moins probables par quelques mesures techniques et organisationnelles simples. Tout d'abord, vous devez fournir une documentation de haute qualité de toutes les entrées de vos fichiers de configuration, ainsi qu'un exemple facilement accessible ou un fichier de configuration «par défaut». Le fichier d'exemple peut être déployé automatiquement dans chaque environnement, car il n'est pas destiné à être modifié directement par l'équipe de prod.

Ensuite, avec chaque nouvelle version, fournissez un journal des modifications, où les changements importants sont documentés. Les modifications de la configuration qui pourraient empêcher le système de fonctionner lorsqu'elles sont manquantes sont toujours importantes, alors assurez-vous que les informations sont là.

Par exemple, supposons que l'équipe de développement ajoute quelques paires clé-valeur à application.properties dans leur environnement. Quelle serait la meilleure façon d'enregistrer ces nouvelles clés, afin que lorsque le déploiement se produit dans l'équipe des opérations, elles sachent exactement quelles clés ajouter, de sorte que le risque de démarrer le nouveau service et de le voir échouer en raison d'une clé manquante soit minimisé?

La meilleure façon de réduire le risque d'échec est d'éviter de modifier votre application d'une manière qui nécessite les nouvelles clés, de sorte que l'application doit être rétrocompatible avec les anciens fichiers de configuration chaque fois que possible. Souvent, votre application peut se comporter de manière sensée en fournissant des valeurs par défaut intégrées pour les nouvelles clés pour le cas où elles sont manquantes.

Cependant, si cela n'est pas possible, votre système devrait permettre à l'équipe de production de découvrir le plus facilement possible pourquoi le nouveau service ne démarre pas lorsque la clé est manquante. Il devrait y avoir un message d'erreur clair, indiquant exactement quelle clé est manquante dans quel fichier , et si nécessaire où trouver les informations sur la clé manquante, ou un indice ou un exemple sur une entrée significative pour cette clé.

Si la configuration est complexe et que le format change d'une manière dont l'édition manuelle devient sujette aux erreurs, vous pouvez également envisager de fournir des outils pour éditer les configurations et pour la migration vers une version plus récente.

Par exemple, j'utilise le navigateur Web Firefox, et avec chaque nouvelle version (que j'obtiens automatiquement), certaines choses sont ajoutées à la configuration locale que l'on peut inspecter sur la page "about: config". Ceci est comparable à la configuration de votre environnement de "production". Étant donné que l'ensemble de la configuration est strictement rétrocompatible, je n'ai jamais à ajouter de nouvelles clés à la configuration manuellement simplement parce qu'il existe une nouvelle version du navigateur. Et pour le cas où je veux changer quelque chose là-bas (peut-être une nouvelle entrée qui ne faisait pas partie de la version précédente), j'utilise le menu Outils / Options ou la page "about: config", et je peux trouver l'entrée plus quelques type de documentation. Je recommande donc d'essayer d'implémenter votre système d'une manière comparable.

À un endroit où j'ai travaillé, ils avaient un problème similaire. La configuration de la production était contrôlée par l'équipe de construction, seulement elle y avait accès dans le référentiel de code. Les configurations dev, qa, test, etc ... peuvent être vues par tous.

Dans votre exemple, un développeur mettrait à jour le fichier localement, l'archiverait au contrôle de code source, puis quelqu'un demanderait à l'équipe de génération de créer une nouvelle génération "config only" qui extrait les fichiers de configuration et les déploie, mais ne recompile pas ou redéployez l'application entière.

Il appartenait aux membres de l'équipe de mettre à jour les fichiers de configuration pour d'autres environnements au moment opportun. Lorsqu'il était temps de mettre à jour pour la production, l'équipe de construction devait mettre à jour le fichier, via une demande explicite du responsable de l'équipe de développement, bien que généralement la demande ressemblait simplement à "copier le fichier app.config de QA1 vers PROD". Les éléments sensibles tels que les mots de passe se trouvaient dans un fichier de configuration distinct et, encore une fois, seule l'équipe de génération pouvait accéder au fichier de mots de passe de production. La différence est que les développeurs ne généralement pasdemander des modifications aux fichiers de mots de passe car ils n'auraient pas eu de mots de passe de production. La seule fois où ils demandaient à l'équipe de construction de la mettre à jour, c'était lors de l'ajout d'un nouveau mot de passe pour un nouveau service. Et même alors, les développeurs ne connaîtraient probablement pas le mot de passe de production, ils ne connaîtraient que la clé à ajouter au fichier (comme "newService2.password").

Jenkins était la technologie utilisée pour gérer une grande partie de cela. Il y avait aussi un outil interne qui était utilisé pour demander et planifier des builds via Jenkins.