it-swarm.com.de

Mein Kollege begeht und pusht ohne zu testen

Wenn mein Mitarbeiter der Meinung ist, dass auf seinem PC kein Test erforderlich ist, nimmt er Änderungen vor, legt fest und drückt dann. Dann testet er auf dem Produktionsserver und stellt fest, dass er einen Fehler gemacht hat. Es passiert einmal in der Woche. Jetzt sehe ich, dass er 3 Commits und Pushs mit Bereitstellung auf dem Produktionsserver innerhalb von 5 Minuten gemacht hat.

Ich sagte ihm einige Male, dass dies nicht die Art und Weise ist, wie gute Arbeit geleistet wird. Ich möchte nicht wieder unhöflich zu ihm sein und er hat den gleichen Status wie ich in der Firma und er hat hier mehr als ich gearbeitet.

Ich möchte, dass dieses Verhalten auf irgendeine Weise bestraft oder so unangenehm wie möglich gemacht wird.

Bevor ich anfing, stellte das Unternehmen antike Methoden wie FTP bereit, und es gab keine Versionskontrolle.

Ich habe sie/uns gezwungen, Git, Bitbucket, Dploy.io und HipChat zu verwenden. Die Bereitstellung erfolgt nicht automatisch. Jemand muss sich bei dply.io anmelden und auf die Schaltfläche zum Bereitstellen klicken.

Wie kann ich sie nun zwingen, nicht auf dem Produktionsserver zu testen? So etwas wie ein HipChat-Bot kann erkennen, dass in derselben Zeile wiederholt Änderungen vorgenommen werden, und eine Benachrichtigung an den Programmierer senden.

115
ilhan

Sie benötigen einen ordnungsgemäßen Qualitätssicherungsprozess (QS).

In einem professionellen Softwareentwicklungsteam pushen Sie nicht vom Entwicklungsrecht bis zur Produktion. Sie haben mindestens drei separate Umgebungen: Entwicklung, Bereitstellung und Produktion.

Wenn Sie der Meinung sind, dass in Ihrer Entwicklungsumgebung etwas funktioniert, wechseln Sie zuerst zum Staging, wo jedes Commit vom QA-Team getestet wird. Erst wenn dieser Test erfolgreich ist, wird es in die Produktion übertragen. Im Idealfall werden Entwicklung, Test und Produktion in die Produktion von getrennten Personen durchgeführt. Dies kann sichergestellt werden, indem Sie Ihr Build-Automatisierungssystem so konfigurieren, dass Entwickler es nur von der Entwicklung bis zum Staging bereitstellen können und das QA-Team nur vom Staging bis zur Produktion bereitstellen kann.

Wenn Sie das Management nicht davon überzeugen können, jemanden für Ihre Qualitätssicherung einzustellen, kann möglicherweise einer von Ihnen diese Rolle für den anderen spielen. Ich habe nie mit diploy.io gearbeitet, aber einige Build-Automatisierungssysteme können so konfiguriert werden, dass ein Benutzer sowohl von der Entwicklung bis zum Staging als auch vom Staging bis zur Produktion bereitstellen kann, jedoch nicht beide für denselben Build, sodass immer eine zweite Person anwesend ist erforderlich (aber stellen Sie sicher, dass Sie einige Backup-Personen für Zeiten haben, in denen einer von Ihnen abwesend ist).

Eine andere Möglichkeit besteht darin, dass Ihre Support-Mitarbeiter die Qualitätssicherung durchführen. Dies mag für sie als zusätzliche Arbeit erscheinen, stellt aber auch sicher, dass sie über Änderungen an der Anwendung informiert sind, die ihnen auf lange Sicht Arbeit ersparen können.

91
Philipp

Möglicherweise möchten Sie einen Entwicklungsserver und vorzugsweise auch eine Staging-Umgebung erhalten. Niemand sollte jemals von der lokalen zur Produktion drängen, außer seiner eigenen persönlichen Website. Ihr Bereitstellungsprozess sollte nur dev-> staging-> prod unterstützen. Sie möchten wahrscheinlich jemanden, der für die Unterzeichnung neuer Releases verantwortlich ist. Je nach Organisation kann dies ein Projektleiter, eine dedizierte Qualitätssicherung oder eine wöchentlich wechselnde Aufgabe sein (mit einer konkreten Erinnerung, z. B. nur die Person mit dem flauschigen Spielzeug in dieser Woche Drücken). Besprechen Sie dies jedoch zuerst mit Ihrem Team, um ein Buy-In zu erhalten (siehe unten).

