大規模な金融/保険会社がgitやgithubを使用する理由
私は金融/保険業界の大企業（従業員数3万人）で働いています。 「IT」は私たちの主な焦点ではありませんが、正直に言うと、これらは情報主導の産業であり、より優れた技術的優位性を持つ企業はより早く前進するようです。
私の会社には多くのソフトウェア開発チームがあります。言語やフレームワークはもちろんのこと、バージョンコントロールを備えたマップ全体に配置されています。一部を使用しない（知っている）、一部はPVCSを使用する、一部はVSSを使用する、最も賢明なものはSVNを使用する。
Gitを企業に導入したい。具体的には、GitHub（プライベートリポジトリ）を導入したいと思います。私はこれについて話をする適切な人々を知っていますが、正直に言って、このような劇的な動きは、漠然としたセキュリティ上の懸念または競合他社の誰もそれを使用していないという事実のために、大企業の環境では通常撃ち落とされます（そして私はjQueryのみを引用、Ruby on Rails、Facebookなどで参照）。
だから私の質問はこれです。大企業がゆっくりと故意にPVCS/VSS/SVNからGitHub（プライベートリポジトリ）などのホストされたgitソリューションに切り替える必要がある最も説得力のある理由は何ですか。もちろん、私の計画の一部には、本質的でない開発プロジェクトのPOCが含まれています。
興味のない第三者として、私が気にかけているかもしれないことがいくつかあります。ですから、（IT部門に）回答する準備を整えておくとよいと思われる質問をいくつか投げかけます。
- バージョン管理は、なしよりも優れています。私たちにはたくさんの選択肢がありますが、それらの何が問題になっていますか？
- 分散バージョン管理？あれは何でしょう？それをどのようにcontrolしますか？
- どれくらいかかるか？ソフトウェアだけでなく、サーバー、ライセンス、メンテナンスなど.
- 私はGitHub、またはanyの外部委託ホスティングを信頼していません。すべてを社内で行う必要があります。独自のサーバーをセットアップできないのはなぜですか？
- Windowsで実行できますか？現在のベースラインを維持する必要があります。
- どうやって確保するの？ SVNは入手できますが、これは私を怖がらせます。
これらは出てくる最初の質問です。 VSSとPVCSに関しては、おそらく（VSSがバージョン履歴を壊すような）かなり適切な議論がたくさん出てくるでしょう。 SVNはもう少し難しくなります。私は、GITのマージ機能に焦点を当てることを強くお勧めします。また、Mercurialについてはオープンマインドを保つことをお勧めします。 GITのすべての議論はMercurialの議論でもあります-そしてMercurialはより成熟したWindowsサポートを持っています。
セキュリティは、金融機関や政府機関にとって最も重要です。それらは、外部でホストされるリソースに対して非常に耐性があります。リスク管理の観点から、誰かがGitHubをハッキングしてソースコードを盗んだり、課題追跡に記録されているセキュリティの脆弱性を発見した場合に何が起こるかを検討してください。それは会社に壊滅的な打撃を与えるでしょう。純粋な管理の観点から、会社があなたに働く時間ごとにあなたに支払うことを合法的に要求されるなら、彼らはどのように家から働いているかどうかをどのように監視できますかリソースはVPNネットワークの外にありますか？別の注意として、すべてのリソースが社外から利用可能な場合、企業スパイを実行することをどのように防ぐことができますか？これらは、ホスティングのアウトソーシングに対するITと管理の議論です。大企業はを物事をこのように見る必要があります。中小企業の場合、収益と、これらすべてのサービスを導入するのにかかる費用を調べます。
大企業が社内で行う方が実際には安上がりです。彼らはすでにITリソースを持っているので、責任を少し変更するだけで済みます。また、定期的なメンテナンス（バックアップとユーザー管理）のみでソリューションの大部分が自動的に処理される場合は、それを企業のドアの内部に保持する必要があります。
Windowsホスティングに関しては、それは組織ごとの問題です。いくつかの企業がWindowsのkoolaidを飲み込んでいます。 Linuxクーライドを飲み込んだ人もいます。他の人はケースバイケースでそれを考慮します。 IT部門が組織に設定したルールに従って行動する必要があります。ソリューションがどちらでもホストできる限り、あなたは黄金です。
最後に、そのような大規模組織では、すべてが自分のやり方でやりたいと思っている領土であることが保証されています。彼らはすべて、VSS、PVCS、SVN、または君は。 ITにとって、それらはすべて同じです。大規模な組織内で統合する唯一の方法は、注文を上からフィアットに送ることです。このような注文には常に抵抗があり、標準化されたバージョン管理システムを使用することによるTCO（Total Cost of Ownership）の明らかなメリットがない限り、会社が望むことではないでしょう。
私はまた、金融/保険会社で働いています（ただし、現在働いている会社ほど大きくはありません）。また、複数の開発チームがあり、企業が開発するMicrosoft製品を具体的に選択している一方で、マスターアーキテクチャ、言語、ソース管理はまだありません。私たちはすべて.Netを使用していますが、フレームワークの異なるバージョンと異なる言語の複数のプロジェクトがあります。一部のプロジェクトはVSSを使用し、その他はTFSを使用します。現在、QAマネージャーとして、より高いレベルのアーキテクトがおり、ホッジポッジのバグ追跡、ソース管理、フレームワークの使用から、すべてのTFSのより普遍的な実装へのより多くのエンタープライズ移行を先導しています。これは、彼がa）ソフトウェアの性質に非常に精通していること、b）会社内の高い位置にあり、ギルとポジションの両方を通じて影響力があること、およびc）特定のソフトウェアチームに直接所属していないことによってのみ可能になります。 。
組織内でこれに対処するには、最初にいくつかのことを考慮する必要があります。
- なぜあなたは答えとしてGitHubにそんなに夢中になるのですか？一般的なソース管理を探していますか、それとも快適なものを実装する理由を探していますか？私は答えを知りません（そして率直に言って気にしない）が、これはあなたが他の人のビジネスでうとうとし始めるときに出てくる質問です。
- 現在、これらのソフトウェアチームの1つに所属していますか？もしそうなら、あなたはその概念を擁護するために、無関係で適切な立場にある個人を見つける必要があるかもしれません。さもなければ、他の開発チームはあなたが彼らにあなたの考えを刻印しようとしていると感じているだけかもしれません。彼らはすでに（彼らの意見では）機能するものを持っているので、これは彼らをコンセプトに対してさらに抵抗力があるようにするでしょう。
- 他のチームの個人にコンセプトの賛同を得るために何か手を差し伸べましたか？他の開発者も同様の意見や懸念を持っていますか？それを達成するための別の方法は、作業を実行する人々の間で批判的なマスをフォローすることです。より多くの人々が共通のソースリポジトリを要求し始めると、管理者は注意を払う必要があります。
- 他のチームのコード/プロセス/要件を十分に理解していて、GitHubがそれらに対して機能する（または機能しない）と言うのに十分ですか？
最後の（または実際の？）質問については、ビジネスマネージャーの観点から見ると、長期的に見て唯一の真の説得力のある理由は、お金を節約できるということです。これらの節約は、ダウンタイムの短縮、コードのセキュリティの向上、開発者の生産性の向上、（バックアップ用の）コードベースの冗長性の増加などの形で発生します。最終的に必要なことは、これらすべてのチェックを作成する個人に、そのようなモデルへの移行に費やされる時間、労力、および費用は、最終的には投資収益として十分に価値があると確信させることです。また、最終的に「ゆっくりと意図的に」発生したときに、同じモデルの将来のサポートが存在することを示す必要があります。 （何らかの理由で）ソフトウェアのサポートが利用できなくなった場合、またはホストされたモデルで会社が腹を立ててドアを閉めた場合はどうなりますか？
このような企業理念の変更には多くのことが含まれるため、草の根的なスタイルの熱意がたくさん必要となり、VPレベルでコンセプトを擁護する人が必ず必要になります。マネージャーは働くかもしれませんが、幹部は他のグループに概念を刻印するより多くの権限を持っています。
このような企業は、リポジトリを一元化する必要があります。 SVN、VSS、およびPVCSには、1つの共通点があります。それらはすべてクライアントサーバーアーキテクチャです。 Gitは分散型VCSとして設計されており、本来は分散型です。
GitHub-さらに問題があります。これは外部サービスです。外部サービスのソースコードは、経営者が受け入れることはほとんどありません。
ただし、双方を満足させることができる解決策があります。 Gitには git-svn コマンド。基本的にはSVNリポジトリがありますが、一部の開発者は独自のローカルGITリポジトリを用意し、それを集中型SVNリポジトリと同期させることもできます。プライベートブランチやコミットされていないパッチの送信に代わる優れた方法。良い git-svn統合の方法 。
これらの回答のいくつかは、投稿後のGitHubでの変更のため、GitHubとセキュリティに関するコメントに関して大幅に古くなっています。
- GitHubは、外部でホストされることを強制しません
- GitHubの[〜＃〜] free [〜＃〜]バージョンがこの制限を設けています。
- 内部ホスティングに使用できるGitHubのエンタープライズバージョンがあります。 https://enterprise.github.com/home 。無料ではなく、もちろん$の費用がかかります
私がそれを使い始めたばかりの会社では、コードは企業秘密であるため、まったく同じ懸念がありました。私たちは金融部門にいます。それはさておき、GitHubを含まないGITを使用する他の方法があります。これには、類似、redmine、gitosisなどがあります。
「誰が使っているか」という質問について：Paypal、Etsy、rackspace、vimeo、SAP、NASAのJPL、Linuxカーネル
説得力のある技術的な理由は多すぎて列挙できません。ここで注目すべき唯一のことは、他の回答が指摘している高レベルの大企業の問題です。私が考えることができる最大のものは、一貫性、統一性、明確な監査、監査の単純さです。しかし、これらの他のVCSシステムの多くの問題の宝庫を解決することは大きな問題です。
異なるシステム間を統合し、それらを監査してレポートし、それらを制御するために異なる奇抜なスクリプトを作成する必要があるすべての部門で、重複した労力が削減されます。
- 商社のような偏執的な環境でSVNを使用しなければならないたびに、不条理な「コンプライアンス」と「セキュリティ」のフックはパフォーマンスに非常に有害でした。
開発者の見込みから技術的な使用法の問題について説明したので、これについてお話します。 15年以上の総使用量で、私はCVS、SVN、CMVC、クリアケース、perforce、およびその他のシステムをGITとともにプロの設定で使用しました。誰かが私にGIT以外のものを使用したいと思った場合（おそらくbzr、Mercurial、perforce、およびclearcase（最後の2つの設定に応じて））（== --- ==） 2009年に私はほぼその結論に達していました（CVSとSVNに若干の許容範囲を拡張しましたが）。私はSVNが私の場所でどのように使用されたかという短い説明にうんざりしていました2010年の初めにGITをSVNクライアントとして使用するようになり、GITに切り替えるよう説得しました。