Çevrimiçi kod barındırma yapmalı mıyız?

İş yerimde iyi bir kaynak kontrolü ve proje yönetimi çözümü arıyoruz ve bir GitHub organizasyonu ve özel depolar oluşturmayı önerdim. GitHub'u birçok nedenden dolayı seviyorum, ancak bu GitHub ile ilgili değil (aslında meslektaşlarım rakip platformlar lehine puanlar sunacaklar) - özel kodumuzu çevrimiçi depolamakla ilgili .

Bunun iyi bir fikir olup olmadığını anlamaya çalışıyorum. Kesinlikle avantajlı görünüyor, çünkü sunucu maliyetlerine olan ihtiyacı ortadan kaldırıyor (en azından doğrudan) ve ayrıca kodun aranmasını kolaylaştırıyor (her şey çevrimiçi).

Ancak ekibimiz kararsız ve bana sorumu yönlendiriyor, bu kararı almak için nelere dikkat etmeliyiz?

Bir profesyonel olarak

Şirketinizin ofisi yanıyorsa, kod hala sunucudadır.

Şirketinizin ofisi yanmazsa , ancak git deponuzun bulunduğu sunucu DOES yaparsa , hala yerel bir kopyaya sahip olursunuz.

Deponuzu sunucunuzda şirketinizin ofis binasında barındırırsanız (Ağ paylaşımlı sürücüde olduğu gibi ...?), O zaman şirketin ofisi yanarsa, ikisini de kaybedersiniz.

Tabii ki, yine de her zamanki gibi desteğe ihtiyacın var ...

"Yanıkları" yerine "fidye yazılımı bulaşmış" olarak kullanmaktan çekinmeyin.

Temel olarak, kullanılabilirlik artıyor.

Bir con olarak

Dosyalarınızı, kodunuzu barındıracak 3. tarafla paylaşmanız gerekir. Gerçekten büyük şirket sırrınız varsa, buna izin verilmeyebilir. Örneğin, Avrupa vatandaşlarından kişisel bilgiler içeren bir veritabanınız varsa, kodunuzu ABD’den üçüncü bir şahısta barındırmanıza izin verilmeyebilir - çünkü ABD yasalarına tabi olacaklar ve bu nedenle AB gizlilik yasalarına uymak. Yasal bir sorun olmasa bile, üçüncü tarafın özel dosyalarınızı vermek için rüşvet verebileceğinin farkında olmalısınız . Bu, üçüncü taraf için büyük olasılıkla kötü olurdu (büyük itibar cezası), ancak olabilirdi.

Temel olarak, gizlilik azaldı.

Kullanılabilirlik için gizlilik konusunda işlem yapmanız tamamsa, özel kodunuzu üçüncü bir tarafla çevrimiçi olarak barındırmak iyi bir fikirdir. Aksi takdirde yapma. Patronunuzun akıllı bir karar vermesine izin vermek için takası açıklayabilirsiniz - ama "hayır" duyabilirsiniz. Birine bir karar verirseniz olan bu olabilir. Patronun hayır diyorsa, o kadar. Patronunu zorla ikna etmenin çok iyi bir fikir olduğunu sanmıyorum.

Açıkçası, bu sağlayıcıya bir güven meselesi ve kaynak kodunuza ne kadar değer verdiğinizdir.

Bununla birlikte, en azından geçmişte insanların kaynak kodlarına göre değer verdiklerini açıkça düşünüyorum.

• 'İş süreci otomasyonu' ürünleri için; Bir şirket içi ekibin özellikle iş dünyası için web siteleri ve diğer yazılımlar oluşturduğu yerlerde. Bu yazılımın diğer insanlara değeri genellikle çok düşüktür.

• Satılabilir yazılımlar için; sattığınız ikili koddur ve kaynak koduna erişmeden kopyalanabilir ve hacklenebilir.

İkincisi: Ayrıca, üçüncü bir tarafla kodunuzu depolamanızın, maruz kalmanızı mevcut seviyenin üzerine çıkardığını da düşünmelisiniz. Çoğu durumda olmaz

• Örneğin; Ürününüz arka uç kodu olmayan bir web sitesiyse, kodunuz zaten halka açıktır.
• Derlenmiş kodunuz dağıtılmışsa, kodları çözülebilir.
• Eğer kodunuz bir web sitesi veya servis ise ve bir üçüncü şahısla barındırıyorsanız. Sonra üçüncü taraf kodunuzu koyabilir.
• Yedeklerinizi üçüncü bir tarafla saklarsanız, kodunuza erişebilirler.

Kısacası, çoğu modern işletme, günlük işleriyle çeşitli üçüncü taraflara güvenecektir; onlar için hayati ve benzersiz şeyler bile.

Bu karar sürecinin bir parçası biraz test, deneme ve yanılma olabilir. Küçük bir projeye katılın ve birkaç üyenin farklı sitelerin bazılarını denemesini sağlayın. Bu takımın kullanılabilirliğini kapsamalıdır, ancak başka hususlar da var.

