Warum sollten große Finanz- / Versicherungsunternehmen Git und / oder Github verwenden?

Ich arbeite für ein großes Unternehmen (30.000 Mitarbeiter) in der Finanz- / Versicherungsbranche. Während "IT" nicht unser Hauptaugenmerk ist, lassen Sie uns ehrlich sein, dies sind informationsgetriebene Branchen und die Unternehmen mit dem besseren technologischen Vorteil scheinen schneller voranzukommen.

In meiner Firma gibt es viele Softwareentwicklungsteams. Sie sind überall auf der Karte mit Versionskontrolle, geschweige denn verwendeten Sprachen / Frameworks. Einige verwenden keine (ich weiß), einige verwenden PVCS, einige verwenden VSS und die am meisten aufgeklärten verwenden SVN.

Ich möchte GIT in mein Unternehmen bringen. Genauer gesagt möchte ich GitHub (private Repositories) mitbringen. Ich kenne die richtigen Leute, mit denen ich darüber sprechen kann, aber seien wir ehrlich, drastische Maßnahmen wie diese werden in der Regel in großen Unternehmen aufgrund vager Sicherheitsbedenken oder der Tatsache, dass keiner unserer Konkurrenten sie einsetzt, abgeschossen (und ich kann das) nur jQuery, Ruby on Rails, Facebook usw. als Referenzen angeben).

Meine Frage lautet also: Was sind die überzeugendsten Gründe, warum ein großes Unternehmen langsam und bewusst von PVCS / VSS / SVN auf eine gehostete Git-Lösung wie GitHub (Private Repo) umsteigen sollte? Natürlich beinhaltet ein Teil meines Plans einen POC für ein nicht notwendiges Entwicklungsprojekt.

Es gibt ein paar Dinge, die mich als uninteressierten Dritten interessieren könnten. Lassen Sie mich daher einige Fragen an Sie werfen, auf die Sie (an Ihre IT-Abteilung) besser vorbereitet sind:

• Jede Versionskontrolle ist besser als keine. Wir haben eine große Auswahl, was ist daran falsch?
• Verteilte Versionskontrolle? Was ist das? Wie kontrollieren wir das?
• Was kostet es? Nicht nur die Software, sondern auch die Server, Lizenzen, Wartung usw.
• Ich vertraue weder GitHub noch ausgelagertem Hosting. Wir müssen alles im Haus machen. Warum können wir keinen eigenen Server einrichten?
• Können wir es unter Windows ausführen? Wir müssen es auf unserer aktuellen Grundlinie halten, wissen Sie.
• Wie sichern wir das Ding? SVN bekommen wir, aber das macht mir Angst.

Dies sind die allerersten Fragen, die auftauchen werden. In Bezug auf VSS und PVCS können Sie wahrscheinlich eine Reihe von einigermaßen guten Argumenten finden (z. B. VSS, das den Versionsverlauf beschädigt). SVN wird etwas schwieriger. Ich empfehle nachdrücklich, sich auf die Zusammenführungsfunktionen von GIT zu konzentrieren und Mercurial gegenüber aufgeschlossen zu bleiben. Jedes Argument für GIT ist auch ein Argument für Mercurial - und Mercurial bietet ausgereifteren Windows-Support.

Sicherheit ist für Finanz- und Regierungsinstitutionen von größter Bedeutung. Sie sind äußerst widerstandsfähig gegenüber extern gehosteten Ressourcen. Betrachten Sie aus Risikomanagementsicht, was passieren könnte, wenn jemand GitHub hackt und den Quellcode stiehlt oder die im Issue Tracker dokumentierte Sicherheitslücke entdeckt. Das wäre für das Unternehmen verheerend. Aus reiner Managementperspektive, wenn das Unternehmen legal istWie können sie überwachen, ob Sie von zu Hause aus arbeiten, wenn sich die Ressourcen außerhalb ihres VPN-Netzwerks befinden? Wie können sie Sie daran hindern, eine Unternehmensspionage durchzuführen, wenn alle Ressourcen von außerhalb des Unternehmens verfügbar sind? Dies sind die IT- und Managementargumente gegen das Auslagern des Hostings. Ein großes Unternehmen muss die Dinge so sehen. Für ein kleines Unternehmen sehen Sie sich das Endergebnis an und wie viel es kosten würde, alle diese Dienste einzurichten.

Es ist tatsächlich billiger für die große Firma, es im Haus zu tun. Sie haben bereits die IT-Ressourcen, sie müssen lediglich die Zuständigkeiten ein wenig verschieben. Und wenn sich die Lösung größtenteils von selbst erledigt und nur regelmäßig gewartet werden muss (Backups und Benutzerverwaltung), ist dies ein Grund mehr, sie in Unternehmenstüren aufzubewahren.