Ich möchte, dass dieses Verhalten auf irgendeine Weise bestraft oder so unangenehm wie möglich gemacht wird.

Sie könnten Ihre Testsuite (Sie haben eine davon, oder?) Eine Überprüfung enthalten lassen, die feststellt, ob Sie sich auf einem Produktionsserver befinden, und in diesem Fall allen Mitarbeitern im Büro eine E-Mail mit der Aufschrift Looks like $username is testing on prod, watch out. Vielleicht wäre es unangenehm, Ihren Kollegen öffentlich zu beschämen. Oder Sie könnten technische Einschränkungen wie das IP-Verbot Ihres Teams für das Betrachten von Produkten schaffen (die Sie aufheben können, aber rechtfertigen müssen).

Ich empfehle es jedoch nicht, Sie würden wie das Problem aussehen, nicht wie die Person, die auf Produkte testet, und Sie könnten sich bei den Leuten im Team, die sich nicht darum kümmern, sehr unbeliebt machen.

Sicherlich wollen Sie wirklich nicht, dass dieses Verhalten bestraft wird, sondern dass es aufhören?

Ich habe sie/uns gezwungen, [...]

Es ist großartig, dass Sie Verbesserungen des Workflows befürworten, aber es klingt so, als würden Sie entweder nicht viel von Ihren Kollegen denken und/oder Sie haben nicht die volle Unterstützung. Dies führt wahrscheinlich dazu, dass Kollegen halb hitzig mit dem Workflow interagieren, das Minimum tun, um Code in die Produktion zu bringen, und nicht wirklich dem Geist des Workflows folgen, was mehr Zeit für das Aufräumen bedeutet. Und wenn Sie immer mehr Zeit damit verbringen, die Ergebnisse einer unzureichenden Interaktion mit dem Workflow zu klären (weil es sonst niemanden interessiert, oder?), Werden alle anderen den Workflow selbst in Frage stellen.

Beginnen Sie also mit einem Gespräch.

Finden Sie heraus, warum dies geschieht (ist der Computer Ihres Kollegen nicht so gut zum Testen geeignet? Ist Ihr Kollege unsicher in Bezug auf Feature-Zweige oder steckt er in einer SVN-Denkweise fest, in der Commit und Push gleich sind?), Erklären Sie, warum es für Sie ein Problem ist, dass nicht getesteter Code nicht funktioniert auf dev/staging/prod und sehen Sie, ob Sie etwas tun können, um zu ändern, warum es passiert (Ihr Kollege wird mit größerer Wahrscheinlichkeit das tun, was Sie wollen, wenn Sie es nur schöner gemacht haben, lokal zu testen, als wenn Sie sie nur beschimpft haben).

Wenn Sie es nicht lösen können und es wirklich zu Meinungsverschiedenheiten kommt, planen Sie eine teamweite Diskussion in Ihrem nächsten retrospektiven Meeting, sehen Sie, was Ihre Kollegen tun und denken. Machen Sie Ihren Fall, aber hören Sie auf den Konsens. Vielleicht sagt Ihr Team, dass es in Ordnung ist, Textkorrekturen nicht lokal zu testen, und Sie haben nur die Regel, dass keine großen Funktionen ungetestet auf Entwickler übertragen werden. Schreiben Sie in der Besprechung auf und lesen Sie vor, was Sie gemeinsam darüber entscheiden, was in den einzelnen Umgebungen zulässig ist. Legen Sie ein Datum in ein paar Monaten fest, um es zu überprüfen, möglicherweise im Nachhinein.

54
user52889

