Project Guardrails : écriture pour la production

Dans les derniers articles, j’ai parlé de quelques éléments (réservés pour l’écriture en production) qui aident à mener à bien un projet :

1. Les dangers du «design by commission »,
2. Considérations relatives au provisionnement d’un environnement.

La dernière chose que je veux aborder l’apprentissage que j’ai vécu jusqu’à présent concerne le maintien des clés proverbiales du royaume de l’écriture à la production et pourquoi cela est important.

Ecrire à la production

L’idée d’écrire à la production peut sembler être le garde-fou le plus dogmatique de ceux mentionnés, car cela convient généralement à ceux qui construisent la solution et ils connaissent les tenants et les aboutissants de son fonctionnement.

Les autres parties prenantes ne le font probablement pas (mais si elles le font et que l’équipe de développement est d’accord avec les autres qui utilisent le contrôle de version pour gérer cela, alors allez-y).

Qui a la permission d’administrer ce truc, vraiment ?

N’oubliez pas, cependant, comme mentionné précédemment dans cette série, la façon dont nous déployons nos projets a changé maintenant de sorte que nous avons souvent un déploiement continu et une intégration continue.

Et souvent, ces services sont connectés à un référentiel de code source, tel que GitHub, et à un système de messagerie (qui, à son tour, peut être connecté à Slack, ce que je trouve utile).

Pour que les membres de l’équipe sachent ce qui a été déployé et quand, et qu’ils sachent comment obtenir le code (qui provient du référentiel, et non en le téléchargeant via S/FTP) si nécessaire.

Lorsqu’un correctif est nécessaire, une procédure doit toujours être en place. Peut-être que quelqu’un est de garde et qu’il existe un processus par lequel la création de branches, la fusion, le balisage et la gestion sémantique des versions sont utilisés.

Quoi qu’il en soit, il ne s’agit pas tant de savoir comment le processus fonctionne ; c’est qu’il est en place et qu’il est suivi.

Bien sûr, ces choses ne sont pas mises en place pour rendre le développement plus compliqué (bien que je comprenne comment cela peut sembler ainsi). C’est au contraire. C’est pour diverses raisons :

• pour maintenir un déploiement continu, vous savez, continu,
• avoir des tests intégrés,
• mesurer en permanence les normes de codage ou la qualité du code,
• pour empêcher le codage de cow-boy,
• et plus.

Il ne s’agit pas tant d’empêcher les autres d’entrer, mais si c’est la responsabilité des développeurs de pousser le code, alors quelqu’un d’autre devrait-il vraiment avoir un accès en écriture au serveur ?

Et c’est l’essentiel : si vous travaillez dans une équipe où les processus que vous avez mis en place peuvent complètement saper le travail que vous faites, quel est le but du processus, de toute façon ?

Parce qu’à tout moment, quelqu’un d’autre peut arriver et cela sans tenir compte de tout ce que vous avez fait. Vous êtes alors, à tout le moins :

• coincé avec l’obligation d’extraire leurs modifications probablement via S/FTP,
• comparez-le à l’aide d’un outil de comparaison avec une branche sur laquelle quelqu’un travaille,
• mettre en œuvre les changements (encore découvrir pourquoi ils ont été apportés),
• puis se remettre au travail sur les exigences.

Cela semble mouvementé quand vous le dites comme ça, mais c’est exactement ce qui se passe.

Les plats à emporter

Alors, quel est le but de ces derniers messages ? Si je devais le résumer le plus succinctement possible, c’est :

Lorsqu’il s’agit d’un projet, connaissez vos responsabilités et ne les dépassez pas. Sinon, vous risquez de tout faire dérailler.

Cela vaut pour les développeurs, les concepteurs, les clients, les spécialistes du marketing, les chefs de projet, etc. qui est la véritable personne-ressource – le propriétaire du projet – pour l’ensemble du projet.

Ne sois pas comme ça.

Et selon la façon dont tout ce qui précède se déroule, le projet peut être un ensemble relativement simple de travail quotidien.

Autant que possible, ne voulons-nous pas profiter de ce que nous faisons