Mengapa perusahaan keuangan / asuransi besar harus menggunakan git dan / atau github

Saya bekerja untuk perusahaan besar (30 ribu karyawan) di industri keuangan / asuransi. Walaupun "IT" bukan fokus utama kami, mari kita jujur, ini adalah industri yang digerakkan oleh informasi dan perusahaan dengan keunggulan teknologi yang lebih baik tampaknya maju lebih cepat.

Ada banyak tim pengembangan perangkat lunak di perusahaan saya. Semuanya ada di peta dengan kontrol versi, apalagi bahasa / kerangka kerja yang digunakan. Beberapa tidak menggunakan (saya tahu), beberapa menggunakan PVC, beberapa menggunakan VSS, dan menggunakan SVN yang paling tercerahkan.

Saya ingin membawa git ke perusahaan saya. Lebih khusus lagi, saya ingin membawa GitHub (repositori pribadi). Saya tahu orang yang tepat untuk diajak bicara tentang hal ini, tetapi mari kita jujur ​​lagi, gerakan drastis seperti ini biasanya ditembak jatuh di lingkungan perusahaan besar karena masalah keamanan yang tidak jelas atau kenyataan bahwa tidak ada pesaing kita yang menggunakannya (dan saya bisa hanya mengutip jQuery, Ruby on Rails, Facebook, dll sebagai referensi).

Jadi pertanyaan saya adalah ini. Apa alasan paling meyakinkan mengapa perusahaan besar harus perlahan dan sengaja beralih dari PVCS / VSS / SVN ke solusi git yang di-host seperti GitHub (repo pribadi). Tentu saja, bagian dari rencana saya melibatkan POC untuk proyek pembangunan yang tidak penting.

Ada beberapa hal yang mungkin saya khawatirkan, sebagai pihak ketiga yang tidak tertarik. Jadi izinkan saya memberikan beberapa pertanyaan kepada Anda bahwa Anda sebaiknya siap menjawab (ke departemen TI Anda):

• Kontrol versi apa pun lebih baik daripada tidak sama sekali. Kami punya banyak pilihan, apa yang salah dengan itu?
• Kontrol versi terdistribusi? Apa itu? Bagaimana kita mengendalikannya ?
• Berapa biayanya? Bukan hanya perangkat lunak, tetapi server, lisensi, pemeliharaan, dll.
• Aku tidak percaya GitHub, atau setiap outsourcing hosting. Kita perlu melakukan semuanya di rumah. Mengapa kita tidak bisa mengatur server kita sendiri?
• Bisakah kita menjalankannya di Windows? Kita harus menyimpannya pada garis dasar kita saat ini, Anda tahu.
• Bagaimana kita mengamankan barang itu? SVN kita dapatkan, tapi ini membuatku takut.

Ini adalah pertanyaan pertama yang akan muncul. Adapun VSS dan PVCS Anda mungkin bisa datang dengan sekelompok argumen yang cukup bagus (seperti VSS merusak versi sejarah). SVN akan sedikit lebih sulit. Saya sangat merekomendasikan fokus pada kapabilitas gabungan GIT, dan juga merekomendasikan untuk tetap berpikiran terbuka tentang Mercurial. Setiap argumen untuk GIT juga merupakan argumen untuk Mercurial - dan Mercurial memiliki dukungan Windows yang lebih matang.

Keamanan sangat penting bagi lembaga keuangan dan pemerintah. Mereka akan sangat tahan terhadap sumber daya yang dihosting secara eksternal. Dari perspektif manajemen risiko, pertimbangkan apa yang bisa terjadi jika seseorang meretas GitHub dan mencuri kode sumber, atau menemukan kerentanan keamanan yang didokumentasikan dalam pelacak masalah. Itu akan menghancurkan perusahaan. Dari perspektif manajemen murni, jika perusahaan itu legaldiharuskan membayar Anda untuk setiap jam Anda bekerja, bagaimana mereka bisa memonitor apakah Anda bekerja dari rumah ketika sumber daya berada di luar jaringan VPN mereka? Pada catatan lain, bagaimana mereka dapat mencegah Anda melakukan spionase perusahaan ketika semua sumber daya tersedia dari luar perusahaan? Ini adalah argumen TI dan manajemen terhadap outsourcing hosting. Sebuah perusahaan besar memiliki untuk melihat hal-hal seperti ini. Untuk perusahaan kecil, Anda melihat garis bawah dan berapa biaya untuk menempatkan semua layanan di tempat.

