Wie kann ich Cowboy-Programmierer von der Verwendung der Quellcodeverwaltung überzeugen?

UPDATE
Ich arbeite in einem kleinen Team von Entwicklern, 4 Leuten. Sie haben alle Quellcodeverwaltung verwendet. Die meisten von ihnen können die Quellcodeverwaltung nicht aushalten und entscheiden sich stattdessen, sie nicht zu verwenden. Ich bin der festen Überzeugung, dass die Quellcodeverwaltung ein notwendiger Bestandteil der beruflichen Entwicklung ist. Verschiedene Probleme machen es sehr schwierig, sie von der Verwendung der Quellcodeverwaltung zu überzeugen:

• Das Team ist nicht an TFS gewöhnt . Ich hatte 2 Trainingseinheiten, aber es wurde nur 1 Stunde zugeteilt, was nicht ausreicht.
• Die Teammitglieder ändern den Code direkt auf dem Server. Dies hält den Code nicht synchron. Ein Vergleich ist erforderlich, um sicherzugehen, dass Sie mit dem neuesten Code arbeiten. Und es entstehen komplexe Zusammenführungsprobleme
• Die von den Entwicklern angebotenen Zeitschätzungen schließen die zur Behebung dieser Probleme erforderliche Zeit aus. Wenn ich also nono sage, dauert es 10x länger ... Ich muss diese Probleme ständig erklären und mich selbst riskieren, weil mich das Management jetzt als "langsam" wahrnimmt.
• Die physischen Dateien auf dem Server unterscheiden sich in unbekannter Weise über ~ 100 Dateien. Das Zusammenführen erfordert Projektkenntnisse und daher eine nicht erreichbare Entwicklerkooperation.
• Andere Projekte sind nicht mehr synchron. Entwickler haben weiterhin ein Misstrauen gegenüber der Quellcodeverwaltung und verschärfen das Problem, indem sie die Quellcodeverwaltung nicht verwenden.
• Entwickler argumentieren, dass die Verwendung der Quellcodeverwaltung verschwenderisch ist, da das Zusammenführen fehleranfällig und schwierig ist. Dies ist schwierig zu argumentieren, da die Quellcodeverwaltung in der Tat fehleranfällig ist, wenn sie so stark missbraucht und ständig umgangen wird. Daher sprechen die Beweise aus ihrer Sicht "für sich".
• Entwickler argumentieren, dass das direkte Ändern des Servercodes unter Umgehung von TFS Zeit spart. Dies ist auch schwer zu argumentieren. Da das Zusammenführen, das zum Synchronisieren des Codes erforderlich ist, zu Beginn sehr zeitaufwendig ist. Multiplizieren Sie dies mit den 10+ Projekten, die wir verwalten.
• Permanente Dateien werden häufig im selben Verzeichnis wie das Webprojekt gespeichert. Beim Veröffentlichen (vollständige Veröffentlichung) werden diese Dateien gelöscht, die sich nicht in der Quellcodeverwaltung befinden. Dies führt auch zu Misstrauen gegenüber der Quellcodeverwaltung. Weil "Veröffentlichung das Projekt bricht". Das Beheben dieses Problems (das Verschieben gespeicherter Dateien aus den Lösungsunterordnern) ist sehr zeitaufwendig und umständlich, da diese Speicherorte nicht in der Datei web.config festgelegt sind und häufig über mehrere Codepunkte verteilt sind.

Die Kultur bleibt also bestehen. Schlechtes Üben erzeugt mehr schlechtes Üben. Schlechte Lösungen treiben neue Hacks dazu, tiefere und zeitaufwändigere Probleme zu "beheben". Server und Festplattenspeicher sind extrem schwer zu bekommen. Die Erwartungen der Nutzer steigen jedoch.

Was kann in dieser Situation getan werden?

Es ist kein Trainingsthema, sondern eine Frage der menschlichen Faktoren. Sie wollen nicht und schaffen Straßensperren. Beschäftige dich mit der zerbrochenen Gruppendynamik, was die Hauptursache für ihren Einwand ist - normalerweise Angst, ist es nur Angst vor Veränderung oder ist es finsterer.

