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

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 ist im gleichen Status wie ich in der Firma und er hat mehr als ich hier gearbeitet.

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

Bevor ich anfing, stellte das Unternehmen mithilfe antiker 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, es muss sich jemand bei dply.io anmelden und den Bereitstellungsknopf drücken.

Wie kann ich sie nun zwingen, nicht auf dem Produktionsserver zu testen? So etwas wie HipChat-Bot kann feststellen, dass in derselben Zeile wiederholte Änderungen vorgenommen wurden, und dem Programmierer einen Hinweis senden.

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

In einem professionellen Softwareentwicklungsteam drängen Sie nicht von der Entwicklung bis zur Produktion. Sie haben mindestens drei separate Umgebungen: Entwicklung, Bereitstellung und Produktion.

Wenn Sie der Meinung sind, dass in Ihrer Entwicklungsumgebung etwas funktioniert, müssen Sie zunächst die Bereitstellung starten, bei der jedes Commit vom QA-Team getestet wird. Erst wenn dieser Test erfolgreich ist, wird es an die Produktion weitergeleitet. Idealerweise wird die Entwicklung, das Testen und das Hochfahren zur Produktion von getrennten Mitarbeitern durchgeführt. Dies kann sichergestellt werden, indem Sie Ihr Build-Automatisierungssystem so konfigurieren, dass Entwickler nur von der Entwicklung bis zum Staging und das QA-Team nur vom Staging bis zur Produktion bereitstellen können.

Wenn Sie das Management nicht davon überzeugen können, jemanden für Ihre Qualitätssicherung einzustellen, kann einer von Ihnen möglicherweise diese Rolle für den anderen übernehmen. 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, aber nicht beide für den gleichen Build, sodass immer eine zweite Person zur Verfügung steht erforderlich (aber stellen Sie sicher, dass Sie für Zeiten, in denen einer von Ihnen abwesend ist, Backup-Leute haben).

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

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

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

Sie könnten Ihre Testsuite (Sie haben eine davon, oder?) Mit einer Überprüfung versehen, die feststellt, ob Sie sich auf einem Produktionsserver befinden, und in diesem Fall an alle Mitarbeiter im Büro eine E-Mail mit dem Hinweis senden 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 für Ihr Team beim 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 die Person, die auf dem Prüfstand testet, und Sie könnten sich bei den Leuten im Team, die sich nicht darum kümmern, sehr unbeliebt machen.

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

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

