Lorsque mon collègue pense qu’il n’est pas nécessaire de faire un test sur son PC, il apporte des modifications, des validations puis des poussées. Ensuite, il teste sur le serveur de production et réalise qu'il a commis une erreur. Cela arrive une fois par semaine. Maintenant, je vois qu’il a effectué 3 commits et pousse avec le déploiement sur le serveur de production en moins de 5 minutes.

Je lui ai dit à quelques reprises que ce n’était pas la façon de faire du bon travail. Je ne veux plus être impoli avec lui et il a le même statut 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 ou le rende désagréable autant que possible.

Avant de commencer, la société utilisait des méthodes antiques, telles que FTP, sans contrôle de version.

Je les ai / obligés à utiliser Git, Bitbucket, Dploy.io et HipChat. Le déploiement n'est pas automatique, il faut que quelqu'un se connecte à dply.io et appuie sur le bouton de déploiement.

Maintenant, comment puis-je les forcer à ne pas tester sur le serveur de production? Quelque chose comme HipChat bot peut sentir qu'il y a des modifications répétées sur la même ligne et envoyer un avis au programmeur.

Vous avez besoin d'un processus d'assurance qualité (QA) approprié.

Dans une équipe de développement logiciel professionnelle, vous ne passez pas du développement à la production. Vous avez au moins trois environnements distincts: le développement, la mise en scène et la production.

Lorsque vous pensez que quelque chose fonctionne dans votre environnement de développement, vous passez d'abord à la mise en scène. Chaque validation est testée par l'équipe d'assurance qualité et, 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 de manière à ce que les développeurs ne puissent déployer que du développement à la mise en scène et que l'équipe d'assurance qualité ne puisse déployer que de la mise en production à la production.

Lorsque vous ne pouvez pas persuader la direction d'engager quelqu'un pour effectuer votre assurance qualité, alors 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 génération peuvent être configurés de manière à ce qu'un utilisateur puisse déployer à la fois du développement à la mise en scène et de la production à la production. requis (mais assurez-vous d’avoir des remplaçants pour les cas où l’un de vous est absent).

Une autre option consiste à demander à votre personnel d'assistance d'effectuer l'AQ. Cela peut sembler être un travail supplémentaire pour eux, mais cela leur permet également d'être au courant des modifications apportées à l'application qui pourraient les protéger du travail à long terme.

Vous voudrez probablement vous procurer un serveur de développement et, de préférence, un environnement intermédiaire. Personne ne devrait jamais pousser de la production locale à la production, à l'exception de son site Web personnel. Votre processus de déploiement doit uniquement prendre en charge dev-> staging-> prod. Vous voulez probablement une personne responsable de la signature des nouvelles versions - selon l’organisation, il peut s’agir d’un responsable de projet, d’un responsable de l’assurance qualité ou d’un devoir qui tourne toutes les semaines (avec un rappel tangible, par exemple, seule la personne avec le jouet moelleux qui arrive cette semaine) pousser). Cependant, discutez-en d'abord avec votre équipe pour obtenir son adhésion (voir ci-dessous).

Je veux que ce comportement soit puni d'une manière ou d'une autre ou le rende désagréable autant que possible.

Vous pourriez avoir votre suite de tests (vous en avez une, n'est-ce pas?) Inclure un contrôle qui détermine si vous êtes sur un serveur de production et, le cas échéant, envoie un courrier électronique à chaque employé du bureau Looks like $username is testing on prod, watch out. Peut-être que faire honte à votre collègue serait désagréable. Ou bien, vous pourriez créer des restrictions techniques, telles que l'IP-interdire à votre équipe de regarder les 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 avec prod et vous pourriez vous rendre très impopulaire auprès des membres de l'équipe qui ne s'en soucient pas.

Ce que vous voulez vraiment, c’est sûrement pas que ce comportement soit puni mais qu’il s’arrête ?

Je les ai forcés / nous à utiliser [...]

C'est bien que vous préconisiez 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 soutien total. Il est probable que les collègues interagiront à moitié avec le flux de travail, en faisant le minimum nécessaire pour que le code passe en production et en ne suivant pas vraiment l'esprit du flux de travail, ce qui signifiera plus de temps passé à nettoyer. Et lorsque vous passerez de plus en plus de temps à éliminer les résultats d'une interaction inadéquate avec le flux de travail (personne ne s'en soucie, n'est-ce pas?), 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 est-elle moins performante pour les tests? Votre collègue est-il incertain des branches de ses fonctionnalités ou est-il coincé dans un état d'esprit où les commandes commit et push sont identiques?), Expliquez-nous pourquoi le code non testé laisse tomber sur dev / staging / prod et voyez si vous pouvez faire quelque chose pour changer la raison (votre collègue fera probablement ce que vous voulez si vous venez de rendre plus agréable le test local que si vous venez de le réprimander).