Kein professioneller Entwickler hat sich heute oder in den letzten 20 Jahren der Quellcodeverwaltung widersetzt. Vor ungefähr 30 oder 40 Jahren, als Computer langsam waren, die Quellcodeverwaltung noch langsamer und Programme aus einer Datei mit 500 Zeilen bestanden, war dies ein Schmerz und es gab triftige Gründe, sie nicht zu verwenden. Diese Einwände können nur von den schlimmsten Cowboys stammen, die ich mir vorstellen kann.

Wird ihnen das System auf irgendeine Weise das Leben schwer machen? Finden Sie heraus, um was es sich handelt, und ändern Sie das System, um den Einwand aufzuheben. Wiederholen, bis fertig.

Ich schlage vor, GIT oder Mercurial zu betrachten. Sie können in jedem Quellcodebaum ein Repository erstellen, das sie nicht einmal bemerken und das sie weiterhin so hacken können, wie sie es jetzt tun. Sie können die Änderungen, die sie in die Codebasis gehackt haben, nachverfolgen, Festschreibungen vornehmen, sie in anderen Quellbäumen zusammenführen usw. Wenn sie sehen, dass Sie innerhalb von Sekunden eine Zusammenführung von mehr als einwöchigem Aufwand in ein anderes Produkt durchführen, ändern sie möglicherweise ihre Ideen. Wenn Sie einen ihrer Fehler mit einem Befehl rückgängig machen und ihren Hintern retten, bedanken sie sich möglicherweise sogar bei Ihnen (rechnen Sie nicht damit). Im schlimmsten Fall siehst du vor dem Chef gut aus und lässt sie als Bonus wie die Cowboys aussehen, die sie sind.

Das Zusammenführen würde nicht nur eine gute Kenntnis des Projekts voraussetzen

In diesem Fall fürchte ich, dass Sie ohne Paddel den sprichwörtlichen Bach hinauf sind. Wenn das Zusammenführen keine Option ist, wird es auch nicht implementiert. Sie sagen also, dass Sie Features, die Sie bereits in einem Zweig (Begriff, der nur lose verwendet wird) haben, nicht mehr zu einem anderen Zweig hinzufügen können.

Wenn ich Sie wäre, würde ich meine Karrierechancen überdenken ...

Manchmal machen es reale Probleme unpraktisch, sie zu verwenden.

Falsch.

Wenn das Team nicht an die Verwendung der Quellcodeverwaltung gewöhnt ist, können Trainingsprobleme auftreten

Das hat nichts mit Quellcodeverwaltung und alles mit Training zu tun. Das Training ist einfach, kostengünstig, effizient und in wenigen Stunden erledigt. Die Verwendung der Quellcodeverwaltung ist kostspielig, riskant und ineffizient, und die Probleme bleiben für immer bestehen .

Wenn ein Teammitglied den Code auf dem Server direkt ändert, können verschiedene Probleme auftreten.

Das ist das Trainingsproblem. Nochmal. Nichts zu tun mit der Quellcodeverwaltung und alles was mit Training zu tun hat.

Entwickler haben weiterhin ein Misstrauen gegenüber der Quellcodeverwaltung und verschärfen das Problem, indem sie die Quellcodeverwaltung nicht verwenden

Sie müssen im Umgang mit der Quellcodeverwaltung geschult werden. Es senkt die Kosten, reduziert das Risiko, vereinfacht die Dinge und ist effizienter. Es ist eine einmalige Investition, die sich jeden Moment auszahlt.

Was kann in einer solchen Situation getan werden?

Beginnen Sie mit der Schulung aller Benutzer zur Verwendung der Quellcodeverwaltung.

Aktualisieren

Entwickler argumentieren, dass das direkte Ändern der Quellcodeverwaltung Zeit spart.

Da sie falsch liegen, ist es wichtig, Daten zu sammeln, um genau zu zeigen, wie falsch dies ist.

Leider scheint das Management eine sofortige Reaktion zu belohnen, die auf lange Sicht kostspielig ist.

Der einzige Weg, dieses Belohnungssystem zu überwinden, ist zu