Beim Windows-Hosting handelt es sich um ein organisationsspezifisches Problem. Mehrere Firmen haben den Windows-Koolaid verschluckt. Andere haben den Linux-Koolaid verschluckt. Andere prüfen dies von Fall zu Fall. Sie müssen sich an die Regeln halten, die die IT-Abteilung für Ihr Unternehmen festgelegt hat. Solange Ihre Lösung auf einem der beiden gehostet werden kann, sind Sie goldrichtig.

Schließlich gibt es in einer so großen Organisation garantiert Lehen, die alles auf ihre Art tun wollen. Sie alle haben überzeugende Argumente, warum sie sich für VSS, PVCS, SVN oder was für Sie entschieden haben. Für die IT sind sie alle gleich. Die einzige Möglichkeit, sich innerhalb einer so großen Organisation zu konsolidieren, besteht darin, dass die Bestellung von oben kommt. Solche Aufträge stoßen immer auf Widerstand, und es ist wahrscheinlich nichts, was Ihr Unternehmen tun möchte, es sei denn, ein standardisiertes Versionskontrollsystem bietet offensichtliche Vorteile hinsichtlich der Gesamtbetriebskosten (TCO).

Ich arbeite auch bei einem Finanz- / Versicherungsunternehmen (wenn auch nicht so groß wie das, für das Sie gerade arbeiten). Wir haben auch mehrere Entwicklungsteams, und obwohl das Unternehmen speziell Microsoft-Produkte für die Entwicklung ausgewählt hat, gibt es noch keine Master-Architektur, -Sprache oder -Versionskontrolle. Wir verwenden alle .NET, haben jedoch mehrere Projekte in verschiedenen Versionen des Frameworks und in verschiedenen Sprachen. Einige Projekte verwenden VSS, andere TFS. Wir haben jetzt einen neuen übergeordneten Architekten als QA-Manager und er hat einen unternehmerischeren Übergang von Hodge-Podge-Bug-Tracking, Quellcodeverwaltung und Framework-Nutzung zu einer universelleren Implementierung von TFS für alles vorangetrieben. Dies wird nur dadurch ermöglicht, dass er a) in der Natur der Software äußerst erfahren ist,

Wenn Sie dies in Ihrer eigenen Organisation angehen, müssen Sie zuerst einige Dinge berücksichtigen:

1. Warum bist du so verliebt in GitHub als Antwort? Suchen Sie nach einer gemeinsamen Quellcodeverwaltung oder suchen Sie nach einem Grund, etwas zu implementieren, mit dem Sie zufrieden sind? Ich kenne die Antwort nicht (und es ist mir ehrlich gesagt auch egal), aber das ist eine Frage, die auftaucht, wenn Sie anfangen, im Geschäft anderer Leute herumzuschnüffeln.
2. Sind Sie derzeit Mitglied in einem dieser Softwareteams? Wenn ja, müssen Sie möglicherweise eine nicht verbundene, gut positionierte Person finden, um das Konzept zu unterstützen. Anderenfalls haben andere Entwicklungsteams möglicherweise nur das Gefühl, dass Sie versuchen, Ihre Überlegungen auf sie zu übertragen. Dies wird sie noch widerstandsfähiger gegen das Konzept machen, da sie (ihrer Meinung nach) bereits etwas haben, das funktioniert.
3. Haben Sie Kontakt zu Einzelpersonen in anderen Teams aufgenommen, um sich für das Konzept zu engagieren? Haben andere Entwickler ähnliche Meinungen oder Bedenken? Ein weiterer Weg, dies zu erreichen, besteht darin, eine kritische Masse unter den Menschen aufzubauen, die die Arbeit ausführen. Da immer mehr Menschen ein gemeinsames Quell-Repository nachfragen, muss das Management darauf achten.
4. Kennen Sie sich mit den Codes / Prozessen / Anforderungen der anderen Teams so gut aus, dass Sie sagen, dass GitHub für sie funktioniert (oder auch nicht)?

Was Ihre letzte (oder eigentliche?) Frage betrifft, so ist der einzige wirklich zwingende Grund auf lange Sicht aus Sicht der Geschäftsleiter, dass dadurch Geld gespart wird. Diese Einsparungen könnten in Form von reduzierten Ausfallzeiten, erhöhter Codesicherheit, erhöhter Entwicklerproduktivität, erhöhter Redundanz der Codebasis (für Backups) usw. u.ä. Was Sie letztendlich tun müssen, ist, die Personen, die Schecks für all dies ausstellen, davon zu überzeugen, dass sich die Zeit, der Aufwand und das Geld, die für die Umstellung auf ein solches Modell aufgewendet werden, am Ende als eine Rendite für ihre Investition lohnen werden. Sie müssen auch zeigen, dass die zukünftige Unterstützung für dasselbe Modell da sein wird, wenn es "langsam und absichtlich" endlich dazu kommt.