Sebenarnya lebih murah bagi perusahaan besar untuk melakukannya sendiri. Mereka sudah memiliki sumber daya TI, mereka hanya perlu mengocok tanggung jawab sedikit. Dan jika solusinya sebagian besar mengurus dirinya sendiri dengan hanya perawatan berkala yang diperlukan (cadangan dan manajemen pengguna), semakin banyak alasan untuk menyimpannya di dalam pintu perusahaan.

Adapun Windows hosting, itu adalah organisasi dengan masalah organisasi. Beberapa perusahaan telah menelan koolaid Windows. Yang lain telah menelan Linux koolaid. Yang lain mempertimbangkannya berdasarkan kasus per kasus. Anda harus bermain sesuai aturan yang telah ditetapkan departemen TI untuk organisasi Anda. Selama solusi Anda dapat di-host di keduanya, Anda adalah emas.

Akhirnya, dalam organisasi besar seperti itu dijamin akan ada para bangsawan yang ingin melakukan segala sesuatunya dengan cara mereka. Mereka semua memiliki argumen yang meyakinkan mengapa mereka memilih VSS, PVCS, SVN, atau apa pun. Bagi mereka semua sama saja. Satu-satunya cara untuk mengkonsolidasikan dalam organisasi yang besar adalah memiliki perintah datang dari atas. Pesanan semacam itu selalu menemui perlawanan, dan mungkin itu bukan sesuatu yang ingin dilakukan perusahaan Anda kecuali ada manfaat Total Biaya Kepemilikan (TCO) yang jelas untuk memiliki sistem kontrol versi standar.

Saya juga bekerja di perusahaan keuangan / asuransi (meskipun tidak sebesar yang Anda bekerja saat ini). Kami juga memiliki beberapa tim pengembangan, dan sementara perusahaan telah memilih produk microsoft khusus untuk dikembangkan di sana masih tidak ada arsitektur master, bahasa atau kontrol sumber. Kita semua menggunakan .Net, tetapi kami memiliki banyak proyek dalam berbagai versi kerangka kerja dan dalam berbagai bahasa. Beberapa proyek menggunakan VSS yang lain TFS. Kami memiliki arsitek tingkat tinggi yang baru sebagai manajer QA sekarang dan dia telah mempelopori transisi perusahaan yang lebih banyak dari pelacakan bug hodge-podge kami, kontrol sumber, penggunaan kerangka kerja hingga implementasi TFS yang lebih universal untuk semua itu. Ini hanya dimungkinkan oleh fakta bahwa ia a) sangat berpengalaman dalam sifat perangkat lunak,

Dalam mengatasinya dalam organisasi Anda sendiri, Anda harus mempertimbangkan beberapa hal terlebih dahulu:

1. Mengapa Anda begitu terpikat dengan GitHub sebagai jawabannya? Apakah Anda mencari kontrol sumber umum atau Anda mencari alasan untuk mengimplementasikan sesuatu yang Anda sukai? Saya tidak tahu jawabannya (dan terus terang tidak peduli), tetapi ini adalah pertanyaan yang akan muncul ketika Anda mulai mencari-cari dalam bisnis orang lain.
2. Apakah Anda saat ini berafiliasi dengan salah satu tim perangkat lunak ini? Jika ya, Anda mungkin perlu menemukan individu yang tidak terafiliasi dan memiliki posisi yang baik untuk memperjuangkan konsep tersebut. Kalau tidak, tim pengembangan lain mungkin hanya merasa Anda mencoba untuk menanamkan pemikiran Anda pada mereka. Ini akan membuat mereka lebih tahan terhadap konsep karena mereka sudah memiliki sesuatu yang berfungsi (menurut mereka).
3. Sudahkah Anda melakukan penjangkauan kepada individu-individu di tim lain untuk mendapatkan dukungan terhadap konsep ini? Apakah pengembang lain memiliki pendapat atau masalah serupa? Jalan lain untuk mencapainya adalah dengan membangun massa kritis di antara orang-orang yang melakukan pekerjaan itu. Ketika lebih banyak orang mulai menuntut repositori sumber umum, manajemen harus memperhatikan.
4. Apakah Anda cukup familiar dengan kode / proses / persyaratan dari tim lain yang cukup untuk mengatakan bahwa GitHub akan (atau tidak akan) bekerja untuk mereka?

Adapun pertanyaan terakhir (atau aktual?) Anda, satu-satunya alasan kuat yang meyakinkan dalam jangka panjang dari perspektif manajer bisnis adalah karena ia menghemat uang. Penghematan ini bisa dalam bentuk downtime yang berkurang, peningkatan keamanan kode, peningkatan produktivitas pengembang, peningkatan redundansi basis kode (untuk cadangan), dll., Dkk. Apa yang Anda akhirnya perlu lakukan adalah meyakinkan orang-orang yang menulis cek untuk semua ini bahwa waktu, usaha dan uang yang dihabiskan untuk beralih ke model seperti itu akan sangat bermanfaat pada akhirnya sebagai pengembalian investasi mereka. Anda juga perlu menunjukkan bahwa dukungan di masa depan untuk model yang sama akan ada ketika "perlahan dan sengaja" akhirnya terjadi.

