Büyük finans / sigorta şirketleri neden git ve / veya github kullanmalı?

Finans / sigorta sektöründe büyük bir işletme (30K çalışan) için çalışıyorum. "BT" bizim odak noktamız olmasa da, dürüst olalım, bunlar bilgi odaklı endüstriler ve teknolojik avantajı daha iyi olan şirketler daha hızlı ilerliyor gibi görünüyor.

Şirketimde birçok yazılım geliştirme ekibi var. Tüm diller ve çerçeveler kullanılsın, sürüm kontrolü ile tüm harita üzerinde. Bazıları (biliyorum) kullanmıyor, bazıları PVCS kullanıyor, bazıları VSS kullanıyor ve en aydınlanmış SVN kullanıyor.

Git'i işletime getirmek istiyorum. Daha spesifik olarak, GitHub'ı (özel depolar) getirmek istiyorum. Bunun hakkında konuşmak için doğru insanları tanıyorum, ama yine dürüst olalım, bu gibi sert hareketler genellikle belirsiz güvenlik endişeleri veya rakiplerimizin hiçbirini kullanmadığı için büyük kurumsal ortamda vuruluyor (ve ben sadece referans olarak jQuery, Ruby on Rails, Facebook vb.).

İşte benim sorum bu. Büyük bir işletmenin neden yavaş yavaş ve kasıtlı olarak PVCS / VSS / SVN'den GitHub (özel repo) gibi barındırılan bir git çözümüne geçiş yapmasının en zorlayıcı nedenleri nelerdir? Tabii ki, planımın bir kısmı temel olmayan bir kalkınma projesi için bir POC içeriyor.

İlgisiz bir üçüncü taraf olarak endişe duyabileceğim birkaç şey var. Size cevap vermeye hazır olmanız gereken bazı soruları (IT departmanınıza) atamama izin verin:

• Herhangi bir sürüm kontrolü hiç yoktan iyidir. Aralarından seçim yapabileceğimiz çok şey var, bunların nesi var?
• Dağıtılmış sürüm kontrolü? Bu da ne? Bunu nasıl kontrol ederiz?
• Ücreti ne kadar? Sadece yazılım değil, sunucular, lisanslar, bakım vb.
• GitHub'a veya dış kaynaklı herhangi bir hostinge güvenmiyorum . Her şeyi kurum içinde yapmamız gerekiyor. Neden kendi sunucumuzu kuramıyoruz?
• Windows üzerinde çalıştırabilir miyiz? Bunu mevcut temelimizde tutmak zorundayız.
• İşi nasıl güvenceye alıyoruz? SVN alıyoruz, ama bu beni korkutuyor.