Bei der Arbeit vermeiden wir dies, indem wir Gerrit verwenden. Gerrit ist ein Codeüberprüfungssystem, das als Tor zu Ihrem Haupt-/Produktions-Git-Zweig fungiert, der üblicherweise als "Master" bezeichnet wird. Sie haben Code-Bewertungen, richtig? Es hört sich so an, als würden Sie sie ausnahmsweise persönlich tun. Mit Gerrit pushen Sie zu einer Art Staging-Zweig, der, nachdem Sie und Ihr Mitarbeiter den Codeüberprüfungsprozess zufriedenstellend ausgeführt haben, mit Ihrem Hauptzweig zusammengeführt wird. Sie können Gerrit sogar an einen CI-Server anschließen, um Komponententests durchzuführen, bevor jemand eine E-Mail erhält, um eine Änderung zu überprüfen. Wenn Sie keinen Server haben, können Sie ein CI-Tool einrichten. Codeship hat einen schönen kostenlosen Plan, der als Proof of Concept verwendet werden kann.

Zuletzt müssen Sie natürlich die Produktionsbereitstellungen nur aus genehmigten Build-Produkten automatisieren, die die Codeüberprüfung und die Komponententests überstanden haben. Dafür stehen einige coole Technologien auf dem Programm, die ich aus Angst vor einem Flammenköder nicht erwähnen werde.

Gehen Sie mit einer Lösung zu Ihrem Chef. Dies gilt auch für Sie und ist eine Möglichkeit, die Codequalität aller zu verbessern und nicht nur Ihren Kollegen zu bestrafen.

20
Greg

Ich sehe dies als ein weitgehend menschliches Problem - der Prozess ist da und die Werkzeuge sind da, aber der Prozess wird einfach nicht befolgt.

Ich stimme dem zu, was andere hier gesagt haben, über die Möglichkeit, dass es durchaus möglich ist, dass der betreffende Entwickler nur in einer SVN Denkweise steckt, und denke das vielleicht auch er folgt dem Prozess.

Ich finde, dass der beste Weg, um diese Art von Problem anzugehen, insbesondere wenn es keinen klaren Vorgesetzten gibt, sich nicht um Bestrafung oder Entfernung des Zugangs dreht - dies führt nur zu Ressentiments und wie es sich anhört, als wären Sie der laute Befürworter des Folgens Während des Prozesses (es gibt immer einen, und ich war schon früher 'dieser Typ') bist du derjenige, der wahrscheinlich die meiste Hitze bewältigt. Es geht darum, die Menschen zuerst zu einer Einigung über den Prozess zu bringen.

Hier können strukturierte Besprechungen wie Besprechungen vom Typ "Lessons Learned" nach einem größeren Produktionsvorfall sehr nützlich sein. Versuchen Sie, alle, einschließlich des betreffenden Entwicklers, dazu zu bringen, dass Codeüberprüfung, Komponententests, umfassende Tests usw. jedes Mal stattfinden müssen (und Sie können auch hier die Idee einer Staging-Umgebung einführen). Es sollte nicht schwer sein und es ist sehr vernünftig. Bitten Sie dann das Team, gemeinsam einige solide Regeln auszuarbeiten, wie dies geschehen soll. Je mehr der Entwickler, der das Problem verursacht, dazu beiträgt, desto mehr wird er sich an die Regeln halten und erkennen, warum sein Verhalten ein Problem war.

Der letzte Punkt ist, niemals in das "Nun, es ist besser als früher!" Zu fallen. Falle. Es gibt immer Raum für Verbesserungen. Nach meiner Erfahrung ist es üblich, dass sich Menschen in der IT-Branche nach einigen Verbesserungen mit dem zufrieden geben, was sie haben. Die Siedlung geht dann weiter, bis Sie plötzlich wieder an einem Krisenpunkt sind.

17
James Decker

Dies ist nicht ungewöhnlich , insbesondere in kleinen Teams. Machen Sie keine große Sache, sondern machen Sie eine informelle Regel:

Brechen Sie den Build, bringen Sie Donuts.

Entweder 1) Sie erhalten zweimal pro Woche Donuts oder 2) sie halten sich an den Standard.

Bringen Sie es in einer Besprechung zur Sprache. Nicht anklagend, erwähnen Sie niemanden mit Namen, aber etwas Ähnliches wie "Seit wir Versionskontroll- und Bereitstellungsstandards eingeführt haben, sind die Dinge viel einfacher geworden und der Server ist die meiste Zeit in Betrieb als Früher war es so. Das ist großartig! Es ist jedoch immer noch verlockend, eine Verknüpfung zu verwenden und ohne ordnungsgemäße Tests einzureichen. Es ist jedoch ein Glücksspiel, und unser Server ist in der Leitung. Ich schlage vor, dass von nun an einer von uns Code sendet bricht der Server, die verantwortliche Person bringt am nächsten Tag Donuts für das Team. "