1. Mevcut Altyapı - Bazı şirketler zaten sunuculara, internet bağlantılarına, VPN'e ve sunucu barındırma becerisine sahip çalışanlara sahip olduğundan, maliyet ve endişelerin bir kısmı daha kolay bir şekilde karşılanabilir. Bir girişim, Github gibi bir şeyi kullanmaya daha meyilli olabilir çünkü bu tür yatırımları yapmak zorunda kalmazlar ve daha erken çalışmaya başlayabilirler.
2. Bütçe - # 1'in birçok yönü buraya girecektir, ancak yüksek fiyat etiketi olan başka çözümler de olabilir. Bazı şirketler maliyetleri haklı çıkarabilir. Açıkçası, düşük bir bütçeyle birçok seçenek elimine edildi.
3. Takım Dağıtımı - Herkes aynı saatte aynı ofisten çıktığında, github'a ihtiyacınız olmayabilir. Dosya sunucunuz çok yüklüyse, Git'i üzerine yerleştirin.
4. Güvenlik - Muhtemelen güvenli birçok site bulabilirsiniz, ancak bazı müşteriler için güvenlik algıları daha önemlidir. Kendi ironclad ağına sahip olmak, güvenlerini kazanmak için doğru şey olabilir. Güvenlik rozetleri, retina tarayıcıları ve silahlı güvenlik görevlileri, bazı müşterilere güvenlik sağlar.
5. Eğitim - Uygulamayı kullanmaktan çok daha fazlası var, şirketinizin / ekibinizin uygulamak istediği kurallar ve prosedürler var. Bir şeyi nasıl yapmak istediğinizi bilmek, hangi araçların kullanılacağını belirleyebilir. Başka ekip üyelerini çekmek, işlerinizi yapma şeklini beğenirse biraz daha kolaylaşır.

Kodlama ve sunma sürecinin tamamı boyunca çalışmaya başlayın. Bu sürece dahil olan kişiler ne kadar çoksa o kadar iyidir. Sadece yönetimde birisinin her şeyi değiştirmesi için belirli kriterlere dayalı bir kaynak kontrol platformu kullanmak istemezsiniz. “Bu dağıtılmış çevik şey işe yaramıyor, bu yüzden herkes pazartesi başından 8-7'de ofisten çalışmaya başlayacaktır.”

Ben mutlaka demiyorum olmamalıdır bulut içinde şirketinizin deposunu barındırmak, ama ben şahsen bulut barındırma ile bazı dezavantajları ve ağrıyı yaşadıysanız.

İnternet bağlantınız ne kadar hızlı ve güvenilir?

Bana göre, bu en büyük tek şey. Örneğin, şirketim oldukça kırsal bir bölgede bulunuyor. Bizim iken içi -net hızları hızlı yanan vardır, bizim arası -net hızları kötü en iyi ihtimalle, düpedüz flakey de yavaştır.

Hangi VCS'yi kullandığınıza bağlı olarak, ağrının bir kısmı hafifletilebilir. Git gibi dağıtılmış sürüm kontrol sistemleri o kadar da kötü değil çünkü hala yerel olarak çalışabilirsiniz. Bazı kodları bir iş arkadaşınızla gerçekten paylaşmanız gerekirse, bir ağ sürücüsünde yeni bir repo bile başlatabilirsiniz. Buna karşılık, Team Foundation ile bunlardan hiçbirini yapamazsınız (tüm yerel çalışma alanına rağmen).

Ama bu sadece kod. Bulutunuzda barındırılan depoda yalnızca koddan çok daha fazlası var. Peki ya iş öğelerin (özellikler / hata listesi)? Peki ya belgeleriniz (wiki)? Sürekli entegrasyon yapınız ne durumda? Bunların hepsi büyük olasılıkla kodunuzun yanında bulutta da barındırılacak. İnternet bağlantınız koparsa, bu şeyler olmadan nasıl çalışacaksınız?

Gitlab, ekibinizin ihtiyaç duyduğundan daha fazlasını sağlayacak olan ücretsiz bir şirket içi sürüm sunar. Bir yerinde kurulum yapmanızı şiddetle tavsiye ederim. Riskleri önemli ölçüde azaltacaktır.

Bu kararı vermek için nelere dikkat etmeliyiz?

Olumsuz yönleri düşünmelisin. Ben (diğerleri ile birlikte), şu andaki işverenimi şirketin taç fikri mülkiyet mücevherlerini özel bir github deposunda ağırlamayı bırakma konusunda başarıyla teşvik ettim. Beni yanlış anlama; Github açık kaynaklı yazılımlar için harika.

Kapalı kaynaklı yazılımlar söz konusu olduğunda, github.com (ya da bazı alternatif) kaynak kodunuzu dünyaya yayınlamamak için gizlilik sözleşmesi (NDA) imzalattınız mı? Bununla iyi şanslar!

Benim düşünceme göre, fikri mülkiyet mallarını başkalarının yanına NDA imzalayana kadar başkalarının varlığına açıklamak deliliktir. NDA'ları müşterileriyle imzalamayan github gibi bir hizmeti kullanmayı planlıyorsunuz. Bunun yerine, çok uzun bir EULA (son kullanıcı lisans sözleşmesi) şeklinde belirsiz bir söz veriyorlar.

Github kendileri bunun önemli bir sorun olabileceğinin farkındalar ve bunun sonucu olarak Github Enterprise'a kaynak kodları (ve diğer özel şeyleri) kendi sunucularında barındırma mekanizması olarak sunuyorlar.