Bunlar ortaya çıkacak ilk sorular. VSS ve PVCS ile ilgili olarak, muhtemelen bir sürü makul derecede iyi argüman ortaya çıkarabilirsiniz (VSS'yi bozan sürüm geçmişi gibi). SVN biraz daha zor olacak. GIT'in birleştirme yeteneklerine odaklanmanızı ve Mercurial hakkında açık fikirli olmanızı tavsiye ederim. GIT için her argüman Mercurial için bir argüman - ve Mercurial daha olgun Windows desteğine sahip.

Güvenlik, finans ve devlet kurumları için büyük önem taşımaktadır. Harici olarak barındırılan kaynaklara karşı son derece dayanıklı olacaklardır . Risk yönetimi açısından bakıldığında, birisi GitHub'ı hackleyip kaynak kodunu çaldıysa veya sorun izleyicide belgelenen güvenlik açığını keşfettiğinde ne olabileceğini düşünün. Bu şirket için yıkıcı olurdu. Saf bir yönetim açısından, eğer şirket yasal olarakÇalıştığınız her saat için size ödeme yapmanız gerekiyorsa, kaynaklar VPN ağlarının dışındayken evden çalışıp çalışmadığınızı nasıl izleyebilirler? Başka bir deyişle, tüm kaynaklar şirket dışından alındığında kurumsal casusluk yapmanıza nasıl engel olabilirler? Bunlar barındırma dış kaynaklara karşı BT ve yönetim argümanlar. Büyük bir şirket olaylara bu şekilde bakmak zorundadır . Küçük bir şirket için, en alt çizgiye ve tüm bu hizmetleri yerine koymanın maliyetine bakıyorsunuz.

Aslında büyük şirketin bunu evde yapması daha ucuz. BT kaynakları zaten var, sadece sorumlulukları biraz karıştırmak zorundalar. Ve çözüm büyük ölçüde yalnızca periyodik bakım ihtiyacı (yedeklemeler ve kullanıcı yönetimi) ile ilgileniyorsa, bunu şirket kapılarının içinde tutmak için daha fazla neden.

Windows barındırma ile ilgili olarak, bu organizasyona göre bir kuruluştur. Birçok şirket Windows koolaidini yuttu. Diğerleri Linux koolaidini yuttu. Diğerleri bunu duruma göre değerlendirir. BT departmanının kuruluşunuz için belirlediği kurallara uymanız gerekir. Çözümünüz her ikisinde de barındırılabildiği sürece altınsınız.

Son olarak, böylesine büyük bir organizasyonda, her şeyi bir şeyler yapmak isteyen fahişeler olduğu garanti edilmektedir. Hepsinin neden VSS, PVCS, SVN veya neyi seçtiklerine dair ikna edici argümanları var. BT için hepsi aynı. Büyük bir organizasyonda birleştirmenin tek yolu, emrin yukarıdan fiat ile gelmesini sağlamaktır. Bu tür emirler her zaman dirençle karşılanır ve standart bir sürüm kontrol sistemine sahip olmanın belirgin Toplam Sahip Olma Maliyeti (TCO) avantajları olmadıkça muhtemelen şirketinizin yapmak istediği bir şey değildir.

Ayrıca bir finans / sigorta kuruluşunda çalışıyorum (şu anda çalıştığınız kadar büyük olmasa da). Ayrıca birden fazla geliştirme ekibimiz var ve işletme geliştirmek için özel olarak microsoft ürünlerini seçmiş olsa da, hala ana mimari, dil veya kaynak kontrolü yok. Hepimiz .Net kullanıyoruz, ancak çerçevenin farklı versiyonlarında ve farklı dillerde birden fazla projemiz var. Bazı projeler VSS, diğerleri TFS kullanır. Şimdi QA yöneticisi olarak yeni bir üst düzey mimara sahibiz ve hodge-podge hata takibimizden, kaynak kontrolünden, çerçeve kullanımından TFS'nin daha evrensel bir uygulamasına kadar daha kurumsal bir geçişe öncülük etti. Bu sadece a) yazılımın doğasında son derece deneyimli olması,

Bunu kendi kuruluşunuz içinde ele alırken, önce bazı şeyleri göz önünde bulundurmalısınız:

1. Cevap olarak neden GitHub'a aşık oldunuz? Ortak kaynak kontrolü mü arıyorsunuz veya rahat ettiğiniz bir şeyi uygulamak için bir neden mi arıyorsunuz? Cevabı bilmiyorum (ve açıkçası umursamıyorum), ancak bu, başkalarının işinde dolaşmaya başladığınızda ortaya çıkacak bir soru.
2. Şu anda bu yazılım ekiplerinden birine bağlı mısınız? Cevabınız evet ise, bu konsepti savunmak için iyi bağlanmamış, iyi konumlandırılmış bir kişi bulmanız gerekebilir. Aksi takdirde, diğer geliştirme ekipleri, düşüncelerinizi onlara baskılamaya çalıştığınızı düşünebilir. Bu, onları zaten işe yarayan bir şeyleri olduğu için (onların görüşüne göre) konsepte daha da dirençli hale getirecektir.
3. Konsepte katılım sağlamak için diğer takımlardaki bireylere erişim sağladınız mı? Diğer geliştiricilerin benzer görüşleri veya endişeleri var mı? Bunu başarmanın bir başka yolu, işi yapan insanlar arasında kritik bir kitle oluşturmaktır. Daha fazla insan ortak kaynak deposu talep etmeye başladığında, yönetimin dikkat etmesi gerekir.
4. Diğer ekiplerin kodunu / süreçlerini / gereksinimlerini GitHub'ın onlar için çalışacağını (veya yapmayacağını) söyleyecek kadar aşina mısınız?

Son (ya da gerçek?) Sorunuza gelince, işletme yöneticileri açısından uzun vadede tek gerçek zorlayıcı neden para tasarrufu sağlamasıdır. Bu tasarruflar, arıza sürelerinin azalması, kod güvenliği artışı, geliştirici verimliliğinin artması, kod tabanı yedekliliği (yedekleme için), vb. Şeklinde olabilir. Sonuçta yapmanız gereken şey, tüm bunları kontrol eden bireyleri, böyle bir modele geçiş için harcanan zaman, çaba ve paranın sonunda yatırımlarının geri dönüşü olarak buna değeceğine ikna etmektir. Ayrıca, aynı model için gelecekteki desteğin "yavaş ve kasten" nihayet gerçekleştiğinde orada olacağını da göstermeniz gerekecektir.

Doktrinde böyle bir kurumsal değişikliğe giren çok şey var, bu yüzden çok fazla taban tarzı coşkusu alacak ve konsepti savunmak için kesinlikle VP seviyesinde birine ihtiyacınız olacak. Bir yönetici çalışabilir, ancak bir yöneticinin diğer gruplara kavramları bastırma konusunda daha fazla yetkisi olacaktır.

Bu şirketler depolarının merkezileştirilmesini isteyeceklerdir. SVN, VSS ve PVC'lerin ortak bir yanı vardır - hepsi istemci-sunucu mimarisidir. Git dağıtılmış VCS olarak tasarlanmıştır ve doğası gereği merkezi değildir.

GitHub - daha da sorunlu. Harici bir hizmet. Harici hizmetteki kaynak kodu, yönetimin büyük olasılıkla asla kabul etmeyeceği bir şeydir.

Ancak her iki tarafı da memnun edebilecek bir çözüm var. Git'in git-svnkomutu var. Temel olarak SVN deponuz olurdu, ancak bazı geliştiriciler kendi yerel GIT deposuna sahip olmayı seçebilir ve merkezi SVN deposuyla senkronize edebilir. Özel şubelere iyi bir alternatif veya sıralanmamış yamaların gönderilmesi. Git-svn entegrasyonu için iyi nasıl yapılır .

Bu yanıtların birçoğu, gönderildiklerinden beri GitHub'daki değişiklikler nedeniyle GitHub ve güvenlik hakkındaki yorumlar açısından önemli ölçüde güncel değildir.

• GitHub sizi harici olarak barındırılmaya zorlamaz
• SERBEST GitHub'dan sürümü yerine bu sınırlamayı koyar budur.
• Dahili barındırma için GitHub'ın bir Enterprise Sürümü vardır . https://enterprise.github.com/home . Ücretsiz değil ve maliyeti $ elbette

Çalıştığım şirket kullanmaya başladı ve kodumuz bir ticari sır olduğu için TAM aynı endişeleri yaşadık, finans sektöründeyiz. Bunun yanı sıra, GIT'i kullanmanın benzer, redmine, gitosis, vb.

"Kim kullanıyor" sorusu ile ilgili olarak: PayPal, Etsy, raf alanı, vimeo, SAP, NASA'nın JPL'si , Linux Çekirdeği

Zorlayıcı teknik nedenler listelenemeyecek kadar çok. Burada odaklanmaya değer tek şey, diğer cevapların işaret ettiği yüksek seviyeli daha büyük kurumsal sorunlardır. Aklıma gelen en büyük şey tutarlılık, tekdüzelik, açık denetim, denetimin basitliği. Bu VCS sistemlerinin birçoğu ile ilgili bir hazine sorununu çözmek büyük bir problemdir.

Farklı sistemler arasında entegre olmak, onları denetlemek ve rapor etmek ve kontrol etmek için farklı tuhaf senaryolar yazmak zorunda olan tüm departmanlara yinelenen çabalarda azalma var.

• SVN'yi bir ticaret firması gibi paranoyak bir ortamda kullanmak zorunda kaldığım her zaman, saçma 'uyumluluk' ve 'güvenlik' kancaları performans için son derece zararlıydı.

Bir geliştiriciden teknik kullanım konularını ele aldığım için bunu söyleyeceğim. 15 yılı aşkın toplam kullanım ile CVS, SVN, CMVC, açık senaryo, performans ve diğer sistemleri GIT ile birlikte profesyonel bir ortamda kullandım. Birisi GIT'den başka bir şey kullanmamı isterse (belki de bzr, mercurial, performance ve clearcase hariç (son ikisinin kurulumuna bağlı olarak)) zamanımın başka bir yerde daha iyi harcandığını hemen bilirdim. 2009'da neredeyse bu sonuca vardım (CVS ve SVN'ye hafif bir ödenek de olsa). SVN'nin işyerinde nasıl kullanıldığına dair kısa düşüşlerden bıktım 2010'dan önce GIT'yi SVN müşterim olarak kullanmaya başladım bizi GIT'e geçmeye ikna etmeye yardım etti.