A) Stellen Sie fest, dass die langfristigen Kosten höher sind als der scheinbare kurzfristige Wert.

B) Identifizieren Sie die tatsächlichen Belohnungen, die kurzfristige Korruption (dh direkte Änderungen) wertvoller erscheinen lassen als eine langfristig korrekte Quellcodeverwaltung. Wer bekommt einen Klaps auf den Kopf, weil er das Falsche getan hat? Welche Art von Kopfschmerzen bekommen sie? Wer gibt es Um die Probleme zu beheben, müssen Sie die Fehler benennen und die Manager, die die Leute tatsächlich ermutigen.

C) Empfehlen Sie ein überarbeitetes Belohnungssystem, bei dem der langfristige Wert anstelle einer kurzfristigen schnellen Reaktion bewertet wird. Verschiedene Streicheleinheiten auf dem Kopf aus verschiedenen Gründen.

D) Trainiere die Leute mit den Belohnungen, die du für langfristigen Wert gefunden hast. Wert, der deutlich größer ist als die kurzfristige schnelle Reaktion.

Entwickler, die sich weigern, die Quell- / Versionskontrolle zu verwenden, sollten so einfach wie möglich entlassen werden. Wie Sie bereits dargelegt haben, überwiegen die Risiken und Kosten, die mit der NICHT-Verwendung verbunden sind, die damit verbundenen Gemeinkosten um viele, viele Größenordnungen. Wer dagegen argumentieren will, sollte nicht in die Softwareentwicklung involviert sein, und ich würde es mit Sicherheit ablehnen, mit solchen Leuten zusammenzuarbeiten.

Wir haben das Problem zuerst gelöst, indem wir einen Continuous Integration Server eingerichtet haben, um unsere Quellcodeverwaltung in dev zu integrieren. Zweitens: Sperren Sie den Ordnerzugriff auf schreibgeschützte Dateien, um zu verhindern, dass Benutzer die Quellcodeverwaltung umgehen und Dateien direkt ändern.

Es ist ein PITA an Tagen, an denen Sie den Fehler nicht lokal reproduzieren können, aber ansonsten ist es besser, arbeiten, einchecken und weitermachen zu können, da Sie wissen, dass er vom CI-Server automatisch an dev weitergeleitet wird.

Ich höre deinen Schmerz. Ich bin an einigen Arbeitsplätzen vorbeigekommen, um herauszufinden, dass es sich bei der Quellcodeverwaltung um einen freigegebenen Ordner auf einem Netzlaufwerk handelt. Das Problem liegt im Allgemeinen nicht darin, dass sie der Meinung sind, dass dieser Ansatz allem anderen überlegen ist. Er funktioniert einfach und sie haben noch nie einen Workflow kennengelernt, der die Quellcodeverwaltung erfolgreich integriert.

Mit der Teamstruktur von Flat Earth, die Sie erklärt haben, ist es möglicherweise nicht der beste Weg, sich der Situation anzunähern, wenn die Änderung von oben nach unten gedrückt wird. Eine Methode, die es wert ist, ausprobiert zu werden, besteht darin, sich direkt von einem oder zwei anderen Entwicklern einzukaufen, damit das Konzept an Fahrt gewinnt. Sobald Sie auch nur einen anderen Entwickler an Bord haben, ist es viel einfacher, ihn auf den Rest des Teams zu übertragen. Führen Sie sie langsam in das Konzept ein, sagen Sie, beginnen Sie mit der Arbeit an einem kleinen Nebenprojekt, bringen Sie es in Git zum Laufen oder verzweigen Sie sogar etwas, das auf GitHub gehostet wird .

Fangen Sie einfach an und führen Sie die Konzepte langsam und getrennt von ihrem täglichen Arbeitsablauf ein. Menschen sind großartig darin, Dinge zu lernen und sich an Veränderungen anzupassen, besonders wenn diese Veränderungen einen direkten Nutzen für sie haben (denken Sie an Evolution). Wenn es jedoch mit einer ganzen Reihe kleiner Änderungen auf einmal präsentiert wird, wird es entfremdend. Sobald sie einen Überblick über die Funktionsweise und die Vorteile der Quellcodeverwaltung haben, können Sie versuchen, sie in ein internes Projekt zu integrieren (wenn Sie ein neues Projekt starten, ist dies eine schlechte Zeit, um es vorzustellen). Wenn Sie möchten, können Sie auch die anderen Projekte auf die vorhandene Weise ausführen. Dies ist besonders hilfreich, um die Vorteile einer angemessenen Codekontrolle hervorzuheben.

