Kovboy programcılarını kaynak kontrolünü kullanmaya nasıl ikna edebilirim?

GÜNCELLEŞTİRME
4 kişilik küçük bir devs ekibi üzerinde çalışıyorum. Hepsi kaynak kontrolünü kullandılar. Bir çoğu kaynak kontrolüne dayanamıyor ve bunun yerine kullanmamayı tercih ediyor. Kaynak kontrolünün profesyonel gelişimin gerekli bir parçası olduğuna kuvvetle inanıyorum. Birkaç sorun onları kaynak kontrolü kullanmaya ikna etmeyi çok zorlaştırıyor:

• Takım, TFS kullanmaya alışkın değil . 2 eğitim seansı yaptım, ancak yalnızca 1 saat verildi, bu da yetersizdi.
• Ekip üyeleri doğrudan sunucudaki kodu değiştirir. Bu kod senkronizasyonun dışında tutar. Sadece en son kodla çalıştığınızdan emin olmak için karşılaştırma yapılması gerekiyor. Ve karmaşık birleştirme sorunları ortaya çıkıyor
• Geliştiriciler tarafından sunulan zaman tahminleri, bu sorunlardan herhangi birini çözmek için gereken süreyi hariç tutar. Öyleyse, hayır deyince 10 kat daha uzun sürer ... Bu sorunları sürekli açıklamak ve kendimi riske atmak zorundayım çünkü şimdi yönetim beni “yavaş” olarak algılayabilir.
• Sunucudaki fiziksel dosyalar bilinmeyen şekillerde ~ 100 dosya üzerinde farklılık gösterir. Birleşme eldeki projenin bilgisini ve bu nedenle elde edemediğim geliştirici işbirliğini gerektirir.
• Diğer projeler senkronizasyondan düşüyor. Geliştiriciler, kaynak kontrolünde bir güvensizliğe sahip olmaya devam ediyor ve bu nedenle kaynak kontrolünü kullanmayarak sorunu daha da karmaşık hale getiriyor.
• Geliştiriciler, kaynak kontrolü kullanmanın zararsız olduğunu, çünkü birleşmenin hataya açık ve zor olduğunu savunuyorlar. Bu tartışılması zor bir noktadır, çünkü kaynak kontrolü çok kötü kullanılırken ve kaynak kontrolü sürekli atlanırsa, aslında hataya açıktır. Bu nedenle, kanıtlar kendi görüşlerine göre “kendisi için konuşur”.
• Geliştiriciler doğrudan sunucu kodunu değiştirmenin, TFS'yi atlamanın zaman kazandırdığını savunuyorlar. Bunu tartışmak da zor. Çünkü, başlangıç kodunu senkronize etmek için gereken birleştirme zaman alıyor. Bunu, yönettiğimiz 10+ projeyle çarpın.
• Kalıcı dosyalar genellikle web projesiyle aynı dizinde depolanır. Böylece yayınlama (tam yayınlama) kaynak kontrolü altında olmayan bu dosyaları siler. Bu aynı zamanda kaynak kontrolü konusunda güvensizliği de beraberinde getirir. Çünkü "yayıncılık projeyi bozuyor". Bunu düzeltmek (depolanan dosyaları çözüm alt klasörlerinden taşımak), bu konumlar web.config dosyasında ayarlanmadığından ve çoğu zaman birden fazla kod noktasında bulunduğundan, çok zaman alır ve hata ayıklama yapar.

Böylece, kültür kendini devam ettirir. Kötü uygulama daha kötü uygulamalara yol açar. Kötü çözümler, daha derin, çok daha fazla zaman alan sorunları düzeltmek için yeni korsanları yönlendirmektedir. Sunucular, sabit disk alanı bulmak çok zor. Ancak, kullanıcı beklentileri artıyor.

Bu durumda ne yapılabilir?

Bu bir eğitim konusu değil, insan faktörleri sorunu. İstemiyorlar ve yol blokları yaratıyorlar. Kırılan grup dinamikleriyle başa çıkma, onların itirazlarının temel nedeni nedir - genellikle korku, sadece değişim korkusu mu yoksa daha kötü bir şey mi?

Bugün hiçbir profesyonel geliştirici veya son 20 yıldır kaynak kontrolüne direnmedi. Bir kere, yaklaşık 30 ya da 40 yıl önce, bilgisayarlar yavaş olduğu zaman, kaynak kontrolü daha da yavaşladı ve programlar bir 500 satırlık dosyadan oluşuyordu, bu bir acıydı ve kullanmamak için geçerli sebepler vardı. Bu itirazlar ancak aklıma gelen en kötü kovboylardan gelebilir.

