Business Case für dezentrale Versionskontrollsysteme

26

Ich habe nach geschäftlichen Gründen gesucht und keine gefunden, warum Git / Mercurial / Bazzr-Systeme besser sind als zentralisierte Systeme (Subversion, Perforce).

Wenn Sie versuchen würden, ein DVCS an eine nicht technische Person zu verkaufen, welche Argumente würden Sie für die Steigerung des Gewinns des DVCS liefern .

In Kürze werde ich meinem Manager das Pitching von Git durchführen. Es wird einige Zeit dauern, Subversion-Repositorys zu konvertieren, und einige Kosten für den Kauf von Smartgit-Lizenzen.

Bearbeiten Ich habe versucht, diese Frage in eine allgemeine Diskussion über zentralisierte vs. dezentralisierte zu verwandeln, aber es hat sich unvermeidlich in Git vs. Subversion verwandelt. Sicher gibt es bessere zentrale Systeme als Subversion.

Keyo
quelle
1
Wir sind in einer ähnlichen Position, wenn es darum geht, den Fall zu klären, und ich bin nicht davon überzeugt, dass es derzeit einen gibt.
Jon Hopkins
Könnten Sie git-svnIhre Bedürfnisse erfüllen?
JBRWilkinson
@JBRWilkinson Ich habe gerade git-svn verwendet, um eine Reihe von Repositorys nach git zu migrieren. Das Unternehmen hat nicht viel in Tools investiert, die sich in svn integrieren lassen, daher war dies kein großes Problem.
Keyo
Ref the edit - Sie haben immer noch nicht erklärt, wie und warum SVN Sie so scheitert, dass Sie das Gefühl haben, einen Ersatz zu benötigen. Meine Antwort (zum Beispiel) bezieht sich NICHT auf Git vs Svn, sondern darauf, einen Business Case für die Änderung des Status Quo zu finden.
Murph

Antworten:

23

Hmm, als Manager habe ich zwei unmittelbare "Knie-Ruck" -Reaktionen darauf:

  • Wenn du noch keine guten Gründe hast, warum wirfst du einen anderen Trottel auf, als im Trend zu sein?
  • Wie schlägt Subversion fehl, sodass Sie einen Ersatz benötigen?

Eigentlich bin ich nicht negativ - ich denke, es muss wahrscheinlich ein Fall gemacht werden (abhängig von den Umständen), aber wenn der Fall einfach ist, dass git "besser" als subversion ist, dann haben Sie keinen.

Sie müssen auch in der Lage sein, die Nachteile aufzuzählen - Sie haben bereits den Mehraufwand für Migration und Nachbearbeitung festgestellt - was ist ein anderes Problem? zB Was passiert mit Ihrem netten, zentralen, gesicherten Repository? Wie integrieren Sie sich in Ihren Continuous Integration Build Server (wenn Sie keinen haben, vergessen Sie git und sortieren Sie diesen zuerst)? Sicherheit und Nachverfolgung - SVN wird mit den richtigen Anmeldungen und Berechtigungen ausgeführt.

Meiner Meinung nach liegen die Vorteile in der Flexibilität, der besseren Zusammenführung, der Fähigkeit, lokale Commits auszuführen, ohne den Build zu unterbrechen und so weiter. Die Nachteile sind mangelnde Kontrolle und die gleiche Flexibilität.

Möglicherweise möchten Sie nur git lokal auf Ihrem Computer als "besseren" Subversion-Client ausführen (ich möchte dies mit mercurial tun).

Hmm, vielleicht ist diese ganze Antwort wirklich ein Kommentar? Sie müssen Ihren Fall hier (in der Frage) für git over subversion (in Ihrer Umgebung) machen, um zu sehen, ob wir Ihnen helfen können, den Geschäftsfall zu identifizieren.


FWIW, ich weiß, dass man eine bestimmte Instanz des Repositorys leicht als Trunk- / Referenzquelle festlegen kann und dass man auf diese Weise den Build-Server einbindet - der Unterschied besteht darin, dass DVCS eher eine administrative Entscheidung ist als eine etwas in der Architektur inhärent.

