Comment les fichiers de configuration dynamiques peuvent économiser des heures et vous garder sain d’esprit

Online Coding Courses for Kids

Permutation sans tracas entre les environnements de développement et de production.

Que vous les utilisiez localement ou dans un pipeline CI / CD, il est très avantageux de basculer facilement entre les bases de données de production et de test.

Localement, je l’utilise beaucoup pour déboguer des erreurs dans notre système de production qui n’ont pas encore été transférées dans les bases de données de test. Cela me fait gagner beaucoup de temps chaque semaine.

Ce n’est pas quelque chose que vous voulez faire si cela peut être évité – mais avoir un commutateur facile garantit que je ne travaille jamais contre les mauvais serveurs ou bases de données. Auparavant, j’aurais dû échanger manuellement les URL et les mots de passe du serveur, ce qui a inévitablement conduit à une erreur humaine. Heureusement, je peux dire que je n’ai jamais mal gâché cela, mais cela s’est produit de temps en temps – assez pour que je me demande pourquoi un certain serveur ne m’a pas donné de résultats, avant de réaliser que mon système de production communiquait avec un service de test à distance .

Dans un pipeline CI / CD, l’avantage est clair – vous pouvez travailler de manière transparente avec les branches de fonctionnalités, les demandes d’extraction et la fusion dans la branche principale une fois que tout est testé. Ce serait un problème sans configuration dynamique.

Obtention d’informations d’identification

Avez-vous déjà reçu un avertissement lors de l’envoi d’un fichier à votre Github qui expose une clé API? C’est déjà assez grave quand cela se produit sur un projet privé – dans un système de production en direct, vous ne pourrez peut-être pas échanger vos informations d’identification sur un coup de tête lorsque plusieurs autres systèmes ont également besoin d’accéder.

De la même manière, vous pouvez masquer les noms d’utilisateur et les mots de passe, les chaînes de connexion à la base de données et tout ce qui pourrait être utilisé pour s’authentifier auprès des serveurs de votre entreprise. De cette façon, vous ne configurez cela qu’une fois dans les paramètres de votre pipeline créé pour les différentes branches, puis ne le touchez plus jamais. Vous pouvez même avoir des développeurs et des pigistes travaillant sur vos systèmes sans qu’ils aient à connaître les mots de passe réels.

Vous pouvez également travailler avec des magasins de clés qui s’exécutent localement pour authentifier des utilisateurs individuels par rapport au système plutôt que tout le monde utilisant un utilisateur de service. C’est juste une bonne idée, en général, de garder les mots de passe hors de votre code source.

Close Menu