Sistem, bir şekilde hayatlarını zorlaştırmaya zorluyor mu? Bunun ne olduğunu bulun ve itirazı geçersiz kılmak için sistemi değiştirin. Yapana kadar tekrarlayın.

GIT veya Mercurial'a bakmayı öneririm. Her kaynak kod ağacında bir depo oluşturabilirsiniz, farkına bile varmazlar ve şimdi olduğu gibi hacklemeye devam edebilirler. Kod üssünde kırdıkları değişiklikleri izleyebilir, taahhütte bulunabilir, diğer kaynak ağaçlarında birleştirebilirsiniz. Bunlar, birkaç hafta içinde başka bir ürüne harcadığınız çabayı bir araya getirdiğini sandıklarında fikirlerini değiştirebilirler. Vidalarından birini bir komutla geri aldığınızda ve kıçlarını kurtardığınızda, size teşekkür bile edebilirler (buna güvenmeyin). En kötüsü, patronun önünde iyi görünüyorsun ve bir bonus için onları oldukları gibi kovboylar gibi gösteriyorlar.

Birleştirme, projenin yalnızca büyük bir bilgisini almaz

Bu durumda, maalesef küreksiz atasöz dereye düştüğünüzden korkuyorum. Birleştirme bir seçenek değilse, hiçbiri de uygulamıyordur, yani zaten bir dalda sahip olduğunuz özellikleri (gevşek olarak kullanılan terim) bir başkasına ekleyemeyeceğinizi söylüyorsunuz.

Yerinde olsaydım kariyer beklentilerimi tekrar gözden geçirirdim ...

Bazen gerçek dünya meseleleri kullanımı pratik yapmaz.

Yanlış.

Ekip kaynak kontrolünü kullanmaya alışık değilse, eğitim sorunları ortaya çıkabilir

Bunun kaynak kod kontrolü ve eğitim ile ilgisi ile ilgisi yok. Eğitim kolay, ucuz, verimli ve birkaç saat içinde yapılır. Kaynak kodu kontrolünü kullanmamak, riskli, riskli, verimsiz ve problemler sonsuza dek sürecek .

Bir ekip üyesi doğrudan sunucudaki kodu değiştirirse, çeşitli sorunlar ortaya çıkabilir.

Bu eğitim sorunu. Tekrar. Kaynak kod kontrolü ve eğitim ile ilgili her şey ile ilgisi yoktur.

Geliştiriciler, kaynak kontrolü konusunda bir güvensizliğe sahip olmaya devam ediyor ve bu nedenle kaynak kontrolü kullanmayarak sorunu daha da karmaşık hale getiriyor

Kaynak kod kontrolünün nasıl kullanılacağı konusunda eğitilmeleri gerekir. Maliyeti düşürür, riski azaltır, işleri basitleştirir ve daha verimlidir. Her seferinde temettü ödeyen tek seferlik bir yatırımdır.

Bu tür durumlarda ne yapılabilir?

Kaynak kodu kontrolünün nasıl kullanılacağı konusunda herkesi eğitmeye başlayın.

Güncelleme

Geliştiriciler doğrudan kaynak kontrolünü değiştirmenin zaman kazandırdığını savunuyorlar.

Yanlış olduklarından, bunun ne kadar yanlış olduğunu kesin olarak göstermek için veri toplamak önemlidir.

Ne yazık ki, ancak, yönetim uzun vadede maliyetli bir acil cevabı ödüllendirmektedir.

Bu ödül sistemini yenmenin tek yolu ...

A) Uzun vadeli maliyetin görünür kısa vadeli değerden yüksek olduğunu belirleyin.

B) Kısa vadeli yolsuzluğun (yani doğrudan değişikliklerin) uzun vadeli doğru kaynak kodu kontrolünden daha değerli görünmesini sağlayan fiili ödülleri tanımlayın. Kim yanlış bir şey yapmak için kafasına bir pat alır? Kafasında ne tür bir pat var? Kim veriyor? Bir şeyleri düzeltmek için, yanlış olan şeyleri ve aslında insanları teşvik eden belirli yönetici (ler) i isimlendirmelisiniz.

C) Kısa vadeli hızlı tepki yerine uzun vadeli değeri önemseyen gözden geçirilmiş bir ödül sistemi önerin. Farklı nedenlerle kafasına farklı patlar.

D) Halkı uzun vadeli bir değer için bulduğunuz ödüller konusunda eğitin; kısa vadeli hızlı tepkiden açıkça daha büyük olan değer.