Murph
quelle
1
Berücksichtigung der Rechte / Flexibilität: Sie benötigen weiterhin ein "Quell" -Repository, in dem Sie die Rechte wie gewohnt festlegen können. Continuous Integration wird für das Quell-Repository ausgeführt, Entwickler klonen das Quell-Repository usw. Die Sicherung ist jedoch weniger wichtig, da jeder einen Klon hat und nicht nur einen Checkout.
Matthieu M.
1
Der Hinweis, dass vollständige Klone Sicherungen sind, ist gut gemacht. Ich gebe frei zu, dass es einige Bereiche gibt, die ich nicht gut genug verstehe, da meine "Arbeit" svn ist und mein Quecksilber persönlich und bis jetzt etwas begrenzt.
Murph
14

Ich würde sagen, das schnelle und schmerzlose Verzweigen und Zusammenführen würde es Entwicklern ermöglichen, produktiver mit ihrem Code umzugehen, da jedes neue Feature verzweigt und später zusammengeführt werden könnte. Der Entwicklungsprozess verläuft viel reibungsloser. Aufgrund der verteilten Struktur verfügt jeder Entwickler über eine vollständige Kopie des Codes, sodass Sie nicht befürchten müssen, dass ein zentraler Serverausfall Ihren gesamten Code ausfällt. Es gibt wahrscheinlich noch mehr Gründe, aber diese beiden Gründe sind meine Hauptgründe für die Verwendung von Git.

mbreedlove
quelle
2
In einer Geschäftsumgebung würde der "zentralisierte Server" Redundanz, Backup und Administratoren haben, die dafür verantwortlich sind, dass er (und alle anderen Server) am Leben bleiben.
JBRWilkinson
2
In einer großen Geschäftsumgebung würden Sie Server-Redundanz haben. In einem kleinen Unternehmen ist eine solche Server-Redundanz nicht so sicher.
Michael Shaw
2
Ein zentraler Serverausfall würde Ihren gesamten Code nicht beeinträchtigen. Selbst wenn Sie keine Backups haben, ist das Schlimmste, was dies tun könnte, das Aufzeichnen Ihres Revisionsverlaufs. Solange jedoch alle Entwickler den Code ausgecheckt haben, ist er auch auf ihren Systemen in der aktuellen Form vorhanden.
Mason Wheeler
1
@mason: aber das ist schon eine Vermutung: "Solange alle Entwickler ...". Denn in kleinen Unternehmen mit noch kleineren Projekten können Projekte ein Jahr oder länger ohne Programmierkenntnisse weiterleben und genutzt werden Zwei
Inca
Außerdem würde ich den Wert der Commit-Geschichte nicht unterschätzen. In einem riesigen System kann es sehr wertvoll sein zu sehen, wer und warum etwas mit dem Code gemacht hat.
Tamás Szelei
8

Ich gehe davon aus, dass Sie sich für eine Versionskontrolle einsetzen können, um die Produktivität (und damit den Gewinn) zu steigern, selbst wenn ein Entwickler alleine arbeitet.

Ein guter DVCS erkennt die gleichen Produktivitätsvorteile, auch wenn er als Teil eines Teams arbeitet. Jeder Entwickler kann alle Vorteile der Versionskontrolle nutzen. Er kann häufig Commits ausführen, Rollbacks ausführen, mit Dingen herumspielen usw., ohne sich um Konflikte sorgen zu müssen mit dem, was andere Entwickler tun, bis sie bereit sind, ihre Änderungen zu veröffentlichen.