Ada banyak hal yang mengarah pada perubahan doktrin perusahaan, sehingga dibutuhkan banyak antusiasme gaya akar rumput dan Anda pasti membutuhkan seseorang di level VP untuk memperjuangkan konsep tersebut. Seorang manajer mungkin bekerja, tetapi seorang eksekutif akan memiliki lebih banyak wewenang untuk menanamkan konsep pada kelompok lain.

Perusahaan semacam itu ingin repositori mereka terpusat. SVN, VSS dan PVCS memiliki satu kesamaan - semuanya adalah arsitektur client-server. Git dirancang sebagai VCS terdistribusi, dan pada dasarnya didesentralisasi.

GitHub - bahkan lebih bermasalah. Ini layanan eksternal. Kode sumber dalam layanan eksternal adalah sesuatu yang kemungkinan besar manajemen tidak akan pernah menerimanya.

Namun ada solusi yang bisa membuat kedua belah pihak puas. Git memiliki git-svnperintah. Pada dasarnya Anda akan memiliki repositori SVN, tetapi beberapa pengembang mungkin memilih untuk memiliki repo GIT lokal mereka sendiri, dan menyinkronkannya dengan repo SVN terpusat. Alternatif yang baik untuk cabang pribadi atau mengirim sekitar tambalan yang tidak dikomit. Cara yang bagus untuk integrasi git-svn .

Beberapa jawaban ini sudah ketinggalan zaman sehubungan dengan komentar tentang GitHub dan keamanan karena perubahan di GitHub sejak diposting.

• GitHub tidak memaksa Anda untuk di-host secara eksternal
• Versi GRATIS dari GitHub adalah batasan yang berlaku.
• Ada Versi Perusahaan dari GitHub yang tersedia untuk hosting internal . https://enterprise.github.com/home . Itu tidak gratis dan biaya $ tentu saja

Perusahaan tempat saya bekerja baru saja menggunakannya dan kami memiliki kekhawatiran yang sama persis karena kode kami adalah rahasia dagang, kami berada di sektor keuangan. Selain itu ada cara lain untuk menggunakan GIT yang tidak melibatkan GitHub yang serupa, redmine, gitosis, dll ...

Mengenai pertanyaan "siapa yang menggunakannya": PayPal, Etsy, rackspace, vimeo, SAP, NASA JPL , Kernel Linux

Alasan teknis yang menarik terlalu banyak untuk disebutkan. Satu-satunya hal yang layak untuk dipusatkan di sini adalah masalah perusahaan tingkat tinggi yang lebih besar yang ditunjukkan oleh jawaban lainnya. Yang terbesar yang bisa saya pikirkan adalah konsistensi, keseragaman, audit yang jelas, kesederhanaan audit. Meskipun memecahkan harta karun masalah dengan banyak dari sistem VCS ini adalah besar.

Ada pengurangan dalam upaya duplikat untuk semua departemen yang harus menulis skrip aneh untuk mengintegrasikan antara sistem yang berbeda, untuk mengauditnya dan melaporkannya dan mengendalikannya.

• Setiap kali saya harus menggunakan SVN di lingkungan paranoid seperti perusahaan perdagangan, kait 'kepatuhan' dan 'keamanan' yang absurd sangat merugikan kinerja.

Karena saya membahas masalah penggunaan teknis dari calon pengembang, saya akan mengatakan ini. Dengan 15+ tahun total penggunaan, saya telah menggunakan CVS, SVN, CMVC, clearcase, perforce, dan sistem lain dalam pengaturan profesional bersama dengan GIT. Jika seseorang ingin saya menggunakan sesuatu selain GIT (dengan pengecualian mungkin bzr, lincah, memaksa dan menghapus (tergantung pada pengaturan dua terakhir)) Saya akan segera tahu waktu saya lebih baik dihabiskan di tempat lain. Saya hampir sampai pada kesimpulan itu (meskipun memperpanjang sedikit penyisihan untuk CVS dan SVN) pada tahun 2009. Saya sangat muak dengan bagaimana SVN digunakan di tempat kerja saya, saya mulai menggunakan GIT sebagai klien SVN pada awal 2010 sebelumnya. membantu meyakinkan kami untuk beralih ke GIT.