Mein Kollege legt fest und drückt ohne zu testen


113

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.


1
Kommentare sind nicht für eine längere Diskussion gedacht. Diese Unterhaltung wurde in den Chat verschoben .
Weltingenieur

5
Verwenden Sie auf Git Pull-Anforderungen, um Codeüberprüfungen zu erzwingen, bevor Sie sie in Master zusammenführen und für die Produktion bereitstellen. Entfernen Sie außerdem seine Anmeldeinformationen, um sich beim Bereitstellungsserver anzumelden. Zentralisieren Sie diese Berechtigung in einem Nicht-Entwickler. (PCI-Konformität, die von der Kreditkartenindustrie durchgesetzt wird, erfordert dies übrigens.)
Barett

3
Aus Sicht des Arbeitsplatzes ist es unwahrscheinlich, dass Sie, wenn Sie mit dieser Person zusammenarbeiten und nicht in irgendeiner Weise deren Vorgesetzter sind, durch „Bestrafung“ an Boden gewinnen. Konzentrieren Sie sich darauf, die Qualität des Codes zu gewährleisten, und achten Sie nicht auf die nachlässigen Standards Ihres Kollegen.
Zibbobz,

2
Löst ein Push zum "zentralen" Repository immer eine Produktionsbereitstellung aus? Das sollte es definitiv nicht.
jpmc26

3
Ich las die Frage und sagte mir, dass der Typ türkisch sein muss und los geht's :) Schau dir das an bro: nvie.com/posts/a-successful-git-branching-model . Sie müssen mindestens zwei Zweige haben: master und dev, bei denen Entwickler nur auf dev pushen. Nach dem Testen werden Sie zu master und deploy zusammengeführt.
Cemre

Antworten:


92

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.


Die Idee der Unterstützung bei der Durchführung der Qualitätssicherung, bei der die Freigabe an die Produktion erfolgt, erscheint zweckmäßig, wird jedoch aus Gründen der Funktionstrennung nicht in Frage kommen. Der Support, der über das Ende des "Programmierertests" hinaus für den Support verantwortlich ist, sollte sie auf Änderungen aufmerksam machen. Bei vier Entwicklern und niemand anderem ist es wirklich schwierig :-) Wenn Sie Ihre Antwort ändern, um sie direkt auf das Setup des OP anzuwenden, dann ist es wird niemandem viel nützen ...
Bill Woodger

1
@ BillWoodger warum? Für sie ist es ein "bevorstehendes Change and Rollback" -System. Sie erhalten nicht nur den Vorteil, dass sie sehen, was auf sie zukommt, bevor es „real“ wird, sondern können auch problemlos auf die letzte Version zurückgesetzt werden, wenn Probleme auftreten. Vergessen Sie nicht, dass die Testumgebung das Ende des Programmierertests darstellt.
Gbjbaanb

1
@gbjbaanb, da dies den Support in die gleiche Position bringt und das ursprüngliche Problem erneut darstellt. Der Support hätte in der Regel einen Notfallzugang zur Produktion. Wenn sie auch anderen Zugriff haben, haben Sie Prüfungsprobleme (wenn das wichtig ist). Wenn jemand etwas ändern kann, liegt ein Problem vor. Natürlich Unterstützung sollte wissen alles, sollten sie nicht in der Lage sein , zu tun alles. Das sagt jeder Auditor, mit dem ich jemals zu tun hatte, und sie haben mich vor langer Zeit davon überzeugt.
Bill Woodger

@ BillWoodger Ich bin nicht sicher, was du sagst. Produktionsteams, die ich kenne, haben normalerweise ihre eigenen Rollout-Prozesse, die eine Testumgebung enthalten (nur um zuerst nach dummen Fehlern zu suchen). In einem kleinen Team gibt es keinen Grund, warum Entwickler und Support dieses Testsystem nicht gemeinsam nutzen können. Es dürfen sowieso keine Änderungen daran vorgenommen werden - es wird von dev über die Automatisierung aufgefüllt und vom Support konsumiert. Nicht anders, als ihnen eine Postleitzahl mit dem gleichen Code zu geben. Auditoren befassen sich mit Prozessen, nicht mit der Implementierung dieser Prozesse (außer dass sie natürlich befolgt werden)
gbjbaanb

1
Die Prüfer von @gbjbaanb befassen sich mit Menschen, die Zugang zu allem haben. Wenn ein Support-Mitarbeiter ein Programm in der Entwicklung ändern und in die Produktion übernehmen kann, ohne dass jemand anderes eingreift, wird das System angezeigt. Sicher, mit den vier Mitarbeitern von OP gibt es sowieso keine separate "Unterstützung", und eine zufriedenstellende Aufteilung der Funktionen wird schwierig.
Bill Woodger

54

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.


10
+1 für das Gespräch. Es muss ein gemeinsames Verständnis geben, dass dies ein Problem ist und warum es ein Problem ist. Nur dann kann eine technische Lösung zum Erfolg führen.
Patrick

9
+1 für das Abrufen von Entwicklungsserver- / Staging-Umgebungen. Solange es keinen wirklichen Ort außerhalb der eigenen Maschine gibt, um Dinge voranzutreiben, ist dieses Verhalten nicht ausschließlich die Schuld des Mitarbeiters. Es gibt nur so viel, was eine Person auf ihrer eigenen Maschine tun kann, und wenn nichts anderes hilft die zusätzliche Umgebung oft bei einer Änderung des Denkprozesses / der Einstellung beim Testen.
Joel Coehoorn

20

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.


17

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.