Si vous ne parvenez pas à résoudre le problème et qu'il en résulte véritablement une divergence d'opinion, planifiez une discussion à l'échelle de l'équipe lors de votre prochaine réunion rétrospective, voyez ce que vos collègues font et pensent. Présentez vos arguments, mais écoutez le consensus. Peut-être que votre équipe dit qu'il est acceptable de ne pas tester les correctifs textuels localement, et que vous avez simplement pour règle de ne pas tester de grandes fonctionnalités. Ecrivez dans la réunion et lisez ce que vous décidez collectivement de ce qui est autorisé sur 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 agit comme une porte d'accès à votre branche Git principale / de production, appelée conventionnellement "maître". Vous avez des critiques de code, non? On dirait que vous les faites personnellement exceptionnellement. Avec Gerrit, vous passez à une sorte de branche intermédiaire qui, une fois que vous et votre collègue avez exécuté le processus de révision de code de manière satisfaisante, Gerrit est ensuite fusionnée avec votre branche principale. Vous pouvez même connecter Gerrit à un serveur de CI pour exécuter des tests unitaires avant que quiconque ne reçoive un courrier électronique pour passer en revue une modification. Si vous n’avez pas de serveur sur lequel vous pouvez configurer un outil de CI, Codeship a un joli plan gratuit à utiliser comme preuve de concept.

Enfin, bien sûr, il faut automatiser les déploiements de production uniquement à partir de produits de construction approuvés ayant survécu à la révision du code et aux tests unitaires. Il existe des technologies intéressantes pour cela, que je ne mentionnerai pas de peur que ce soit un appât à la flamme.

Allez chez votre patron avec une solution. Celui-ci s'applique même à vous et est un moyen d'améliorer la qualité du code de chacun, pas seulement de punir votre collègue.

Je considère cela comme un problème essentiellement humain - le processus est en place et les outils sont en place, mais le processus n'est tout simplement pas suivi.

Je suis d' accord avec ce que les autres ont dit ici, au sujet de la possibilité qu'il est tout à fait possible , le développeur en question est tout simplement coincé dans un SVN état d' esprit, et peut bien penser qu'il est suit le processus.

Je trouve que la meilleure façon de traiter ce type de problème, en particulier lorsqu'il n'y a pas de supérieur hiérarchique évident, ne tourne pas autour de la punition ou de la suppression de l'accès - cela crée simplement du ressentiment et donne l'impression que vous êtes le grand partisan de ce qui suit. En ce qui concerne le processus (il y en a toujours un, et j'ai déjà été "ce gars-là"), vous êtes le plus susceptible de faire la plus forte pression. Il s’agit avant tout de faire en sorte que les gens s’entendent sur le processus.

C'est ici que des réunions structurées, telles que des réunions de type "leçons apprises" après un incident majeur dans la production, peuvent être très utiles. Essayez de convaincre tout le monde, y compris le développeur en question, que la révision du code, les tests unitaires, les tests complets, etc. Cela ne devrait pas être difficile, et c'est très raisonnable. Ensuite, demandez à l’équipe de définir ensemble des règles solides sur la manière de procéder. Plus le développeur à l'origine du problème contribue au processus, plus il se sentira conforme aux règles et commencera à comprendre pourquoi son comportement pose problème.

Le dernier point est de ne jamais tomber dans le "bon, c'est mieux que ce qu'il était avant!" piège. Il y a toujours moyen de s'améliorer. D'après mon expérience, il est courant que les gens de l'industrie informatique commencent à se contenter de ce qu'ils ont après quelques améliorations. Le règlement se poursuit ensuite, jusqu'à ce que vous vous trouviez soudain à nouveau en crise.

Ce n'est pas rare , en particulier dans les petites équipes. N'en faites pas un problème, mais établissez une règle informelle:

Casser la construction, apporter des beignets.

Soit 1) vous aurez des beignets deux fois par semaine ou 2) ils respecteront la norme.

Amenez-le en réunion. Sans accuser de cause, ne nommez 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 simples et le serveur est plus opérationnel que jamais. C’est génial! Cependant, il est toujours tentant de prendre un raccourci et de le soumettre sans les soumettre à un test correct. C'est un pari cependant, et notre serveur est en ligne. Je suggère qu'à partir de maintenant si l'un de nous soumet du code qui casse le serveur, la personne responsable apporte des beignets pour l'équipe le lendemain. "

Si vous le souhaitez, remplacez les beignets par quelque chose de nouveau et ne payez pas trop cher - un déjeuner pour toute l'équipe serait trop, mais une boîte de beignets ou un plateau de fruits / légumes de 5 $, des chips et une trempette, etc., seraient probablement ennuyeux. suffisamment pour leur faire peser le risque en comparant les avantages de sauter des tests sans en faire un fardeau qui les éloignerait de l’équipe ou de la société.

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 facilitera les choses pour tout le monde. Ce qui me mène dans ...

Je veux que ce comportement soit puni d'une manière ou d'une autre ou le rende désagréable autant que possible.

Pourquoi est-ce une douleur pour vous avec des problèmes sur le serveur live, mais pas pour ce gars? Savez-vous quelque chose qu'il ne sait pas? Que pouvez-vous faire pour lui faire voir les choses comme vous le faites?