Ersetzen Sie Donuts auf Wunsch durch etwas anderes und machen Sie es nicht teuer - das Mittagessen für das gesamte Team wäre zu viel, aber eine 5-Dollar-Schachtel mit Donuts oder Obst-/Gemüsetablett oder Pommes und Dip usw. usw. wäre wahrscheinlich ärgerlich genug, um das Risiko tatsächlich gegen die Bequemlichkeit des Überspringens von Tests abzuwägen, ohne es zu einer Belastung zu machen, die sie vom Team oder Unternehmen wegschieben würde.

12
Adam Davis

Wie kann ich sie jetzt zwingen ...

Versuchen Sie, Ihre Kollegen zu zwingen, Dinge aus Ihrer Perspektive zu sehen, anstatt sie zu zwingen. Dies wird die Dinge für alle viel einfacher machen. Was mich führt in ...

Ich möchte, dass dieses Verhalten auf irgendeine Weise bestraft oder so unangenehm wie möglich gemacht wird.

Warum ist es ein Schmerz für Sie mit Problemen auf dem Live-Server, aber nicht für diesen Kerl? Weißt du etwas, was er nicht weiß? Was können Sie tun, damit er die Dinge so sieht, wie Sie es tun?

Wenn Ihnen dies gelingt, werden Sie das Beste aus ihm herausholen und er wird Lösungen für das Problem finden, an das Sie nie gedacht haben.

Versuchen Sie im Allgemeinen, mit Menschen zusammenzuarbeiten, um Probleme zu lösen, anstatt sie zu Prozessen zu zwingen, die nicht verstehen.

8
vidstige

Was ist das Schlimmste, was passieren könnte? Haben Sie Backups, die gut genug sind, um einen Fehler beim Ändern zufälliger Datensätze in Ihrer Datenbank durch Wiederherstellen einer alten Version zu beheben?

Angenommen, Sie haben einen Fehler, bei dem Sie eine Datensatz-ID verwenden, und versehentlich wird der Betrag einer Rechnung in Cent in einer Variablen gespeichert, die für die Datensatz-ID verwendet wird. Wenn ich also 12,34 USD bezahle, wird der Datensatz mit der ID 1234 geändert. Können Sie sich davon erholen, wenn die Software einige Stunden läuft, bis der Fehler erkannt wird? (Wenn sowohl der richtige Datensatz als auch der Datensatz 1234 aktualisiert werden, werden Sie dies nur erkennen, wenn Datensatz 1234 verwendet wird, sodass dies für eine Weile unentdeckt bleiben kann.).

Fragen Sie nun Ihren hochmotivierten Entwickler, was er davon hält. Offensichtlich kann er nicht behaupten, dass er niemals Fehler macht, weil er dies in der Vergangenheit getan hat.

6
gnasher729

Sie verstehen verschiedene mögliche prozessuale und technische Lösungen. Die Frage ist, wie der Mitarbeiter verwaltet wird.

Dies ist im Wesentlichen eine Change-Management-Übung.

Erstens hätte ich ein ruhiges Wort mit dem Gründer, um sicherzustellen, dass er/sie mit Ihrem Standpunkt an Bord ist. Wenn es zu einem Produktionsausfall kommt, würde ich erwarten, dass der Gründer darüber sehr besorgt ist und eine Änderung wünscht.

Zweitens arbeiten Sie in einem kleinen Team und es lohnt sich wahrscheinlich, das gesamte Team für die Prozessverbesserung zu gewinnen.

Richten Sie regelmäßige (z. B. wöchentliche) Prozessrückblicke ein. Habe das ganze Team:

  • Probleme identifizieren
  • Freiwillige Ideen zur Verbesserung der Arbeitspraktiken
  • Nehmen Sie an der Umsetzung dieser Praktiken teil