1
Mir ist wirklich nicht klar, wie "Commit / Push, sofortige Bereitstellung in der Produktion und Testen Ihrer Änderungen dort und nirgendwo sonst" eine SVN-Denkweise ist ... Der einzige Teil dieses Prozesses, der SVN beinhalten würde, ist das Commit. Selbst bei einem Modell mit einer einzelnen Verzweigung oder einer Quellcodeverwaltung bedeutet ein Festschreiben nicht unbedingt eine Produktionsbereitstellung. Zumindest sollte es nicht so sein.
Jpmc26

@ jpmc26: Auf die Gefahr eines Git / SVN-Flammenkrieges: Wir haben ein SVN-System für einen Großteil unseres "Legacy" -Codes geerbt, aber Git für unsere neuere Arbeit verwendet. Ich kann fast garantieren, dass wir nicht das richtige SVN-Setup hatten und / oder es nicht richtig verwendeten, aber Gits Umgang mit Zweigen fühlt sich viel einfacher an, mit ihnen zu arbeiten. Ich bin zu 100% sicher, dass SVN mehr als in der Lage ist, eine ordnungsgemäße Bereitstellung zu gewährleisten, aber ich kann (aus meiner unvollständigen Erfahrung) auch sehen, wie SVN Sie möglicherweise davon abhält, das Richtige zu tun. In jedem Fall wäre dies nur ein beitragender Faktor, und die Schulung des Benutzers ist wichtiger.
TripeHound

1
@TripeHound Kein Argument dafür, dass das Git-System insgesamt besser für die Verwaltung von Codeänderungen geeignet ist. (Meine Einwände gegen git haben im Allgemeinen mit der hohen Lernkurve zu tun.) Mein Punkt ist, dass git zwar mehr Funktionen für die Verwaltung Ihres Veröffentlichungsprozesses bietet, die Art und Weise, wie Sie Ihre Build-Infrastruktur einrichten, jedoch immer noch der Hauptfaktor für Sie ist Wahl der Quellcodeverwaltung. Ich hatte eine ziemlich erfolgreiche Build- und Release-Automatisierung in SVN, daher ist mir nicht klar, was eine "SVN-Denkweise" ist oder wie sie sich negativ auf Ihr Release auswirkt.
jpmc26

2
Nur weil Sie sich zum Master bekennen, heißt das noch lange nicht, dass Sie die Bereitstellung in der Produktion durchführen sollten. Auch wenn Ihr Origin Repo / SVN Repo auf dem Prod Server gehostet wird, bedeutet dies nicht, dass dies der Fall ist.
vonPetrushev

12

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.


2
Dies funktioniert nur mit einem Büro. Was ist das äquivalente Konzept für ein verteiltes Team von Remote-Entwicklern, die alle von zu Hause aus arbeiten?
Donnerstag,

2
@aroth Für einige Teams ist eine einfache teamweite E-Mail von der Person, die den Build gebrochen hat, ausreichend. Planen Sie es als ein "kontinuierliches Prozessverbesserungsziel" und bitten Sie die E-Mail, genügend Informationen zu enthalten, damit andere sehen können, was schief gelaufen ist, warum es schief gelaufen ist und was diese Person an ihrem Prozess ändern wird oder was sie dem Team vorschlagen, sich zu ändern der Prozess, um zu verhindern, dass es wieder passiert. Die meisten Leute hassen Berichte und Berichterstattung, und es ist schon wieder ärgerlich genug, dass sie in Zukunft vorsichtiger sind, den Build nicht zu brechen.
Adam Davis

8

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.


6

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.


"Haben Sie Backups, die gut genug sind?" - und wenn ja, möchte Ihr Kollege die Muggins sein, die das Backup wiederherstellen müssen, weil er den Server kaputt gemacht hat? Vielleicht würde er gerne im Prinzip vor der Bereitstellung zu testen, aber da es keine Testumgebung ist hat er die einfachste derzeit verfügbare Option nehmen. Dann sollte es einfach sein, einen Test-Server zu finden. Übrigens, Fehler, die "für eine Weile" unentdeckt bleiben, werden den Test bis zur Bereitstellung durchlaufen, da das Problem bei solchen Fehlern die Qualität der Tests ist und nicht, wo die Tests durchgeführt werden.
Steve Jessop

Sie haben nicht nur die Backups, sondern können sich auch die Ausfallzeit Ihres Unternehmens leisten, während eine Wiederherstellung durchgeführt wird? Und kann es sich leisten, Minuten, Stunden oder sogar Tage an Informationen zu verlieren, weil ein Rollback der Datenbank durchgeführt werden musste? Ich würde sagen, in fast allen nichttrivialen Fällen ist die Antwort ein klares Nein. Und selbst in trivialen Fällen möchten Sie nicht, dass bei der Wiederherstellung eines Backups sichergestellt wird, dass nicht getesteter Code eingecheckt wird. Es muss sichergestellt sein, dass die Tests zwischen dem Einchecken des Codes und dem Erreichen der Produktion stattfinden.
Donnerstag,

Völlig einverstanden, deshalb habe ich gesagt "Fragen Sie Ihren Entwickler, was er darüber denkt". Entweder ist er völlig getäuscht und glaubt, sein Code sei fehlerfrei, oder er erkennt nicht, welchen Schaden er anrichten kann. Oder die dritte Möglichkeit, die er kennt und die ihm egal ist.
gnasher729

3

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.


Eine Retrospektive ist eine großartige Möglichkeit, dieses Verhalten auf konstruktive Weise anzugehen und hoffentlich zu ändern!
GreenSocksRock

1

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.

  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 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).


0

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.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.