Quantifizierung der Vorteile eines modernen Versionskontrollsystems

Ich habe fast drei Jahre als Teamleiter / Entwickler in einem großen Finanzunternehmen gearbeitet. Unser Produktionsfreigabeprozess ist ein Albtraum, da er sich um Clearcase dreht. Wir haben eine Änderungsverwaltungsgruppe, die alle Releases ausführt und nur Code für die Produktion zulässt, der daraus entnommen wurde.

Als erstes habe ich mein Team mit Git zusammengestellt. Alle waren sich einig, dass Clearcase schrecklich und unpraktisch für die alltäglichen Probleme der Quellcodeverwaltung war. Also haben wir eine Art "inoffizielles" Repository auf meinem lokalen Rechner eingerichtet und ich habe ein Skript geschrieben, um unsere git- und Clearcase-Repos zur Veröffentlichungszeit zu synchronisieren.

Das hat sich auch bei anderen Teams herumgesprochen, und mehrere haben den gleichen Prozess übernommen. Git "inoffiziell" für alltägliche Aktivitäten und "offiziell" mit Clearcase für Veröffentlichungen verwenden. Ich bin zu einer Art Ansprechpartner für alle Probleme mit Git geworden.

Also habe ich diese Woche ein Treffen mit der SVP im Bereich des Infrastrukturwechsels, die ausdrücklich möchte, dass ich ihr die Vorzüge von Git erkläre. Anscheinend erfuhr sie von meinen häufigen Beschimpfungen auf Clearcase. Wenn sie meine Argumente akzeptiert, kann ich meinem Arbeitgeber helfen, sich von diesem Gräuel zu befreien.

Meine Erfahrung mit Führungskräften zeigt mir, dass sie a) extrem knappe Erklärungen für alles wollen, b) nur an Fakten interessiert sind, die Dollarzahlen beinhalten