Wenn dies fehlschlägt, führen Sie aus.

Sie haben offensichtlich die technischen Fähigkeiten, um Ihre Situation zu identifizieren und zu beheben. Ihre Probleme sind menschlich und prozessbezogen.

Die Leute neigen dazu, viel besser auf ein Beispiel als auf eine Vision zu reagieren, daher würde ich vorschlagen, es selbst zu "reparieren":

Nehmen Sie eine Kopie der neuesten Quelle, strukturieren Sie sie zur Versionskontrolle um, erstellen Sie ein neues Projekt mit einer nützlichen, vorausschauenden Struktur (überlegen Sie, wie Sie mit Zweigen umgehen, wo Sie Abhängigkeiten von Drittanbietern usw. platzieren). Sie werden das wahrscheinlich in Ihrer eigenen Zeit tun müssen.

Ziehen Sie dann Ihre Mitarbeiter und das Management in einen Raum und zeigen Sie ihnen, wie die Softwareentwicklung im 21. Jahrhundert aussieht. Veranschaulichen Sie die Fehler in Ihrem aktuellen System und zeigen Sie, wie sie mit Ihrer neuen Struktur behoben werden.

Sie müssen sich auch als Bewahrer der Quelle aufstellen - da Sie der einzige zu sein scheinen, der sich darum kümmert, liegt es an Ihnen, die Menschen (mit welchen technischen oder psychologischen Mitteln auch immer) dazu zu zwingen, sich daran zu halten der Plan. Stellen Sie sicher, dass das Einzige, was ein Kunde erhält, von einem Buildcomputer stammt, der sich außerhalb der Quellcodeverwaltung befindet. Menschen, die gegen die Regeln verstoßen und Chaos anrichten, rituell demütigen. Besteche sie mit Donuts ... was auch immer funktioniert.

Wenn das alles nach zu viel Aufwand aussieht (wie in fast jeder anderen Antwort gesagt wurde), holen Sie sich einen anderen Job. Sie sind Ihre Zeit nicht wert.

Schritt 1 - Feuer inkompetenten Manager!

Wenn Sie Schritt 1 nicht ausführen können, versuchen Sie, den Manager zu veranlassen, die Bereitstellung auf Skripts zu beschränken, die nur aus der Quellcodeverwaltung stammen. Wenn Entwickler (die keine Produktionsrechte für Produkte haben sollten, siehe Schritt 1, falls sie dies tun) möchten, dass ihre Produkte bereitgestellt werden, muss dies aus der Quellcodeverwaltung stammen. Damit haben wir das Problem behoben, dass die Quellcodeverwaltung nicht mehr so ​​gut funktioniert, als wir sie zum ersten Mal für Datenbanksachen und C # -Code verwendeten.

Wie kann jemand nicht unterschiedliche Versionen seiner Dateien und die Fähigkeit, die Unterschiede zu sehen, wollen? Vergessen Sie Verzweigungen und die komplexen Dinge. Sie bekommen nicht einmal die Grundlagen. Das direkte Ändern einer Produktionsdatei, ohne die rudimentärsten Änderungen in einer Testumgebung vorzunehmen, ist verrückt. Ich habe mit einigen Leuten zusammengearbeitet und zum Glück haben wir nie an denselben Projekten gearbeitet.

Ihre Mitarbeiter sind zu dumm, um faul zu sein. Das ist Zeitverschwendung. Sie können nur hoffen, Ihren Manager zu schulen. Das Management sollte die Quellcodeverwaltung mögen, weil es alle Formen der Kontrolle mag. Sie fühlen sich wichtig. Scheiß auf die anderen. Die Reparatur des Anführers ist Ihre einzige Hoffnung, da Sie ihn nicht ersetzen können. Beginnen Sie das Networking mit anderen kompetenten Entwicklern und versuchen Sie, diese dazu zu bringen, sich Ihrem Team anzuschließen, wenn Sie eine Eröffnung haben, oder sie zu veranlassen, Sie in ihrem Geschäft einzustellen.