Es ist großartig, dass Sie Verbesserungen des Workflows befürworten, aber es hört sich so an, als würden Sie nicht viel von Ihren Kollegen halten und / oder dass Sie nicht die volle Unterstützung dafür haben. Dies wird wahrscheinlich dazu führen, dass Kollegen nur halbwegs hitzig mit dem Workflow interagieren, das Minimum tun, um Code in die Produktion zu bringen, und nicht wirklich dem Geist des Workflows folgen, was bedeutet, dass mehr Zeit für die Aufklärung aufgewendet wird. Und wenn Sie mehr und 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 so ist (eignet sich der Computer Ihres Kollegen nicht so gut zum Testen? Ist Ihr Kollege nicht sicher, ob es sich um Funktionszweige handelt oder ob er sich in einer svn-Denkweise befindet, in der Festschreiben und Weitergeben identisch sind?), Und erklären Sie, warum es für Sie ein Problem ist, dass nicht getesteter Code verloren geht Überprüfen Sie unter dev / staging / prod, ob Sie etwas tun können, um zu ändern, warum es passiert (Ihr Kollege wird mit größerer Wahrscheinlichkeit das tun, was Sie möchten, wenn Sie es nur angenehmer gemacht haben, vor Ort 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 nachträglichen 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 vor Ort zu testen, und Sie haben nur die Regel, dass keine großen Funktionen für Entwickler ungetestet sind. Notieren Sie sich in der Besprechung, und lesen Sie vor, wie Sie gemeinsam 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 bei einer Retrospektive.

Bei der Arbeit vermeiden wir dies, indem wir Gerrit verwenden . Gerrit ist ein Code-Überprüfungssystem, das als Tor zu Ihrer Haupt- / Produktions-Git-Niederlassung fungiert, die üblicherweise als "Master" bezeichnet wird. Sie haben Code-Reviews, richtig? Es hört sich so an, als ob Sie sie ausnahmsweise persönlich machen. Mit Gerrit wechseln Sie zu einer Art Staging-Zweig, der, nachdem Sie und Ihre Mitarbeiter den Codeüberprüfungsprozess zufriedenstellend ausgeführt haben, zu Ihrem Master-Zweig zusammengeführt wird. Sie können Gerrit sogar mit einem CI-Server verbinden, um Komponententests durchzuführen, bevor jemand eine E-Mail zur Überprüfung einer Änderung erhält. Wenn Sie keinen Server haben, auf dem Sie ein CI-Tool einrichten können, hat Codeship einen kostenlosen Plan, den Sie als Proof-of-Concept verwenden können.

Als letztes müssen Sie natürlich die Produktionsbereitstellungen nur mit genehmigten Build-Produkten automatisieren, die die Codeüberprüfung und den Komponententest überstanden haben. Hierfür gibt es einige coole Technologien, die ich nicht erwähnen werde, aus Angst, es wäre ein Flammenköder.

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.

Ich sehe dies als größtenteils menschliches Problem - der Prozess ist da und die Werkzeuge sind da, aber der Prozess wird einfach nicht befolgt.

Ich stimme mit dem, was andere hier gesagt haben, über die Möglichkeit , dass es die Entwickler in Frage durchaus möglich , ist nur in einer stecken SVN Mentalität und kann auch denken , dass er sich um den Prozess folgen.

Ich bin der Meinung, dass der beste Weg, um diese Art von Problem anzugehen, insbesondere wenn es keinen klaren Vorgesetzten gibt, nicht in der Bestrafung oder dem Entfernen des Zugangs besteht - dies führt nur zu Ressentiments und da es sich so anhört, als ob Sie der lautstarke Befürworter der Befolgung sind Während des Prozesses (es gibt immer einen, und ich war schon einmal „dieser Typ“) sind Sie wahrscheinlich derjenige, der die meiste Hitze bewältigt. Es geht darum, die Menschen zuerst zu einer Einigung über den Prozess zu bringen.

Hier können strukturierte Besprechungen, z. B. Besprechungen vom Typ "Lessons Learned" nach einem großen Produktionsvorfall, sehr nützlich sein. Versuchen Sie, alle zur Zustimmung zu bewegen, einschließlich des betreffenden Entwicklers, dass jedes Mal eine Codeüberprüfung, ein Komponententest, ein umfassender Test usw. stattfinden muss (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, einige feste Regeln für die Vorgehensweise zusammenzustellen. Je mehr der Entwickler, der das Problem verursacht, dazu beiträgt, desto mehr werden sie das Gefühl haben, sich an die Regeln zu halten und zu verstehen, warum ihr Verhalten ein Problem war.

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

Dies ist insbesondere in kleinen Teams nicht ungewöhnlich . Machen Sie keine große Sache darüber, aber 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 auf. Nicht anklagend, erwähnen Sie niemanden beim Namen, sondern etwas Ähnliches wie "Seit wir Versionskontrolle und Bereitstellungsstandards eingeführt haben, sind die Dinge viel einfacher geworden und der Server ist öfter in Betrieb als früher. Das ist großartig! Es ist jedoch immer noch verlockend, eine Verknüpfung zu erstellen und ohne ordnungsgemäße Tests einzureichen. Es ist jedoch ein Glücksspiel, und unser Server ist in Betrieb. Ich schlage vor, dass die verantwortliche Person von nun an Code einreicht, der den Server bricht Donuts für das Team am nächsten Tag. "

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 Schachtel mit 5 US-Dollar Donuts oder Obst- / Gemüsetablett oder Chips und Dip usw. usw. wären wahrscheinlich ärgerlich Dies reicht aus, um das Risiko gegen die Bequemlichkeit des Überspringens von Tests abzuwägen, ohne dass dies zu einer Belastung wird, die sie vom Team oder der Firma abhält.

Nun, wie kann ich sie zwingen ...

Anstatt Ihre Kollegen zu zwingen, lassen Sie sie die Dinge aus Ihrer Sicht sehen. Dies wird die Dinge für alle viel einfacher machen. Welches führt mich in ...

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

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 kannst du tun, damit er die Dinge so sieht, wie du es tust?

Wenn Sie damit Erfolg haben, 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 sie nicht verstehen.

Was ist das Schlimmste, was passieren könnte? Haben Sie Backups, die gut genug sind, um einen Fehler zu beheben, der zufällige Datensätze in Ihrer Datenbank ändert, indem Sie eine alte Version wiederherstellen?

Angenommen, Sie haben einen Fehler, bei dem Sie eine Datensatz-ID verwenden, und versehentlich wird der Rechnungsbetrag 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 das beheben, wenn die Software einige Stunden läuft, bis der Fehler erkannt wird? (Wenn sowohl der richtige Datensatz als auch Datensatz 1234 aktualisiert werden, würden Sie dies nur erkennen, wenn Datensatz 1234 verwendet wird, sodass dies für eine Weile unerkannt bleiben könnte.)

Fragen Sie jetzt 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.

Sie verstehen verschiedene mögliche verfahrenstechnische und technische Lösungen. Die Frage ist, wie der Mitarbeiter zu verwalten ist.

Dies ist im Wesentlichen eine Übung zum Änderungsmanagement.

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

Zweitens arbeiten Sie in einem kleinen Team und es lohnt sich wahrscheinlich, das gesamte Team für Prozessverbesserungen 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
• Engagieren Sie sich bei der Umsetzung dieser Praktiken

Es sollte selbstverständlich sein, dass das gesamte Team dann auch dazu beiträgt, dass die verbesserten Praktiken eingehalten werden.

Ich denke, Sie haben ein paar 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, einfach in die Produktion übernommen werden kann.

Ehrlich gesagt denke ich, dass das Setup einfach verrückt ist. Mindestens die Personen, die manuell einen Push für die Produktion auslösen können, sollten auf die Personen beschränkt sein, denen vollkommen vertraut werden kann , um alle ausgehenden Änderungen (unabhängig davon, wer die Änderungen erstellt hat) gründlich zu überprüfen und zu testen, bevor der Push ausgelöst wird. Wer die Berechtigung zum Einchecken von Code hat, willkürlich einen Push für die Produktion auslösen zu können, bittet nur um Ärger. Nicht nur von sorglosen und / oder inkompetenten Entwicklern, sondern auch von verärgerten oder böswilligen Dritten, die zufällig eines Ihrer Konten kompromittieren.

Und wenn Sie jede eingecheckte Änderung per Knopfdruck bereitstellen möchten, müssen Sie über eine umfassende Suite automatisierter Tests verfügen und diese per Knopfdruck ausführen (und die Bereitstellung abbrechen, wenn alle tests scheitern!). Ihr Prozess sollte nicht zulassen, dass Code, der noch nicht einmal oberflächlich getestet wurde, den Punkt erreicht, an dem er überhaupt auf dem Produktionssystem bereitgestellt wird.

Ihr Mitarbeiter hat einen großen Fehler beim Einchecken von Code gemacht, ohne ihn zuvor zu testen. Ihre Organisation hat einen weitaus größeren Fehler begangen, als sie einen Bereitstellungsprozess einführte, der es ungetestetem Code ermöglicht, unter allen Umständen die Produktion zu erreichen.

Die erste Aufgabe besteht also darin, den Bereitstellungsprozess zu korrigieren. Begrenzen Sie entweder, wer einen Push für die Produktion auslösen kann, oder integrieren Sie eine angemessene Menge an Tests in Ihren automatisierten Bereitstellungsprozess, oder beides.

2. 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 eine klare " Definition von erledigt " vermissen und / oder eine Definition verwenden, die nicht "der Code wurde getestet" enthält, um den Code in der Produktion zu überprüfen / bereitzustellen. Wenn Sie dies getan 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 der Zukunft besser sein muss Zukunft".

Sie sollten versuchen, eine Kultur zu etablieren, die klar kommuniziert, was von Entwicklern erwartet wird und welche Standards und Qualitätsstandards sie einhalten sollen. Das Einrichten einer Definition von "erledigt", die mindestens manuelle Tests (oder vorzugsweise automatisierte Testfälle, die als Teil des Erstellungs- / Bereitstellungsprozesses ausgeführt werden können) umfasst, hilft dabei. Da kann es Konsequenzen für den Abbruch des Builds geben. Oder schwerwiegendere Konsequenzen für den Bruch des Produktionssystems. Beachten Sie, dass diese beiden Dinge wirklich unabhängig voneinander sein sollten und es absolut unmöglich sein sollte, sowohl den Build als auch das Produktionssystem gleichzeitig zu unterbrechen (da beschädigte Builds niemals bereitgestellt werden sollten).

Sie sollten einen kontinuierlichen Integrations- und Peer-Review-Prozess in das Unternehmen integrieren. Bitbucket macht es einfach.

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

Seien Sie nicht unhöflich mit ihm, es wird nur Ihre Arbeitsbeziehung verletzen.