Si vous y parvenez, vous en tirerez le meilleur et il trouvera des solutions au problème auquel vous n'aviez jamais pensé.

En général, essayez de travailler avec les gens pour résoudre les problèmes plutôt que de les forcer à participer à des processus incompréhensibles.

Quel est le pire qui pourrait arriver? Avez-vous des sauvegardes suffisamment bonnes pour qu'un bogue modifiant des enregistrements aléatoires de votre base de données puisse être corrigé en restaurant une ancienne version?

Imaginons que vous utilisiez un identifiant d'enregistrement et que, 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'identifiant 1234 sera modifié. Pouvez-vous vous en remettre 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 le détecterez que lorsque l'enregistrement 1234 est utilisé, de sorte que cela risque de ne pas être détecté pendant un certain temps).

Maintenant, demandez à votre développeur très motivé ce qu’il en pense. De toute évidence, il ne peut pas prétendre qu'il ne fait jamais d'erreur, car il l'a déjà fait par le passé.

Vous comprenez clairement les différents processus et solutions techniques possibles. La question est de savoir comment gérer le collègue.

Il s’agit essentiellement d’un exercice de gestion du changement.

Tout d’abord, j’aurais un mot discret à dire au fondateur pour s’assurer qu’il / elle adhère à votre point de vue. S'il y avait une panne de production, je m'attendrais à ce que le fondateur soit très préoccupé par cela et souhaite un changement.

Deuxièmement, vous travaillez dans une petite équipe et il 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 volontaires pour améliorer les pratiques de travail
• S'engager dans la mise en œuvre de ces pratiques

Naturellement, l’ensemble de l’équipe contribue également à assurer le respect des pratiques améliorées.

Je pense que vous avez identifié quelques problèmes:

1. Il semble que tout code qui est vérifié peut être poussé de manière triviale vers la production par quiconque dispose des droits nécessaires à son contrôle.

Franchement, je pense que cette configuration est simplement folle. Au minimum, les personnes pouvant déclencher manuellement un transfert en production doivent être limitées à l'ensemble des personnes en qui on peut entièrement faire confiance pour examiner et tester en profondeur tous les changements sortants (quel que soit le créateur de ceux-ci) avant de déclencher le transfert. Donner à quiconque ayant la permission d’archiver le code le pouvoir de déclencher arbitrairement une poussée en production, c’est tout simplement demander des problèmes. Non seulement des développeurs négligents et / ou incompétents, mais aussi des développeurs mécontents ou des tiers malveillants qui compromettent l'un de vos comptes.

Et si vous souhaitez déployer chaque modification enregistrée dans un processus à l'aide d'un bouton-poussoir, vous devez disposer d'une suite complète de tests automatisés. Vous devez également appuyer sur le bouton pour les exécuter (et interrompre le déploiement si nécessaire. 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 de déploiement initial sur le système de production.

Votre collègue a commis une grosse erreur en enregistrant le code sans le tester au préalable. Votre organisation a commis une erreur bien plus grave en adoptant un processus de déploiement qui permet au code non testé d’atteindre la production, quelles que soient les circonstances.

La première tâche à accomplir consiste donc à réparer le processus de déploiement. Limitez le nombre de personnes pouvant déclencher une incitation à la production ou incorporez une quantité raisonnable de tests dans votre processus de déploiement automatisé, ou les deux.

2. Il semble que vous n’ayez peut-être pas défini de normes / principes de développement clairement définis.

En particulier, il semble qu'il vous manque une " définition de fait " claire et / ou l'utilisation d'une définition n'incluant pas "le code a été testé" en tant que facteur de déclenchement pour la vérification du code / le déploiement du code en production. Si vous aviez cela, au lieu de simplement indiquer que "le bon code n'est pas produit de cette façon", vous pouvez dire: "ce code ne respecte pas les normes minimales sur lesquelles nous nous sommes tous mis d'accord et il doit être amélioré dans les règles de l'art. futur".

Vous devriez essayer d'établir une culture qui communique clairement ce que l'on attend des développeurs, ainsi que les normes et le niveau de qualité qu'ils sont censés respecter. Configurer une définition de done incluant au moins des tests manuels (ou de préférence des cas de tests automatisés pouvant être exécutés dans le cadre du processus de création / déploiement) vous aidera à cela. Comme peut avoir des conséquences pour briser la construction. Ou des conséquences plus graves pour briser le système de production. Notez que ces deux éléments doivent être réellement indépendants et qu’il devrait être absolument impossible de décomposer simultanément le système de production et le système de production (car les modèles endommagés ne devraient jamais être déployables).

Vous devez intégrer un processus d’intégration continue et d’évaluation par les pairs dans l’entreprise. Bitbucket facilite les choses.

Et +1 au serveur de dev suggéré par d'autres utilisateurs.

Ne soyez pas impoli avec lui, cela ne fera que nuire à votre relation de travail.