Anon.
quelle
Das ist es, was ich eigentlich posten wollte. Sie sollten auf jeden Fall Produktivitätsverbesserungen von Entwicklern sehen, die früh und häufig in ihr eigenes Repository einbinden, ohne dass ihre Mitarbeiter Probleme haben.
Carson63000
5
Dann bist du in der Integrationshölle, wenn du irgendwann deine Änderungen drückst. Das ist eine schlechte Sache, keine gute Sache.
Henry
Da Sie die lokale Entwicklung mit vielen Commits durchführen, können Sie weiterhin Änderungen aus dem zentralen Repository abrufen und Ihre lokalen Änderungen an die laufende Entwicklung anpassen, an der andere arbeiten. Wenn es darum geht, Ihre Änderungen in das zentrale Repository zu übertragen, sollten Sie bereits über die meisten Änderungen verfügen, die dort vorgenommen wurden, und die Integration wird einfach sein.
DaveJohnston
1
Es sei denn, einer Ihrer Mitarbeiter hat genau dasselbe getan und Sie haben sich beide schon eine ganze Weile nicht mehr integriert. Es gibt immer Kompromisse. Ich habe Fälle erlebt, in denen Dinge auf der Hauptleitung integriert wurden, bei denen dies nicht der Fall sein sollte (falsche Lösung, Sackgasse bei einem Lösungsversuch usw.). Das Integrieren mit vollständiger Funktionalität hat auch Vorteile.
Joppe
2
Können Sie all diese Dinge nicht mit (a) SVN-Zweigen oder (b) mehreren Arbeitskopien machen?
JBRWilkinson
4
  • Branch-per-Bug
  • Reduzierte Latenz auf Ihren Diffs.
  • In der Lage sein, beim Peer-Review sehr schnell und willkürlich durch den Verlauf einer Branche zu navigieren.
  • Sie haben immer noch Zugriff auf Ihren gesamten Verlauf, wenn Sie keinen Zugriff auf den zentralen Server haben: Sie sind nicht im Büro, der Strom ist gerade ausgefallen, aber der Akku Ihres Laptops funktioniert immer noch, ...

Mit diesen Dingen können Sie sowohl alleine als auch im Team effizienter arbeiten. Effizienteres Arbeiten = schnellere Entwicklungszeit = schnellere Time-to-Market = Gewinn.

Frank Shearar
quelle
3

Verzeihen Sie mir, dass ich auf meinen eigenen Blog verlinke, aber ich habe Artikel zu diesem Thema geschrieben:

Sie können gerne abstimmen, wenn Sie diese nicht für relevant halten.

Kurz gesagt, mit DVCS lassen sich Verzweigungsmodelle einfach erstellen, sodass große Entwicklergruppen nicht aufeinander treten können, was sowohl die Produktivität als auch Ihre tägliche Verarbeitungsqualität steigert. Der Teil der Versionskontrolle, bei dem die Zusammenarbeit problematisch ist, kann in lokalen Repos durchgeführt werden, wodurch Ihr zentrales Repository sauberer und von höherer Qualität bleibt. Entscheidungen darüber, wann eine Niederlassung eröffnet werden soll, können sich auch erheblich auf die Effizienz auswirken, wenn beispielsweise eine Abteilung bereit ist, mit der Arbeit an 2.0 zu beginnen, während 1.0 noch von anderen aufgeräumt wird. Das DVCS ermöglicht, dass diese Entscheidungen auf lokaler Ebene und nicht vom Ausschuss getroffen werden.