Kaynak / sürüm kontrolünü kullanmayı reddeden geliştiricilerin, bu kadar basit bir şekilde kovulması gerekir. Daha önce belirttiğiniz gibi, kullanmamanın doğal riskleri ve maliyetleri, birçok, büyüklükteki emirlerin neden olduğu ek yüklerden daha ağır basar. Buna karşı çıkmaya çalışan herhangi bir kişi yazılım geliştirmeye dahil olmamalı ve bu insanlarla çalışmayı reddetti.

Kaynak kontrolümüzü dev'e dönüştürmek için sürekli bir entegrasyon sunucusu kurarak ilk önce sorunu çözdük. İkinci olarak, insanların kaynak denetimini atlatmasını ve dosyaları doğrudan değiştirmesini önlemek için klasör erişimini salt okunur olarak kilitleyin.

Bu, hatayı yerel olarak çoğaltamayacağınız günlerde bir PITA'dır, ancak bunun dışında, CI sunucusu tarafından otomatik olarak devlemeye zorlanacağını bilerek çalışmanın, kontrol etmenin ve devam etmenin daha hoş bir yanıdır.

Acını duyuyorum. 'Kaynak denetimi'nin ağ sürücüsündeki paylaşılan bir klasör olduğunu öğrenmek için birkaç işyerine girdim. Mesele genel olarak, yaklaşımın başka bir şeyden üstün olduğuna inandıkları için değil, basitçe işe yarıyor ve hiç bir zaman kaynak kontrolünü başarılı bir şekilde entegre eden bir iş akışına girmemişler.

Düz dünya takımı yapısıyla, yukarıdan aşağı doğru itilen değişimin elde edilmesinin, duruma yaklaşmanın en iyi yolu olmayabilir. Denemeye değer bir yöntem, kavramın momentum kazanmasına izin vermek için diğer devlerin bir veya ikisinden doğrudan alım yapmaktır. Gemide bir tane bile olsa, ekibin geri kalanına yaymak çok daha kolay olacak. Kavramını yavaşça tanıtın, küçük bir proje üzerinde çalışmaya başlayın, başlayın ve Git'e gidin , hatta GitHub'da barındırılan bir şeyi dallayın .

Basit başlayın, kavramları günden güne iş akışından yavaş ve ayrı olarak tanıtın. İnsanlar bir şeyler öğrenmekte ve değişime uyum sağlamakta harikadır, özellikle de bu değişiklik onlara doğrudan fayda sağlarsa (evrimi düşünün). Bununla birlikte, bir kerede bütün küçük değişikliklerle birlikte sunulduğunda, yabancılaşma olur. Kaynak kontrolünün nasıl çalıştığını ve sağladığı avantajları kavradıktan sonra, onu kendi iç projenizden birine entegre etmeyi deneyin (yeni bir projeye başlarsanız, bu onu tanıtmak için çok kötü bir zamandır). İsterseniz diğer projelerin de mevcut şekilde çalışmasına izin verin, bu özellikle iyi kod kontrolünün avantajlarını vurgulamakta etkili olacaktır.

Bu başarısız olursa, koş.

Durumunuzu belirleme ve çözme konusunda teknik becerileriniz var, problemleriniz insan ve süreçle ilgili.

İnsanlar vizyondan çok örneklere daha iyi cevap verme eğilimindedir, bu yüzden kendin "tamir et" derim:

En son kaynağın bir kopyasını alın, sürüm kontrolü dostu olacak şekilde yeniden yapılandırın, kullanışlı, ileriye dönük bir yapıya sahip yeni bir proje oluşturun (3. taraf bağımlılıklarını koyduğunuz şubeleri nasıl idare edeceğinizi öğrenin). Muhtemelen bunu kendi zamanınızda yapmak zorunda kalacaksınız.

Ardından iş arkadaşlarınızı ve yönetiminizi bir odaya sürükleyin ve 21. yüzyılda yazılım geliştirmenin nasıl olduğunu gösterin . Mevcut sisteminizdeki arızaları gösterin ve yeni yapınızla nasıl giderildiklerini gösterin.

Ayrıca kendinizi Kaynağın Koruyucusu olarak ayarlamak zorunda kalacaksınız - umursayan tek kişi göründüğünüz için, insanları (emrinde ne teknik veya psikolojik araçlarla olursa olsun) bunlara bağlı kalmaya zorlamak size kalmış Plan Bir müşteriye giden tek şeyin kaynak kontrolünün dışındaki bir inşaat makinesinden geldiğinden emin olun . Kurallara aykırı olan ve tahribata neden olan insanları ritüel olarak küçük düşürmek. Onlara çöreklerle rüşvet verin ... ne işe yarıyorsa

