Mon collègue s'engage et pousse sans tester
Lorsque mon collègue pense qu'il n'est pas nécessaire de faire un test sur son PC, il apporte des modifications, s'engage et pousse. Puis il teste sur le serveur de production et se rend compte qu'il a fait une erreur. Cela arrive une fois par semaine. Maintenant, je vois qu'il a fait 3 commits et et pousse avec déploiement sur le serveur de production dans les 5 minutes.
Je lui ai dit plusieurs fois que ce n'était pas ainsi que l'on faisait du bon travail. Je ne veux plus être impoli avec lui et il est dans la même situation que moi dans l'entreprise et il a travaillé plus que moi ici.
Je veux que ce comportement soit puni d'une manière ou d'une autre le rende aussi désagréable que possible.
Avant de commencer, la société déployait en utilisant des méthodes anciennes, telles que FTP, et il n'y avait aucun contrôle de version.
Je les ai forcés/nous à utiliser Git, Bitbucket, Dploy.io et HipChat. Le déploiement n'est pas automatique, quelqu'un doit se connecter à dply.io et appuyer sur le bouton de déploiement.
Maintenant, comment puis-je les forcer à ne pas tester sur le serveur de production? Quelque chose comme le bot HipChat peut sentir qu'il y a des modifications répétées sur la même ligne et envoyer une notification au programmeur.
Vous avez besoin d'un processus d'assurance qualité (AQ) approprié.
Dans une équipe de développement de logiciels professionnels, vous ne passez pas du développement à la production. Vous disposez d'au moins trois environnements distincts: développement, mise en scène et production.
Lorsque vous pensez que quelque chose fonctionne dans votre environnement de développement, vous passez d'abord au staging, où chaque validation est testée par l'équipe QA, et seulement si ce test réussit, il est poussé en production. Idéalement, le développement, les tests et la mise en production sont effectués par des personnes distinctes. Cela peut être assuré en configurant votre système d'automatisation de génération d'une manière que les développeurs ne peuvent déployer que du développement à la mise en place et que l'équipe QA ne peut déployer que de la mise en place à la production.
Lorsque vous ne pouvez pas persuader la direction d'embaucher quelqu'un pour faire votre AQ, alors peut-être que l'un de vous peut jouer ce rôle pour l'autre. Je n'ai jamais travaillé avec diploy.io, mais certains systèmes d'automatisation de construction peuvent être configurés de manière à ce qu'un utilisateur puisse déployer à la fois du développement à la préparation et de la préparation à la production, mais ne pas faire les deux pour la même génération, donc une deuxième personne est toujours requis (mais assurez-vous d'avoir des personnes de secours pour les moments où l'un d'entre vous est absent).
Une autre option consiste à demander à votre personnel de support d'effectuer l'AQ. Cela peut sembler un travail supplémentaire pour eux, mais cela garantit également qu'ils sont au courant de toute modification de l'application qui peut leur garantir un certain travail à long terme.
Vous voudrez probablement obtenir un serveur de développement, et de préférence un environnement de transfert également. Personne ne devrait jamais passer du local à la production, à l'exception de son propre site Web personnel. Votre processus de déploiement ne doit prendre en charge que dev-> staging-> prod. Vous voulez probablement quelqu'un responsable de la signature des nouvelles versions - selon l'organisation, cela peut être un chef de projet, un contrôle qualité dédié ou un devoir qui tourne chaque semaine (avec un rappel tangible, par exemple, seule la personne avec le jouet moelleux de la semaine arrive à Pousser). Cependant, discutez-en d'abord avec votre équipe pour obtenir l'adhésion (voir ci-dessous).
Je veux que ce comportement soit puni d'une manière ou d'une autre le rende aussi désagréable que possible.
Vous pourriez avoir votre suite de tests (vous en avez un, n'est-ce pas?) Inclure une vérification qui détermine si vous êtes sur un serveur de production et, si c'est le cas, envoie à tout le monde au bureau un e-mail disant Looks like $username is testing on prod, watch out. Peut-être que faire honte à votre collègue serait désagréable. Ou vous pourriez créer des restrictions techniques comme interdire à votre équipe de regarder IP prod (que vous pouvez lever mais que vous devez justifier).
Je ne le recommande pas, cependant, vous ressembleriez au problème, pas à la personne qui teste la prod et vous pourriez vous rendre très impopulaire avec les gens de l'équipe qui ne s'en soucient pas.
Ce que vous voulez vraiment, ce n'est pas que ce comportement soit puni, mais --- stop?
Je les ai forcés/nous à utiliser [...]
C'est formidable que vous préconisez des améliorations du flux de travail, mais il semble que vous ne pensez pas beaucoup à vos collègues et/ou que vous ne bénéficiez pas de leur plein soutien. Cela entraînera probablement des collègues qui interagissent à moitié avec le flux de travail, font le minimum nécessaire pour mettre le code en production et ne suivent pas vraiment l'esprit du flux de travail, ce qui signifie plus de temps consacré à la clarification. Et lorsque vous passez de plus en plus de temps à clarifier les résultats d'une interaction inadéquate avec le flux de travail (parce que personne d'autre ne s'en soucie, non?) Tout le monde remettra en question le flux de travail lui-même.
Commencez donc par une conversation.
Découvrez pourquoi cela se produit (la machine de votre collègue n'est-elle pas aussi bonne pour les tests? sur dev/staging/prod, et voyez si vous pouvez faire quelque chose pour changer pourquoi cela se produit (votre collègue fera plus probablement ce que vous voulez si vous avez rendu le test local plus agréable que si vous venez de les réprimander).
Si vous ne pouvez pas le résoudre et que cela se résume vraiment à une différence d'opinion, planifiez une discussion à l'échelle de votre équipe lors de votre prochaine réunion rétrospective, voyez ce que vos collègues font et pensent. Faites valoir votre point de vue, mais écoutez le consensus. Peut-être que votre équipe dit que c'est ok de ne pas tester les correctifs textuels localement, et vous avez juste une règle selon laquelle aucune grosse fonctionnalité ne passe en dev non testée. Notez pendant la réunion et lisez ce que vous décidez collectivement de ce qui est autorisé dans chacun des environnements. Fixez une date dans quelques mois pour l'examiner, peut-être lors d'une rétrospective.
Au travail, nous évitons cela en utilisant Gerrit . Gerrit est un système de révision de code qui sert de porte d'entrée à votre branche Git principale/de production qui est conventionnellement appelée "maître". Vous avez des revues de code, non? On dirait que vous les faites personnellement exceptionnellement. Avec Gerrit, vous passez à une sorte de branche intermédiaire qui, après que vous et votre collègue avez exécuté le processus de révision de code de manière satisfaisante, Gerrit fusionne ensuite avec votre branche principale. Vous pouvez même connecter Gerrit à un serveur CI pour exécuter des tests unitaires avant que quiconque ne reçoive un e-mail pour examiner une modification. Si vous n'avez pas de serveur, vous pouvez configurer un outil CI, Codeship a un bon plan gratuit à utiliser comme preuve de concept.
Le dernier, bien sûr, consiste à automatiser les déploiements de production uniquement à partir de produits de construction approuvés qui ont survécu à la révision du code et aux tests unitaires. Il y a des technologies intéressantes à venir pour cela, que je ne mentionnerai pas de peur que ce soit un appât à la flamme.
Allez voir votre patron avec une solution. Celui-ci s'applique même à vous et est un moyen d'améliorer la qualité du code de tout le monde, pas seulement de punir votre collègue.
Je vois cela comme un problème largement humain - le processus est là et les outils sont là, mais le processus n'est tout simplement pas suivi.
Je suis d'accord avec ce que les autres ont dit ici, sur la possibilité qu'il soit tout à fait possible que le développeur en question soit simplement coincé dans un état d'esprit SVN , et pourrait bien penser que il suit le processus.
Je trouve que la meilleure façon d'aborder ce genre de problème, surtout lorsqu'il n'y a pas de supérieur clair, ne tourne pas autour de la punition ou de la suppression de l'accès - cela mène juste au ressentiment et comme il semble que vous êtes le grand partisan de suivre le processus (il y en a toujours un, et j'ai été "ce gars-là" auparavant), c'est vous qui êtes le plus susceptible de faire face au plus de chaleur. Il s'agit d'abord d'amener les gens à s'entendre sur le processus en premier.
C'est là que les réunions structurées, comme les réunions de type "enseignements tirés" après un incident majeur de production, peuvent être très utiles. Essayez de faire en sorte que tout le monde soit d'accord, y compris le développeur en question, que la révision du code, les tests unitaires, les tests complets, etc. doivent tous avoir lieu, à chaque fois (et vous pouvez commencer à introduire l'idée d'un environnement de transfert ici aussi). Ça ne devrait pas être difficile, et c'est très sensé. Demandez ensuite à l'équipe d'élaborer ensemble des règles solides sur la manière de procéder. Plus le développeur à l'origine du problème contribue, plus il aura envie de respecter les règles et commencera à voir pourquoi son comportement a été un problème.
Le dernier point, c'est de ne jamais tomber dans le "bien, c'est mieux qu'avant!" prendre au piège. Il y a toujours moyen de s'améliorer. D'après mon expérience, il est courant pour les gens de l'industrie informatique de commencer à se contenter de ce qu'ils ont, après quelques améliorations. Le règlement se poursuit ensuite, jusqu'à ce que vous soyez soudainement à nouveau en crise.
Ce n'est pas rare , en particulier dans les petites équipes. Ne vous en faites pas trop, mais établissez une règle informelle:
Brisez la construction, apportez des beignets.
Soit 1) Vous obtiendrez des beignets deux fois par semaine ou 2) ils adhéreront à la norme.
Apportez-le lors d'une réunion. Sans accusation, ne mentionnez personne par son nom, mais quelque chose de similaire à "Depuis que nous avons introduit les normes de contrôle de version et de déploiement, les choses sont devenues beaucoup plus faciles et le serveur est plus actif que C'était génial! Cependant, il est toujours tentant de prendre un raccourci et de le soumettre sans tests appropriés. C'est un pari, cependant, et notre serveur est en jeu. Je suggère qu'à partir de maintenant si l'un de nous soumet du code qui casse le serveur, le responsable apporte des beignets pour l'équipe le lendemain. "
Remplacez quelque chose d'autre par des beignets si vous le souhaitez, et ne le faites pas cher - le déjeuner pour toute l'équipe serait trop cher, mais une boîte de 5 $ de beignets ou un plateau de fruits/légumes, ou des frites et une trempette, etc., etc. serait probablement ennuyeux assez pour les faire réellement peser le risque contre la commodité de sauter les tests sans en faire un fardeau qui les éloignerait de l'équipe ou de l'entreprise.
Maintenant, comment puis-je les forcer ...
Au lieu de forcer vos collègues, essayez de leur faire voir les choses de votre point de vue. Cela rendra les choses beaucoup plus faciles pour tout le monde. Ce qui m'amène à ...
Je veux que ce comportement soit puni d'une manière ou d'une autre le rende aussi désagréable que possible.
Pourquoi est-ce pénible pour vous d'avoir des problèmes sur le serveur en direct, mais pas pour ce type? Savez-vous quelque chose qu'il ne sait pas? Que pouvez-vous faire pour lui faire voir les choses comme vous?
Si vous réussissez, vous ferez ressortir le meilleur de lui et il trouvera des solutions au problème auquel vous n'avez jamais pensé.
En général, essayez de travailler avec les gens pour résoudre les problèmes plutôt que de les forcer à des processus qui ne comprennent pas.
Quel est le pire qui puisse arriver? Avez-vous des sauvegardes suffisamment bonnes pour qu'un bug modifiant des enregistrements aléatoires dans votre base de données puisse être corrigé en restaurant une ancienne version?
Supposons que vous ayez un bogue où vous utilisez un identifiant d'enregistrement, et par erreur le montant d'une facture en cents est stocké dans une variable utilisée pour l'identifiant d'enregistrement. Donc, si je paie 12,34 $, l'enregistrement avec l'ID 1234 sera modifié. Pouvez-vous récupérer de cela, si le logiciel fonctionne pendant quelques heures jusqu'à ce que le bogue soit détecté? (Si à la fois l'enregistrement correct et l'enregistrement 1234 sont mis à jour, vous ne détecteriez cela que lorsque l'enregistrement 1234 est utilisé, cela pourrait ne pas être détecté pendant un certain temps).
Demandez maintenant à votre développeur très motivé ce qu'il en pense. De toute évidence, il ne peut pas prétendre qu'il n'a jamais commis d'erreur, car il l'a fait par le passé.
Vous comprenez clairement les différentes solutions techniques et processus possibles. La question est de savoir comment gérer le collègue.
Il s'agit essentiellement d'un exercice de gestion du changement.
Premièrement, j'aurais un mot tranquille avec le fondateur pour m'assurer qu'il/elle est à bord avec votre point de vue. S'il y a une panne de production, je m'attends à ce que le fondateur soit très préoccupé par cela et souhaite un changement.
Deuxièmement, vous travaillez dans une petite équipe et cela vaut probablement la peine d'essayer d'impliquer toute l'équipe dans l'amélioration des processus.
Configurez des rétrospectives de processus régulières (par exemple hebdomadaires). Demandez à toute l'équipe:
- Identifier les problèmes
- Idées de bénévoles pour améliorer les pratiques de travail
- S'engager dans la mise en œuvre de ces pratiques
Il doit en résulter naturellement que toute l'équipe contribue également à assurer le respect des pratiques améliorées.
Je pense que vous avez identifié quelques problèmes:
- Il semble que tout code qui est vérifié peut être mis en production de manière triviale par quiconque a le droit d'enregistrer le code.
Franchement, je pense que la configuration est tout simplement folle. Au minimum, les personnes qui peuvent déclencher manuellement un push vers la production doivent être limitées à l'ensemble des personnes de confiance complètement pour examiner en profondeur et tester tous les modifications sortantes (quel que soit l'auteur de ces modifications) avant de déclencher le Push. Donner à quiconque ayant la permission de consigner le code le pouvoir de déclencher arbitrairement un Push to production demande simplement des problèmes. Non seulement de développeurs imprudents et/ou incompétents, mais aussi de mécontents ou de tiers malveillants qui compromettent l'un de vos comptes.
Et si vous allez utiliser un processus à bouton-poussoir pour déployer chaque modification qui est enregistrée, vous devez disposer d'une suite complète de tests automatisés, et appuyer sur le bouton doit les exécuter (et abandonner le déploiement si tous les tests échouent!). Votre processus ne doit pas permettre au code qui n'a même pas été testé superficiellement d'atteindre le point où il est déployé sur le système de production en premier lieu.
Votre collègue a fait une grosse erreur en termes de vérification du code sans le tester au préalable. Votre organisation a commis une erreur beaucoup plus grave en adoptant un processus de déploiement qui permet au code non testé d'atteindre la production en toutes circonstances.
Le premier ordre du jour consiste donc à corriger le processus de déploiement. Limitez le nombre de personnes pouvant déclencher un push vers la production, ou incorporez une quantité raisonnable de tests dans votre processus de déploiement automatisé, ou les deux.
- Il semble que vous n'ayez peut-être pas défini de normes/principes de développement clairement définis.
En particulier, il semble que vous manquez un " définition de done " clair, et/ou en utilisant un qui n'inclut pas "le code a été testé" comme facteur de déclenchement lors de la vérification du code dans/déploiement de code en production. Si vous aviez cela, au lieu de simplement souligner que "un bon code n'est pas produit de cette façon", vous pourriez dire "ce code ne répond pas aux normes minimales que nous avons tous convenues, et il doit être meilleur dans le avenir".
Vous devez essayer d'établir une culture qui communique clairement ce que l'on attend des développeurs et les normes et le niveau de qualité qu'ils sont censés respecter. La mise en place d'une définition de done qui comprend au moins des tests manuels (ou de préférence, des cas de tests automatisés qui peuvent être exécutés dans le cadre du processus de construction/déploiement) aidera à cela. Comme cela peut avoir des conséquences pour casser la construction. Ou des conséquences plus graves pour la rupture du système de production. Notez que ces deux choses doivent vraiment être indépendantes, et il devrait être complètement impossible de casser simultanément le build et le système de production (car les builds cassés ne devraient jamais être déployables).
Vous devez intégrer un processus d'intégration continue + examen par les pairs dans l'entreprise. Bitbucket vous facilite la tâche.
Et +1 au serveur de développement suggéré par d'autres utilisateurs.
Ne soyez pas impoli avec lui, cela ne fera que nuire à votre relation de travail.