Es sollte natürlich folgen, dass das gesamte Team dann auch dazu beiträgt, die Einhaltung der verbesserten Praktiken sicherzustellen.

3
Keith

Ich denke, Sie haben einige Probleme festgestellt:

  1. Es hört sich so an, als ob jeder Code, der überprüft wird, von jedem, der das Recht hat, Code einzuchecken, trivial zur Produktion gebracht werden kann.

Ehrlich gesagt denke ich, dass das Setup einfach verrückt ist. Zumindest sollten die Personen, die manuell einen Push-to-Production auslösen können, auf die Gruppe von Personen beschränkt sein, denen vertraut werden kann vollständig, um alle ausgehenden Änderungen gründlich zu überprüfen und zu testen (unabhängig davon, wer die erstellt hat) Änderungen) vor dem Auslösen des Push. Wenn Sie jemandem die Erlaubnis geben, Code einzuchecken, können Sie auch willkürlich einen Push-to-Production-Vorgang auslösen. Nicht nur von unachtsamen und/oder inkompetenten Entwicklern, sondern auch von verärgerten oder böswilligen Dritten, die zufällig eines Ihrer Konten gefährden.

Wenn Sie einen Push-Button-Prozess verwenden möchten, um jede eingecheckte Änderung bereitzustellen, müssen Sie über eine umfassende Suite automatisierter Tests verfügen, die auf Knopfdruck ausgeführt werden müssen (und die Bereitstellung abbrechen, wenn Tests scheitern!). Ihr Prozess sollte nicht zulassen, dass Code, der noch nicht einmal oberflächlich getestet wurde, den Punkt erreicht, an dem er überhaupt erst auf dem Produktionssystem bereitgestellt wird.

Ihr Mitarbeiter hat einen großen Fehler beim Einchecken von Code gemacht, ohne ihn vorher zu testen. Ihre Organisation hat einen viel größeren Fehler durch die Einführung eines Bereitstellungsprozesses verrückt gemacht, der es ungetestetem Code ermöglicht, unter allen Umständen die Produktion zu erreichen.

Die erste Aufgabe besteht also darin, den Bereitstellungsprozess zu reparieren. Beschränken Sie entweder, wer einen Push to Production auslösen kann, oder integrieren Sie eine angemessene Menge an Tests in Ihren automatisierten Bereitstellungsprozess oder beides.

  1. Es hört sich so an, als hätten Sie möglicherweise keine klar definierten Entwicklungsstandards/-prinzipien festgelegt.

Insbesondere klingt es so, als ob Sie ein klares " Definition von erledigt " vermissen und/oder eines verwenden, das nicht "der Code wurde getestet" als Ansteuerungsfaktor für das Einchecken von Code in/enthält Bereitstellen von Code für die Produktion. Wenn Sie dies hätten, anstatt nur darauf hinzuweisen, dass "guter Code nicht auf diese Weise erzeugt wird", könnten Sie sagen, dass "dieser Code nicht den Mindeststandards entspricht, auf die wir uns alle geeinigt haben, und dass er in den USA besser sein muss Zukunft".

Sie sollten versuchen, eine Kultur zu etablieren, die klar kommuniziert, was von Entwicklern erwartet wird und welche Standards und Qualitätsniveaus sie einhalten sollen. Das Einrichten einer Definition von done, die mindestens manuelle Tests umfasst (oder vorzugsweise automatisierte Testfälle, die als Teil des Erstellungs-/Bereitstellungsprozesses ausgeführt werden können), hilft dabei. Da kann Konsequenzen für das Brechen des Builds haben. Oder schwerwiegendere Folgen für die Störung des Produktionssystems. Beachten Sie, dass diese beiden Dinge wirklich unabhängig sein sollten und es völlig unmöglich sein sollte, sowohl den Build als auch das Produktionssystem gleichzeitig zu beschädigen (da fehlerhafte Builds niemals bereitstellbar sein sollten).

1
aroth

Sie sollten einen Continuous Integration + Peer Review-Prozess in das Unternehmen integrieren. Bitbucket macht es einfach.

Und +1 an den von anderen Benutzern vorgeschlagenen Dev-Server.

Sei nicht unhöflich mit ihm, es wird nur deine Arbeitsbeziehung verletzen.

0
Rufo El Magufo