Her şey çok fazla çaba gibi görünüyorsa (hemen hemen her cevapta söylendiği gibi) - başka bir iş bulun. Zaman ayırmaya değmezler.

Adım 1 - Beceriksiz yönetici ateş!

1. adımı yapamıyorsanız, yöneticinin konuşlandırmayı yalnızca kaynak denetiminden alınan komut dosyalarına prodüksiyonla sınırlandırmasını sağlayın. Geliştiriciler (prod üzerinde üretim haklarına sahip olmamalıdırlarsa, eğer varsa 1. adıma bakın) eşyalarının konuşlandırılmasını istiyorlarsa, kaynak kontrolünden gelmesi gerekir. Bu, C # kodu yanı sıra veri tabanı işleri için kullanmaya başladığımızda kaynak denetimini oldukça iyi kullanmamak konusundaki sorunumuzu çözdü.

Birisi dosyalarının farklı sürümlerini ve farklılıkları görme becerisini nasıl istemez? Dallanma ve karmaşık şeylerin herhangi birini unutun. Temelleri bile anlamadılar. Bir üretim dosyasını, bir test ortamında en basit değişiklik yapmadan doğrudan değiştirmek delilik. Bazı kişilerle çalıştım ve neyse ki aynı projelerde hiç çalışmadık.

İş arkadaşların tembel olamayacak kadar aptal. Bu zaman kaybı. Yapabileceğin tek şey menajerini yetiştirmek. Yönetim, kaynak kontrolünü sevmelidir, çünkü bütün kontrol biçimlerini severler. Onları önemli hissettirir. Diğerlerini boşver; lideri tamir etmek, onun yerine koyamayacağın tek umudun. Diğer uzman geliştiricilerle ağ kurmaya başlayın ve ya bir açılışınız olduğunda ekibinize katılmalarını sağlayın ya da sizi dükkanlarında işe almalarını sağlayın.

Bu, kötü uygulamaların o kadar yaygın kullanıldığı bir projenin iyi bir örneğidir; bunu düzeltmek neredeyse imkansız hale gelir. Tamir edilmesi donmaya ihtiyaç duyar, böylece her şey kesintisiz olarak temizlenebilir. Ne yazık ki, bu tür projeler genellikle (açık nedenlerden ötürü) birkaç ay boyunca dondurulmayacak kadar çok ciddidir, kritik hataların her gün düzeltilmesi gerekir.

Projeyi, kirli sürüm bu günlük hatalarla tedavi edilirken temiz bir sürüm oluşturmak üzere biçimlendirmek isteyebilirsiniz; Ancak en olası sonuç, birkaç ay sonra "temiz" sürümün bitmesi durumunda, çataldan bu yana hangi düzeltmelerin ve değişikliklerin yanlış yapıldığını kimse söyleyemez. yaptıkları değişikliklerle ilgili kayıtları tutarlar). Temiz sürüm modası geçmiş, kirli sürüm hala çalışıyor, peki ne olacak? Temiz sürüm atıldı, naysays haklı çıktı.

Belirgin dışında Yeni bir iş bulun, cevabın yukarıdakilerin hepsi olduğunu düşünüyorum.

Kaynak kontrolünün kullanımına geçerek ve bunları uygulayarak onları yönlendirmek için önce yönetime gidin. Daha sonra, doğrudan sunucuda çalışmak anlamına gelse bile, işleri devam ettirmek için yapılması gerekenlere ulaşın. Her şeyi kaynak kontrolüne alma işlemini başlatın.

Diğer bir seçenek de en sonuncunun sunucuda olduğundan emin olmaktır (ne olursa olsun yapmanız gerekir) ve en sondan tamamen yeni bir havuz başlatmaktır. Tarihi kaybedeceksiniz, ama bu noktada küçük patatesler.

Açıklamanıza göre durumla ilgili bir veya daha fazla sorun varmış gibi görünüyor - ya dev ekibi kontrolden çıktı ya da kötü bir kaynak kontrol çözümü uygulandı. Her iki durumda da, bazı kaynak kontrol çözümünü kullanmak, geliştirme ekibinde görevlidir - üretim servisindeki kaynak kodunu doğrudan değiştirmek sadece sorunların ortaya çıkması için yalvarıyor.