Ich kann einem Entwickler die Vorzüge von Git gegenüber Clearcase (oder JEDEM anderen Versionskontrollsystem gegenüber Clearcase) erläutern, aber ich zeige einem technischen Manager ohne technischen Hintergrund, wie dies zu tun ist (sie hat eine MBA und machte ihren Bachelor in Geographie.

Ich habe das Gefühl, dass jedes Argument, das ich ihr vorbringe, entweder nach technischem Kauderwelsch klingt oder dass ich meine persönlichen Vorlieben evangelisiere.

Was ich versuche zu finden, sind konkrete Fakten, die zeigen, dass Entwickler effektiver mit Git oder JEDEM modernen Versionsverwaltungssystem arbeiten.

Ich denke, dass die Tatsache, dass die anderen Teams damit begonnen haben, Git intern zu verwenden, ein aussagekräftiges Zeichen ist, aber es ist immer noch nicht stark genug, da es immer noch als persönliche Präferenz abgetan werden kann.

Was ich wirklich brauche, ist etwas, das stark genug ist, um den "Dieser Prozess funktioniert seit 20 Jahren, warum sollten wir ihn ändern?" Streit.

Ich war in sehr ähnlichen Situationen (in der Luftfahrt- und Automobilindustrie). Erwarten Sie nicht, dass Sie in diesem oder den folgenden Meetings weiterkommen. Beide Situationen haben meinen Wunsch übertroffen, weiter für Verbesserungen zu kämpfen, aber hier ist die beste Taktik, die ich bisher gesehen habe ...

Sie sagen, "dieser Prozess hat seit 20 Jahren funktioniert", aber hat es das wirklich getan? Beschreiben Sie zunächst, was Sie unter "Unser Produktionsfreigabeprozess ist ein Albtraum" verstehen. Erstellen Sie eine Liste der Probleme mit dem aktuellen Prozess / Tool, die ClearCase so wenig wie möglich ausgesetzt sind.

Erstellen Sie dann eine Liste von Prozess- / Tool- "Lösungen", die so unabhängig wie möglich von Git sind. Zu erklären, warum Git besser ist als ClearCase, bedeutet für Nichtbenutzer nichts.

Lassen Sie das Infrastruktur-Team bestätigen, dass der aktuelle Ansatz die von Ihnen identifizierten Probleme aufweist. Dies wird sie wahrscheinlich veranlassen, Unterstützung von IBM zu suchen, um diese Probleme zu "beheben". Bleiben Sie verbunden, um sicherzustellen, dass IBM die Probleme nicht außer Acht lässt. Da ClearCase nicht über die grundlegenden Eigenschaften unseres modernen Verständnisses der Versionskontrolle verfügt, können die meisten dieser Probleme nicht behoben werden oder erfordern eine grundlegende Änderung der Infrastruktur.

Hoffentlich wird das Infrastruktur-Team dies zu diesem Zeitpunkt als ein Geschäftsproblem betrachten, das jedoch keine einfache Lösung bietet. An dieser Stelle bieten Sie an, zusätzliche Lösungen mit geschätzten Kosten zu vergleichen. Da viele Ihrer Teams bereits Git verwenden, sollten Sie in der Lage sein, Schulungen als Aufwand zu entfernen.

Viel Glück!

Unser Produktionsfreigabeprozess ist ein Albtraum, da er sich um Clearcase dreht. Wir haben eine Änderungsverwaltungsgruppe, die alle Releases ausführt und nur Code für die Produktion zulässt, der daraus entnommen wurde.

Nein, Ihr Prozess ist aufgrund Ihrer Änderungsverwaltungsgruppe und Ihrer Freigabeverfahren ein "Albtraum". Ersetzen Sie Clearcase durch SVN, git oder Fossil. Sie werden genau die gleichen Probleme haben . (Ich denke, sie machen es richtig, TBH, starke Release-Kontrollen sind unerlässlich).

Dies ist es, worauf Sie sich konzentrieren müssen, nicht auf die geekigen Anmeldeinformationen von git (die für alle außer den Entwicklern irrelevant sind), sondern auf den Business Case, um den Prozess so zu ändern, dass er weniger lästig wird. Möglicherweise können Sie dies mit Clearcase tun, aber es gibt Ihnen die Möglichkeit, die Idee der Verwendung von Git in jedem Fall zu schleichen.

Wenn Sie sich hier nicht das "größere Bild" ansehen, erhalten Sie es am besten, um git mit den gleichen Einschränkungen zu verwenden, die die Release-Gruppe erfordert. Wenn Sie die umfassenderen Aspekte der Änderungskontrolle berücksichtigen, werden Sie die Einschränkungen zu schätzen wissen, die Sie implementieren müssen, um git für den stark kontrollierten Freigabeprozess Ihrer Organisation nützlich zu machen.

Einige Ideen für Sie: Lassen Sie sie die Produktivitätsprobleme mit dem aktuellen System aus Entwicklersicht sehen. Tun Sie dies als Teil 1 von 2. Teil 2, arbeiten Sie mit ihnen an einem Release, damit Sie die Steuerungsprobleme sehen, die Entwickler verstehen müssen. Betrachten Sie es als eine Lernübung für beide Seiten, um die Sicht der anderen Seite zu betrachten, und dann sollten Sie besser in der Lage sein, eine Lösung zu finden, die die wichtigsten Anforderungen beider Seiten noch löst. Beachten Sie, dass Releases wichtiger sind als dev. Sie sollten also bereit sein, mehr zu tun, als Sie erwarten.

Sobald Sie wissen, was für Releases erforderlich ist, sollten Sie sich bereit erklären, ein detailliertes Prozessdokument (mit folgenden Schritten) zu verfassen, in dem Sie ihnen zeigen können, was sie benötigen. Wie Sie dies massieren können, damit die Entwicklerseite besser für Sie ist, liegt bei Ihnen. Ich stelle mir vor, dass es ihnen egal ist, wie dev dev funktioniert, solange die Quelle ordnungsgemäß verwaltet und die Veröffentlichungen ordnungsgemäß organisiert sind. Das bedeutet, dass Sie zeigen müssen, wie Codeänderungen mit Ticketänderungen verknüpft werden können und wie der erstellte Code übernommen wird eine Version zum Patchen, Erstellen und erneuten Veröffentlichen.

Spezifische Beispiele werden mehr als abstrakte Vorteile beeindrucken. Ich denke, Sie werden den größten Erfolg erzielen, wenn Sie bestimmte Beispiele dokumentieren können, bei denen (a) Clearcase Probleme verursachte, deren Lösung einige Zeit in Anspruch nahm, und (b) Git diese Probleme löst. Denken Sie daran, dass Sie nicht auf technische Details eingehen müssen, um zu zeigen, warum dies so ist (es sei denn, Sie werden gefragt), dass dies der Fall ist. Das Management muss die technischen Details nicht kennen, dafür werden Sie bezahlt.

Wenn Sie diesen Beispielen bestimmte Zeitskalen und Daten hinzufügen können, umso besser. Möglicherweise können Sie das Ganze auch abrunden, indem Sie zeigen, dass Task X, den Sie häufig ausführen, in Clearcase Y Minuten und in Git Z Minuten dauert.

Denken Sie daran, dass Zeit Geld ist. Wenn Sie also zeigen können, dass die Arbeit mit Git schneller ist , können Sie zeigen, dass dies auch finanziell sinnvoll ist.

Hier ist ein Versuch, wie ich das versuchen würde.

Das mag für einen Entwickler dumm klingen, aber für das Management werden technologische Veränderungen als riskant angesehen.

"Wenn das magische Ding bereits funktioniert, warum das Risiko eingehen, es zu zerbrechen?"

Sie müssen also den Spieß umdrehen. Machen Sie es riskanter, nicht auf Git umzusteigen. Lass es nicht so klingen, als wäre es ein neues Spielzeug.

Ich würde damit anfangen zu sagen, dass Git mittlerweile weit verbreitet ist. Verwenden Sie Zahlen wie die folgenden: http://ianskerrett.wordpress.com/2014/06/23/eclipse-community-survey-2014-results/

Für einen Manager bedeutet dies, dass er in der Lage sein sollte, mit git viele Entwickler zu finden. Und ein ganzes Ökosystem mit Tools von Drittanbietern (ich hörte sogar, dass Microsoft Git jetzt in Visual Studio integriert).

Auch ein Manager kann nicht wirklich dafür verantwortlich gemacht werden, den Mainstream-Dingen zu folgen, oder? Wer hingegen benutzt hier $ other_cvs?

Legen Sie Wert darauf, wie viele Projekte es nutzen, weil es einfach, schnell, flexibel und leistungsstark ist ... Finden Sie große Projekte mit großen Namen (GNU / Linux, Google, Microsoft ...), die Git verwenden.

Nachdem Sie bewiesen haben, dass es kein schlechter Schachzug sein kann, können Sie weiter machen, wie sich die Situation in Ihrem Fall verbessern lässt.

Sie möchten, dass das Unternehmen wettbewerbsfähig bleibt und nicht von schnelleren, agileren Teams überholt wird, oder? Ich würde versuchen, einige interne (schriftliche) Schätzungen zu finden, wie sich die Produktivität mit Clearcase vs Git geändert hat. Sie könnten Hilfe von Ihren Mitentwicklern dort gebrauchen. Extrapolieren Sie dann für das gesamte Unternehmen (dh für alle Softwareentwickler) die Zahlen und die geschätzten Kosten für den Aufenthalt bei Clearcase.

Ich würde sogar, wenn angebracht, das Ganze in einer schriftlichen E-Mail nach dem Treffen zusammenfassen (die richtigen Personen mit einbeziehen).

Was ich wirklich brauche, ist etwas, das stark genug ist, um den "Dieser Prozess funktioniert seit 20 Jahren, warum sollten wir ihn ändern?" Streit.

Dies ist ein ungültiges Argument (Pferdekutschen haben "jahrhundertelang gearbeitet", aber Sie möchten wahrscheinlich stattdessen ein Auto kaufen).

Ich habe dasselbe Argument über svn vs. mercurial gehört (ich habe mercurial auf meinem Entwicklungssystem verwendet).

Bei diesem Problem geht es nicht darum, das zu ersetzen, was funktioniert. Versuchen Sie nicht, es als solches zu formulieren, und wenn dies die Frage ist, die Sie "besiegen" müssen, sollten Sie zunächst darauf hinweisen, dass es nicht darum geht, was funktioniert oder nicht - sondern darum, welche Vorteile Sie mit git haben , wenn beide funktionieren (und warum funktioniert git besser).

Gute Argumente für die Verwendung von Git:

• Git ist ChangeSet-zentriert anstelle von File-zentriert. Dies bedeutet, dass Änderungen leichter über Dateien hinweg verfolgt werden können (Verfolgbarkeit über das Projekt hinweg).

• Git wird verteilt anstatt zentralisiert; Dies bedeutet, dass das Einchecken von Inhalten nicht durch die Netzwerkgeschwindigkeit beschränkt ist, sondern erneut viel Zeit spart. Dies bedeutet auch, dass Sie keine einzige Fehlerquelle haben, falls Ihr ClearCase-Server ausfällt.

• Aufgrund des Verzweigungssystems minimiert git die Notwendigkeit des Zusammenführens (dh Sie führen die Dateien nicht bei jedem Einchecken, sondern bei jedem abgeschlossenen Feature zusammen). Sie wechseln von der Lösung von Zusammenführungskonflikten (falls vorhanden) einige Male pro Tag (bei jedem Commit) zu ein- oder zweimal pro Woche (bei jedem abgeschlossenen Feature). Dies bedeutet mehr Entwicklungszeit für Ihre Entwickler (etwas, das Manager maximieren möchten).

Ich denke, dass die Tatsache, dass die anderen Teams damit begonnen haben, Git intern zu verwenden, ein aussagekräftiges Zeichen ist, aber es ist immer noch nicht stark genug, da es immer noch als persönliche Präferenz abgetan werden kann.

Sie können darauf hinweisen, dass der qualitative Unterschied so groß ist , dass Entwickler in Ihrem Unternehmen die Komplikationen der Installation, Konfiguration und Verwendung von git zusätzlich zu Clearcase aufgrund der zusätzlichen Funktionen bevorzugen. Tatsächlich ist es ein starkes Argument (wenn es nicht zu einer insgesamt besseren Benutzererfahrung und einem besseren Funktionsumfang führen würde, würden die Leute nicht die Mühe machen, es zu verwenden - zumal es etwas ist, das das Unternehmen nicht benötigt).

Also habe ich diese Woche ein Treffen mit der SVP im Bereich des Infrastrukturwechsels, die ausdrücklich möchte, dass ich ihr die Vorzüge von Git erkläre.

Zeichnen Sie ein Diagramm, das die Commits mit den beiden Systemen darstellt, und zeigen Sie die Optimierungen, die von Entwicklern erzielt wurden, die keine öffentlichen Commits durchgeführt haben (dh, wenn Sie eine Datei borken, wird der Rest des Teams nicht blockiert und kann erst ausgeführt werden, wenn Sie sie korrigieren). Erklären Sie auch die zusätzlichen Qualitätskontrollen Sie können, wenn Sie Vermittler verpflichtet , ohne dass jemand zu beeinflussen anderes machen kann, ist die Tatsache , dass Sie sauber diffs bekommen pro Funktion (wichtig für Code - Reviews).

Was ich wirklich brauche, ist etwas, das stark genug ist, um den "Dieser Prozess funktioniert seit 20 Jahren, warum sollten wir ihn ändern?" Streit.

Es ist schwer zu beurteilen, was ein gutes Argument wäre, ohne Zeuge der Szene zu sein. Aber ich werde versuchen, Ihnen dabei zu helfen, Ihre Argumente so zu formulieren, dass sie gehört werden können.

Ich gehe davon aus, dass Ihr Publikum kein Experte in diesem Thema ist und ein Interesse daran hat, den aktuellen Kurs beizubehalten. Sie haben unterschiedliche Anliegen und Verantwortlichkeiten und können schwerwiegende Konsequenzen haben, wenn etwas schief geht. Sie müssen also mit dieser Einstellung arbeiten. Erwarten Sie einige der Fragen oder Sorgen, die sie haben könnten:

• Welche neuen Fähigkeiten würde dies bringen? Gibt es etwas, das wir derzeit nicht können, das wir gerne tun würden und das uns dieses neue Ding erlauben würde? Beginnen Sie mit einer positiven Note.

• Was sind die Auswirkungen auf die Veröffentlichungszeitpläne? Was kostet die Implementierung dieser Änderung in Richtung der sofortigen nächsten Version? Welche Kosten und Vorteile ergeben sich aus folgenden Releases?

• Führt dies zu einer Änderung des Prozesses? Wird diese Änderung im Unterschied zum Veröffentlichungszeitplan erfordern, dass die Personen im Veröffentlichungsprozess ihre Verhaltensweisen ändern? Wird dies für sie transparent sein oder müssen sie sich anpassen? Müssen Sie mit anderen Abteilungen zusammenarbeiten? Die Menschen sind resistent gegen Veränderungen.

• Besteht die unmittelbare Gefahr, am aktuellen System festzuhalten? Hat der aktuelle Prozess Software- oder Hardwareabhängigkeiten, die verschwunden sind oder bald enden werden? Verlässt es sich auf Fachwissen von Einzelpersonen, das die Einstellungskosten in die Höhe treibt? Hat das neue System eine potenzielle Sicherheitslücke (Bonuspunkte, wenn diese Lücke zu rechtlichen Schritten führen kann)? Winken Sie nicht mit der Hand oder „vielleicht“ oder „wahrscheinlich“: Der Sinn ist, dass es 20 Jahre lang gut funktioniert hat. Die Beweislast liegt also beim Befürworter des Wandels.

Seien Sie auch genau über Probleme und Lösungen . Wenn Sie keine konkreten Beispiele finden, verwenden Sie ehrliche Schätzungen aus Ihrer Position als Experte. Beispiele für andere Unternehmen / Abteilungen / Organisationen, die eine solche Änderung, vorzugsweise aus Ihrer Branche, übernehmen, und deren Bewertung dieser Änderung helfen Ihnen dabei. (Wählen Sie keine Beispiele aus, bei denen in den letzten Jahren ein IT-Problem bekannt geworden ist. Andernfalls müssen Sie nachweisen, dass diese Änderung nicht die Ursache war.)

Sie finden diese Antwort möglicherweise, um das Unternehmen, für das ich arbeite, von der Implementierung der Versionskontrolle zu überzeugen? hilfreich.