Es gibt eine Menge Dinge, die für eine solche unternehmerische Veränderung der Doktrin erforderlich sind. Daher ist eine Menge Enthusiasmus für den Basisstil erforderlich, und Sie benötigen auf jeden Fall jemanden auf der Ebene der Vizepräsidenten, der sich für das Konzept einsetzt. Ein Manager mag arbeiten, aber eine Führungskraft wird viel mehr Befugnis haben, Konzepte in andere Gruppen einzudrücken.

Solche Unternehmen möchten, dass ihre Repositories zentralisiert werden. SVN, VSS und PVC haben eines gemeinsam: Sie sind alle Client-Server-Architekturen. Git ist als verteiltes VCS konzipiert und von Natur aus dezentralisiert.

GitHub - noch problematischer. Es ist eine externe Dienstleistung. Der Quellcode in externen Diensten wird vom Management höchstwahrscheinlich nie akzeptiert.

Es gibt jedoch eine Lösung, die beide Seiten zufrieden stellen könnte. Git hat git-svnBefehl. Grundsätzlich hätten Sie ein SVN-Repository, aber einige Entwickler entscheiden sich möglicherweise für ein eigenes lokales GIT-Repository und synchronisieren es mit dem zentralen SVN-Repository. Gute Alternative zu privaten Filialen oder zum Versenden von nicht festgeschriebenen Patches. Gutes How-to für die Git-Svn-Integration .

Einige dieser Antworten sind in Bezug auf Kommentare zu GitHub und Sicherheit aufgrund von Änderungen bei GitHub, seitdem sie veröffentlicht wurden, erheblich veraltet.

• GitHub erzwingt kein externes Hosting
• Die KOSTENLOSE Version von GitHub setzt diese Einschränkung in Kraft.
• Für das interne Hosting steht eine Enterprise-Version von GitHub zur Verfügung . https://enterprise.github.com/home . Es ist nicht kostenlos und kostet natürlich $

Die Firma, bei der ich arbeite, hat gerade damit angefangen und wir hatten genau die gleichen Bedenken, weil unser Code ein Geschäftsgeheimnis ist, wir sind im Finanzsektor. Abgesehen davon gibt es andere Möglichkeiten, GIT zu verwenden, die GitHub nicht betreffen, die ähnlich sind, Redmine, Gitosis, etc ...

In Bezug auf die Frage, wer es verwendet: PayPal, Etsy, Rackspace, Vimeo, SAP, JPL der NASA , Linux-Kernel

Zwingende technische Gründe sind zu viele, um sie aufzulisten. Das Einzige, worauf es sich zu konzentrieren lohnt, sind die größeren Unternehmensfragen auf hoher Ebene, auf die die anderen Antworten hinweisen. Das größte, an das ich denken kann, ist Konsistenz, Einheitlichkeit, klare Prüfung, Einfachheit der Prüfung. Bei vielen dieser anderen VCS-Systeme ist es jedoch eine große Herausforderung, eine Vielzahl von Problemen zu lösen.

Der doppelte Aufwand für alle Abteilungen, die unterschiedliche verrückte Skripte schreiben müssen, um die verschiedenen Systeme zu integrieren, zu prüfen, Berichte zu erstellen und zu steuern, ist geringer.

• Jedes Mal, wenn ich SVN in einer paranoiden Umgebung wie einer Handelsfirma einsetzen musste, waren die absurden "Compliance" - und "Security" -Hooks für die Leistung äußerst nachteilig.

Da ich die technischen Verwendungsprobleme eines Entwicklers beschönigt habe, sage ich dies. Mit mehr als 15 Jahren Gesamtnutzung habe ich CVS, SVN, CMVC, Clearcase, Perforce und andere Systeme in einer professionellen Umgebung zusammen mit GIT verwendet. Wenn jemand wollte, dass ich etwas anderes als GIT verwende (mit Ausnahme von bzr, mercurial, perforce und clearcase (abhängig vom Setup der letzten beiden)), würde ich sofort wissen, dass meine Zeit besser woanders verbracht wird. Ich war bereits im Jahr 2009 fast zu diesem Schluss gekommen (obwohl ich CVS und SVN ein wenig zugestanden hatte). Ich hatte es so satt, dass ich Anfang 2010 anfing, GIT als SVN-Client zu verwenden Überzeugen Sie uns, auf GIT umzusteigen.