Tecrübelerime göre, hemen gerçekleşmesi gereken ilk adım, kaynak kontrolünü üretim sunucusuyla senkronize etmek. Bu adım, üretim kodunun bir kopyasını almak ve kontrol etmek kadar basit olabilir - prod kodu muhtemelen ekibinizin geliştirdiği temeldir. Bu adımın mevcut kaynak kontrol sisteminde dolaşan kodla birleştirme ile artırılması gerekebilir. Kod, dev'ten entegrasyona / KG'ya (veya her ikisine) ve sonra aşama veya aşama / üretime akmalıdır.

Daha sonra, yönetimin kaynak kontrolünün kullanımını zorunlu kılması gerekiyor. Oldukça basit, derleme kaynak kontrol sisteminden gelmediyse, kodun üretime dağıtılmaması gerekir. Üretim erişiminin yalnızca destek ekibi ile sınırlı olması ve üretim sorunlarını gidermek için sınırlı erişim hakkı verilmesi gerekir. Geliştiriciler genellikle üretime sıcak kod dağıtımı yapmazlar - özellikle devler baskı altındaysa, üretim sorunları kesinlikle olabilir.

Yönetim kesinlikle buradaki meseleleri daha iyi ele almalı - kod doğrudan prod'a (ve kaynak kontrolüne girmeden) uygulanırsa gelişmeyi sürdürmek neredeyse imkansız olacak.

Asıl sorun, kovboy kodlayıcılarının sürüm kontrolü kullanmamasıdır. Asıl sorun, zaten bir şeyler yapmanın bir yolunu seçmiş olmalarıdır ve siz onların sürecini değiştirmeye çalışıyorsunuz. Seçilen işlem sürüm kontrolünü içermez. Programcıların kendileri bir sorun farketmediği sürece, tüm süreç değişiklikleri zordur. Mevcut sistemin yeterince iyi olduğu hissi varsa, farklı bir sistemi dayatmaya çalışmak sadece boşunadır. Biz borcum, sen asimile edileceksin. Tabii ki borc olmak için savaşmaya çalışıyorlar.

Kendi akıl sağlığınız için değişiklikleri makinenizde izleyebilmeniz için Git'i veya başka bir DVCS'yi ayarlamanızı öneririm. İş arkadaşlarınızın değişikliklerini sık sık havuzunuza aktarın. Çatışmaları olabildiğince iyi çöz. Bu kısmen sizi arkadaşlarınızın deliliğinden koruyacaktır.

Yönetimin, geliştiricilerin kaynak kontrolünü kullanması gerektiğini söylediğini söylediniz. Kötü olmak istiyorsanız, bunu TFS'de yapılan değişiklikleri kontrol ederek ve depoyu düzenli olarak yayınlayarak zorlayabilirsiniz, böylece TFS'de olmayan değişiklikleri gizleyebilirsiniz. (Kendi DVCS'nizi de koruyorsanız, ikisini senkronize tutmalısınız.) Bunu yapmanız için gerekçeniz yönetimden gelen siparişleri takip etmenizdir. İş arkadaşlarınız değişikliklerinin üzerine yazmaktan yorulursa, onları TFS kullanmaya davet edin. Ve iade edilmemiş değişiklikleri kontrol etmeye devam edin. İş arkadaşlarınız yardım edene veya kovulana kadar devam edin.

Geliştirmeleri dışındaki herhangi bir sunucuyu kilitleyin. Bir yapılandırma yöneticisi kullanın. Düzenlenebilir tanımlanabilir yapılar (etiketlere karşı) yapın. Her değişiklik setini etiketleyin (yani, hata başına 1 değişiklik seti). Ayrıca her yapıya bir etiket koyduk. Dev ve üretim arasında bir QA tipi sistem var (en azından). Doğru derleme etiketi kullanarak QA sistemine kurar. Onlara "yapıyı kırma" için üzülün.

Asla bir sorunu yeniden oluşturamadığım / düzeltemediğim (sadece prodüksiyonda gösterilen) bir durumla karşılaşmadım. Evet, konuyu bir geliştirme sisteminde yeniden oluşturmak için saatlerce harcadım (artı bunu çözdüğünüzde bunu regresyon testinize ekleyebilirsiniz).

Tüm bu kötü şeyleri yapan bir sürü kovboy müteahhitle bir proje yaptık. Ondan sonra temizlik yapmak için 4 haftamı harcadım ve sonra yukarıdaki uygulamaları yerine getirdim. Projenin o zamandan beri bunlarla hiçbir sorunu yoktu.

Alıntı:

Takım TFS kullanmaya alışkın değil

TFS, Microsoft Team Foundation Server olduğu ortaya çıktı.

İlk içgüdüm: "Bu, Microsoft Visual SourceSafe'in son sürümüdür"

İş arkadaşlarınızın yanında olurdum ve buna karşı çıkarım.