Dies ist ein gutes Beispiel für ein Projekt, bei dem schlechte Praktiken so verbreitet waren, dass es praktisch unmöglich wird, sie zu beheben. Das Reparieren würde ein Einfrieren erfordern, so dass alles ohne Unterbrechung aufgeräumt werden kann. Leider sind solche Projekte normalerweise (aus offensichtlichen Gründen) zu fehlerhaft, um für mehrere Monate eingefroren zu werden. Kritische Fehler müssen jeden zweiten Tag behoben werden.

Sie könnten versucht sein, das Projekt aufzuteilen, um eine saubere Version zu erstellen, während die fehlerhafte Version mit diesen täglichen Bugfixes behandelt wird. Aber das wahrscheinlichste Ergebnis ist, dass nach einigen Monaten, wenn die "saubere" Version fertig ist, niemand mehr sagen kann, welche Fehlerbehebungen und Änderungen seit der Veröffentlichung vorgenommen wurden (denn die gleiche Denkweise, die es den Leuten ermöglicht, sich in solche Praktiken hineinzuversetzen, macht es unwahrscheinlich, dass Sie führen Aufzeichnungen über die vorgenommenen Änderungen. Die saubere Version ist veraltet, die schmutzige Version funktioniert immer noch. Was passiert also? Die saubere Version ist entleert, die Neinsagen haben sich als richtig erwiesen.

Abgesehen von der offensichtlichen Suche nach einem neuen Job, denke ich, ist die Antwort eher all das oben Gesagte.

Wenden Sie sich zunächst an die Geschäftsleitung, um sie für die Einführung und Durchsetzung der Quellcodeverwaltung zu gewinnen. Machen Sie sich an die Arbeit, um den Betrieb aufrechtzuerhalten, auch wenn dies bedeutet, dass Sie direkt auf dem Server arbeiten. Starten Sie den Vorgang, um alles in die Quellcodeverwaltung zu bekommen.

Eine andere Möglichkeit besteht darin, sicherzustellen, dass sich die neueste Version auf dem Server befindet (was Sie unabhängig davon tun müssen), und ein neues Repository insgesamt ab der neuesten Version zu starten. Sie werden die Geschichte verlieren, aber an diesem Punkt sind das kleine Kartoffeln.

Aus Ihrer Beschreibung geht hervor, dass es ein oder mehrere Probleme mit der Situation gibt - entweder ist das Entwicklerteam außer Kontrolle oder es wurde eine schlechte Versionskontrolllösung implementiert. In jedem Fall ist es Sache des Entwicklerteams, eine Versionsverwaltungslösung zu verwenden. Das direkte Ändern des Quellcodes im Produktionsdienst ist nur eine Bitte, um Probleme zu verursachen.

Nach meiner Erfahrung besteht der erste Schritt, der sofort ausgeführt werden muss, darin, die Quellcodeverwaltung mit dem Produktionsserver zu synchronisieren. Dieser Schritt kann so einfach sein, wie eine Kopie des Produktionscodes zu erstellen und einzuchecken - der Produktcode ist vermutlich die Basis, die Ihr Team entwickelt. Dieser Schritt muss möglicherweise durch eine Zusammenführung mit Code ergänzt werden, der im vorhandenen Quellcodeverwaltungssystem schwebt. Der Code sollte von dev zu integration / QA (oder beiden) und dann entweder zu stage oder stage / production fließen.

Als Nächstes muss das Management die Verwendung der Quellcodeverwaltung vorschreiben. Ganz einfach, wenn der Build nicht aus dem Versionsverwaltungssystem stammt, sollte der Code nicht für die Produktion bereitgestellt werden. Der Produktionszugriff muss nur auf das Support-Team beschränkt werden, und der Entwickler muss nur eingeschränkten Zugriff haben, um Produktionsprobleme zu beheben. Entwickler sollten im Allgemeinen niemals Hot Deployments von Code für die Produktion durchführen - Produktionsprobleme können definitiv auftreten, insbesondere wenn die Entwickler unter Druck stehen.

Das Management muss die Probleme hier definitiv besser in den Griff bekommen - es wird fast unmöglich sein, die Entwicklung aufrechtzuerhalten, wenn Code direkt auf Produkte angewendet wird (und nicht in die Quellcodeverwaltung gelangt).

Das eigentliche Problem ist nicht, dass die Cowboy-Codierer keine Versionskontrolle verwenden. Das eigentliche Problem ist, dass sie sich bereits für eine Vorgehensweise entschieden haben und Sie versuchen, ihren Prozess zu ändern. Der ausgewählte Prozess enthält keine Versionskontrolle. Alle Prozessänderungen sind schwierig, es sei denn, die Programmierer bemerken selbst ein Problem. Wenn es das Gefühl gibt, dass das bestehende System gut genug ist, ist es einfach vergeblich, ein anderes System durchzusetzen. Wir sind die Borg, Sie werden assimiliert. Natürlich versuchen sie zu kämpfen, um Borg zu werden.

Zu Ihrer eigenen Sicherheit würde ich empfehlen, Git oder ein anderes DVCS auf Ihrem eigenen Computer einzurichten, damit Sie Änderungen nachverfolgen können. Importieren Sie die Änderungen Ihrer Mitarbeiter häufig in Ihr Repository. Lösen Sie Konflikte so gut wie möglich. Dies schützt Sie teilweise vor dem Wahnsinn Ihrer Mitarbeiter.

Sie haben erwähnt, dass das Management festgelegt hat, dass Entwickler die Quellcodeverwaltung verwenden sollten. Wenn Sie böse sein möchten, können Sie dies erzwingen, indem Sie Änderungen in TFS einchecken und das Repository regelmäßig veröffentlichen, wodurch alle Änderungen, die nicht in TFS enthalten sind, blockiert werden. (Wenn Sie auch Ihr eigenes DVCS verwalten, sollten Sie die beiden synchron halten.) Ihre Rechtfertigung dafür ist, dass Sie die Anweisungen des Managements befolgen. Wenn Ihre Mitarbeiter es satt haben, Änderungen zu überschreiben, laden Sie sie ein, TFS zu verwenden. Machen Sie so lange weiter, bis Ihre Kollegen nachgeben oder Sie entlassen werden.

Sperren Sie alle Server außer deren Entwicklung. Verwenden Sie einen Konfigurationsmanager. Erstellen Sie regelmäßig identifizierbare Builds (gegen Tags). Kennzeichnen Sie jeden Änderungssatz (dh 1 Änderungssatz pro Fehler). Wir haben auch jedem Build ein Tag hinzugefügt. Haben Sie ein QS-System zwischen Entwickler und Produktion (mindestens). Erstellen Sie das QS-System mit dem richtigen Build-Tag. Gib ihnen Trauer, weil sie "den Bau gebrochen" haben.

Ich bin noch nie auf eine Situation gestoßen, in der ich ein Problem nicht neu erstellen / beheben konnte (das nur in der Produktion angezeigt wird). Ja, ich habe Stunden damit verbracht, das Problem auf einem Entwicklungssystem wiederherzustellen (und wenn Sie es herausfinden, können Sie es Ihrem Regressionstest hinzufügen).

Wir haben ein Projekt mit ein paar Cowboy-Auftragnehmern durchgeführt, die all diese schlechten Dinge getan haben. Ich verbringe danach 4 Wochen damit, aufzuräumen, und setze dann die oben genannten Praktiken ein. Das Projekt hatte seitdem keine Probleme mit all diesen Dingen.

Zitat:

Das Team ist nicht an TFS gewöhnt

TFS stellt sich als Microsoft Team Foundation Server heraus.

Mein erster Instinkt sagt: "Dies ist die neueste Version von Microsoft Visual SourceSafe"

Ich wäre auf Ihrer Seite und würde wirklich dagegen vorgehen.