Karl Bielefeldt
quelle
Ihre Blog-Einträge sind gut geschrieben. Ich habe aber noch nicht alle gelesen. Ich frage mich, warum Sie sich für Bzr entschieden haben, wenn Git und Hg weitaus beliebter zu sein scheinen. Die Leute scheinen Bzr zu hassen, weil er langsam ist. Ich bin auch ein Fan von Git wegen der Baum-Hashes anstelle von Revisionsnummern, was mir sehr sicher erscheint. Werden die bzr-Revisionsnummern beim Zusammenführen von Zweigen nicht alle durcheinander gebracht?
Keyo
2
@Keyo, ich habe mich für bzr entschieden, weil ich mir selbst DVCS beibringen musste und bzr am besten für Neulinge geeignet ist. Ich bin seitdem aus Gründen der Geschwindigkeit, der Funktionen und der Stabilität auf Git umgestiegen. Bazaar hascht auch seine Revisionen und verfügt über global eindeutige Bezeichner. Sie sind nur nicht die Standardeinstellung, die dem Benutzer angezeigt wird. Ihre Revisionsnummern sind wirklich nicht anders als die Verwendung HEAD~1, HEAD~2etc. in git. Es ist sehr selten, dass Sie den eigentlichen Hash brauchen, aber es ist das erste, was Sie in git lernen und es ist immer in Ihrem Gesicht. Das zu verbergen, wenn man es nicht wirklich braucht, ist ein Grund dafür, dass bzr einsteigerfreundlicher ist.
Karl Bielefeldt
Danke für die Klarstellung. Git war nicht gerade einfach für mich, weil ich von Subversion gekommen bin. Viele Befehle haben dasselbe Wort, aber unterschiedliche Funktionen.
Keyo
2

Meine Argumente für DVCS sind diese:

  • Die Verzweigung ist nicht unterbrochen, was zu einer geringeren Reibung bei der Entwicklung von Funktionen und der Beibehaltung vorhandener Produkte führt. Reibung kostet Geld in der Zeit.

  • Die Umstellung auf ein modernes System zieht die neuesten Entwickler an, was zu einer Kultur besserer Produkte führt, die es dem Unternehmen ermöglicht, mehr Produkte zu verkaufen.

  • Nicht-Netzwerk-Commits sind schneller , sodass die Entwickler häufig Commits durchführen können, was zu einer detaillierten Fehlererkennung und -analyse führt.

Im Wesentlichen geht es darum, Reibung zu reduzieren. Dafür gibt es einen Begriff: Muda . Je mehr Reibung, desto schmerzhafter ist es, Dinge zu tun. Je mehr Schmerz, desto weniger wird getan, desto weniger Gewinn.

Paul Nathan
quelle
2

Ich entschuldige mich, wenn ich großartig bin, aber erlaube mir, den Business Case in eindeutigen Worten zu formulieren:

SVN macht das Leben der Entwickler miserabel . Und das macht ein Software-Geschäft miserabel.

... auf eine Weise, die viele erst erkennen, wenn sie anfangen, ein DVCS zu verwenden. Dies ist der wichtigste Geschäftsfall, der möglicherweise erstellt werden kann . Warum? Im Vergleich zu den Kosten für die Suche und Bindung guter Entwickler sind die Kosten für den Umstieg auf ein DVCS so gut wie nicht vorhanden .

Folgendes berücksichtigen:

  • Alle bis auf die einfachsten Vorgänge in SVN (und den meisten anderen CVCS) erfordern Netzwerkzugriff. In den meisten DVCS tritt der Netzwerkzugriff nur auf, wenn Sie eine pushoder -Operation pullausführen. Dies bedeutet, dass nicht triviale Befehle langsam sind . Was machst du, wenn ein Befehl ewig dauert? Ich persönlich gehe programmers.se oder Hacker-Nachrichten durchsuchen, während ich warte. Mit DVCS können sich Programmierer darauf konzentrieren, das zu tun, was sie lieben: die Software des Unternehmens zu schreiben .
  • SVN unterstützt das Verzweigen auf die gleiche Weise, wie Gefängnisse es unterstützen, Ihre Seife in die Dusche zu werfen: Sie können es tun, aber wenn Sie es tun, werden Sie gefickt. Daher zwingt SVN Ihre Entwickler, sich ständig gegenseitig zu streiten, um Änderungen vorzunehmen .
  • Wenn SVN nicht verfügbar ist, ist es nicht verfügbar. Es wird für Entwickler furchtbar schwierig, ihre Arbeit zu erledigen, wenn sie sie überhaupt können. Daher zwingt SVN Ihre Entwickler, sich darauf zu verlassen, dass Ihre Infrastruktur zu 100% fehlerfrei ist .
  • Heutzutage gewinnt Git rapide an Mindshare, während SVN es rapide verliert. Wenn die Verwendung von DVCS keine Vorteile gegenüber SVN bietet, warum ändert sich die Programmiergemeinschaft so schnell wie möglich?

Was bedeutet das alles? Ich habe noch keinen Entwickler getroffen, der einem DVCS einen ehrlichen Versuch gegeben hat, der danach SVN vorziehen würde. Wenn ich noch eine nervige, kühne Aussage machen könnte, ist SVN ein "notwendiges Übel", zu dessen Verwendung sich Entwickler zwingen. Git ist ein Tool, das Entwickler produktiver und glücklicher macht .

(Ich möchte darauf hinweisen, dass die fettgedruckten Aussagen diejenigen sind, auf die Sie sich konzentrieren sollten. Der Rest von ihnen liefert nur den Kontext.)

Jason Baker
quelle
5
-1 - Sie sind großartig und obwohl das, was Sie schreiben, etwas Wahres ist, wird es so negativ gesponnen, dass es eher an FUD als an begründete Analysen grenzt. Ist SVN langsam? Nur wenn das Repository riesig und das Netzwerk glazial ist. Wenn SVN nicht funktioniert, kann ich mich nicht erinnern, dass es jemals nicht funktioniert, und NEIN, da mein Computer nicht vom Repository abhängig ist, um die Quelle zu bearbeiten, zu kompilieren oder auszuführen. Verzweigt und verschmilzt SVN schlecht? Wow, die Leute haben kurze Erinnerungen ... warum gewinnt DVCS an Mindshare? Eine Mischung aus Funktionalität - die verbessert wird - und ehrlich gesagt Mode.
Murph
1
@Murph - Ob es dir gefällt oder nicht, die Leute hassen es, sich zu verändern, bis sie töricht sind. Um sie davon zu überzeugen, sich zu ändern, müssen Sie sie davon überzeugen, dass der Status Quo gebrochen ist. Und es ist kaputt. FUD ist nur schlecht, wenn es keinen Grund gibt, ängstlich, unsicher und zweifelhaft zu sein. Was mindshare angeht, stimme ich Ihnen zu. Aber darum geht es nicht wirklich. Es ist die Frage, ob die Leute, die Entscheidungen treffen, damit einverstanden sind oder nicht. Und jeder Manager, den ich jemals getroffen habe, war von diesem Argument überzeugt (auch wenn er Schwachsinn hasst ).
Jason Baker
2
Ich bin nicht unbedingt anderer Meinung als Sie, Jason meint nur, dass Ihre Argumente nicht gut gemacht sind. Insbesondere denke ich, Sie übertreiben auf Wirkung, und wenn Sie dabei erwischt werden, neigen Sie dazu, Punkte für Ihre Argumentation zu verlieren, selbst wenn Sie Recht haben. (Mit Ausnahme der Punkte, an denen Sie natürlich falsch liegen ... (-
Murph
2
Alle Ihre Punkte sind eher Ansichtssachen als Fakten. Ich würde jedes aufzählen, aber in Kommentaren ist nicht genug Platz. Wie wäre es, wenn Sie ohne die Tribüne noch einmal antworten?
Henry
1
@Henry - Programmers.se steht für subjektive Fragen und Antworten. Subjektive Ansichtssache.
Jason Baker
1

Das einzige, was ich mir vorstellen kann, ist, dass Git ohne Netzwerkverbindung funktioniert. Alles andere ist sogar oft schwer an technische Benutzer zu verkaufen, die seit geraumer Zeit Subversion oder Perforce einsetzen.

Brainlag
quelle
2
Klar, aber Subversion funktioniert meist auch ohne Netzwerkverbindung. (Nicht offensichtlich, aber allgemeine Dinge wie das Abrufen von Informationen über die Arbeitskopie oder die Abweichung von der Basisrevision funktionieren.)
j_random_hacker
@j_random_hacker: Der Zweck eines VCS besteht darin, Codeänderungen zu verfolgen. Das Festschreiben verfolgt Codeänderungen. Wenn Sie kein Offline-Commit durchführen können, würde ich argumentieren, dass Ihr VCS im Offlinemodus nicht funktioniert.
Daenyth
1

Der Unterschied zeigt, wenn es Ärger gibt

Wir sind vor 6 Monaten auf git umgestiegen, nachdem wir unser zehn Jahre altes Repository portiert hatten.

Bisher habe ich nach einigem Experimentieren folgendes herausgefunden:

  • Verzweigen und Zusammenführen ist nahezu schmerzfrei. Dies macht es viel einfacher, an separaten Funktionen und Bugfixes zu arbeiten, ohne sich gegenseitig auf die Zehen zu treten. Es macht es auch sehr einfach, einen bestimmten Bugfix auch an einer anderen Stelle anzuwenden.

  • Robuster durch Design - Sie verlassen sich nicht zu 100% darauf, dass ein zentraler Server verfügbar ist. Wenn dies nicht der Fall ist, können Sie einen beliebigen Klon vorübergehend als Ersatz für einen Hotspot verwenden. Dies beseitigt einen entscheidenden Fehlerpunkt - wenn der SVN-Server aus irgendeinem Grund ausfällt, kann niemand SVN-Arbeit leisten. Wenn das zentrale Git-Repository aus irgendeinem Grund ausfällt, können Sie weiterhin lokal arbeiten und Push / Pull ausführen, um sicherzustellen, dass die Commits repliziert werden. Sie können sogar mehrere externe Repositorys für genau diesen Zweck einrichten.

  • Repository-Interaktion wird vereinfacht. Für CVS brauchten Sie im Wesentlichen immer Zugriff, wenn Sie Informationen benötigten. Für Git ist das gesamte Repository lokal verfügbar, sodass viele Dinge schneller erledigt werden können.

Der Nutzen ist also nicht so groß im Alltag, sondern sehr deutlich, wenn etwas nicht richtig funktioniert!

Daher schlage ich vor, dass Sie sich für Ihren Geschäftsfall ansehen, was Sie tun werden, wenn eine Katastrophe eintritt ...


quelle
Es ist das gleiche Argument wie für Backups: Sie brauchen sie nur, wenn ein Notfall eintritt. Die Frage ist, was Sie tun werden, wenn dies der Fall ist, und was Sie dann akzeptieren werden.
0

Das einfache Verzweigen und Zusammenführen ist der konkreteste Grund, aber um jemanden zu überzeugen, müssen Sie ihm ein konkretes Beispiel geben, wie dies die Dinge verbessert.

Nehmen wir an, Sie haben einige Programmierer, die an Leistungsverbesserungen für eine App arbeiten. Sie befinden sich im Versuchsstadium und wissen nicht, ob der von ihnen geschriebene Code jemals Teil des Master- / Trunk-Zweigs sein wird. Sie müssen jedoch häufig Code untereinander austauschen und Ideen ausprobieren, die möglicherweise Sackgassen sind. Wie schaffen Sie es, so häufig in Subversion zu verzweigen und zusammenzuführen? Die kurze Antwort lautet, dass Sie dies nicht tun. Mit einem dvcs ist es wirklich einfach, und die Programmierer können schnell neue Ideen in Branchen ausprobieren und mit anderen austauschen, bevor sie entscheiden, ob diese Idee bestehen bleibt.

jshen
quelle
-1

Das Geschäftsmodell für SubVersion ist, dass die Verzweigungsunterstützung ein Hindernis für die Produktstabilisierung und -wartung darstellt. Wenn Sie ein Produkt freigeben und dann die Entwicklung fortsetzen müssen, benötigen Sie eine Filiale. Mit Subversion werden die Entwickler die Verzweigung nicht richtig verwenden, sodass Sie die Entwicklung auf dem Tunk nicht aufrechterhalten und sicherstellen können, dass die Fehlerbehebungen tatsächlich sowohl auf dem Stamm als auch auf dem Zweig landen.

Michael Shaw
quelle