Kaynak Kontrolü: Roller ve Sorumluluklar - En İyi Uygulamalar

Roller ve sorumluluklarla ilgili olarak, özellikle geliştirme dallarından gövdeye (veya anaya) olan birleşmelerden kimin sorumlu olduğunu "En İyi Uygulamalar" arıyorum. Temelde amacım için mühimmat arıyorum.

Karşılaştığım şeyi tanımlayayım. Belirli bir uygulamanın baş geliştiricisi (sahibi). Şirketimiz yakın zamanda VSS'den (başvurumun saklandığı VSS veritabanının yöneticisi olduğum yer) TFS'ye (yalnızca "operasyonlar" ekibimiz tarafından oluşturulan geliştirme dallarında izinlerim var) taşındı. Önceki işlerde TFS Yöneticisiydim, bu yüzden TFS ve MSBuild konusunda yolumu biliyorum.

Kullanılan dallanma ve birleştirme stratejisi ile ilgili bir sorunum yok (ana dal, gerektiğinde oluşturulan hata / proje geliştirme dalları ile anaya birleştirilmiş ve daha sonra serbest bırakma dalına yükseltilmiş). Sahip olduğum konular:

1. Kendi şubelerimi oluşturamıyorum. "Operasyonlar" ekibinin benim için şube oluşturmasını sağlamak için bir TFS görevi oluşturmalıyım.

2. Main'den geliştirme şubemle birleşemiyorum. Bir "operasyonlar" ekip üyesi birleştirme gerçekleştirmek için bir TFS görevi oluşturmak gerekir ve daha sonra "ops adam" bir geliştirici olabilir ve olmayabilir ve kesinlikle vardır çünkü takımlarımın herhangi bir değişiklik "adım" umuyoruz birleştirdiği kod hakkında çok az bilgi sahibi.

3. Gelişimden Main'e birleşemem. Yine "ops guy" birleştirme yapmak için bir TFS görevi oluşturmak gerekir, doğru bir şekilde umuyor. Sonra geliştirici olmayan birleştirme Main ile oluşan herhangi bir sorunları çözmek böylece benim şube geri birleştirmek için başka bir TFS görevi oluşturmak zorunda.

4. MSBuild komut dosyaları oluşturamıyorum veya düzenleyemiyorum. Yine MSBuild için yeni olan "ops" ekibi ile çalışmalıyım, böylece sadece en temel oluşturma görevleri gerçekleştirilebilir. (Karmaşık bir şeyi unutun ya da cenneti özel bir görevi yasaklayın).

5. Bir MSBuild komut dosyasını yürütemiyorum. Yine sadece "ops" ekibi bunu yapabilir.

6. Tüm bunların üstesinden gelmek için, genellikle istenen görevleri yerine getiren bir "kıyıdan uzak" kaynaktır, bu yüzden sabahın erken saatlerinde (şube / birleştirme / inşa etme) görevi oluştursam bile, muhtemelen tamamlanmayacaktır. o akşama kadar.

Artık "operasyonlar" ekibiyle sürüm şubelerini koruyan hiçbir sorunum yok. Yaptıkları tek şey (temelde) Main'den en son sürümü almak ve sürüm şubesine tanıtmaktır; "Ana" sabit ve hazır olduğu sürece, serbest bırakma dalı iyi olacaktır.

Benim görüşüm teknik liderlerin (I gibi) bagajın ("Ana") ve geliştirme dallarıyla birleşmesinden sorumlu olması gerektiğidir. Ekip yöneticisinin, Integration test ortamını oluşturmak ve dağıtmak için MS Build komut dosyaları oluşturma yeteneğine de sahip olması gerekir.

Biri beni davamı kanıtlamama yardımcı olacak bir Best Practices belgesine yönlendirebilir mi? Tüm araştırmalarım sadece dallanma ve birleştirme teknikleriyle ilgili En İyi Uygulamaları ortaya çıkardı ve DSÖ'nün söz konusu dallanma / birleştirme işleminden bahsetmemesi gerekir.

En iyi uygulamaları genel olarak benim ele aldığım şey, geliştirme ekibinin herhangi bir üyesinin, bu eylemlerin bir üretim dağıtımını başlatmak gibi şeyler yapmadığını varsayarak ağaç üzerinde herhangi bir eylem gerçekleştirebilmesidir. Belirli bir şube / etiket / havuzun, makul bir değişiklik kontrolü veya giriş engelleri koyarak otomatik dağıtımlar için bir kaynak işlevi gördüğü durumlarda, hataları kontrol etmekten ziyade, bazı kontrol düşkünleri açısından ziyade sadece hata perspektifinden uzak durmak mantıklıdır. Geliştiricileri dallar oluşturmaya ve yapı komut dosyalarını geliştirmeye teşvik ederim. Gerekirse geliştiricilerin üretime erişmesini sağlamak için yollar bulurdum. Kaynak kontrolünün bir parçası, hataların etkili bir sihirli silgisi olmasıdır - yapmanız gereken en kötü şey bir devir veya iki geri almak ve dallamaktır.

Maalesef bu, burada izledikleri yaklaşım gibi görünmüyor. Bunu yenmek için birkaç açıyı kapatmanız gerektiğini düşünüyorum:

a) Bu politikaların bir şeyler geliştirmeye zararlı olduğunu kanıtlayın. Bir şey üzerinde çalışmak için operasyonları beklerken harcadığınız her zaman günlüğe kaydedin. Bu tek başına bunun neden kötü bir politika olduğu konusunda makul bir yönetim satmalıdır.

b) Ops'de bazı arkadaşlar edinin - belki de bu politikanın bir nedeni vardır. Belki de bu muhakeme daha etkili bir şekilde ele alınabilir.

Bu yardımcı olur umarım.

Gördüğüm uygulamalar:

1. Herkes kalbinin içeriğine iş dalları oluşturabilir. Bir geliştirici, devam etmekte olan mevcut çalışmalarını depolamanın bir anlamı olduğunu gördükleri anda bir özellik dalı oluşturabilmelidir. Çünkü günün sonunda bunu istiyorlar / yedekliyorlar, başka bir ekip üyesiyle paylaşmak istiyorlar, ana değişikliklerden ya da herhangi bir şeyden korunmak zorundalar.

2. Herkes geliştirme dallarına kesinlikle her şeyi yapabilir. Geliştirici, başka bir geliştiricinin ihtiyaç duydukları bir şeyi anaya entegre ettiği andan itibaren birleştirebilmelidir.

3. Main ile birleştirmek (entegrasyon) için üç seçenek vardır:

   • Geliştiriciler bunu kendileri yapıyorlar. Riskleri sadece baş geliştirici ile tartışır ve özellikleri uygun şekilde test ederler. Bu herkesin izinleri olduğunu gösterir; birisi kuralları ihlal ederse, azarlanır ve yanlış değişiklik geri alınır.
   • Başka bir geliştirici, değişiklikleri inceledikten sonra yapar. Yine de herkesin bunu yapmak için izinleri olmasını gerektirir; kurallar hala baş geliştirici tarafından uygulanıyor.
   • Ana gözden geçiren ve birleştiren belirlenmiş bir entegratör vardır. Ancak entegratör ekibin bir parçasıdır ve kodu anlamalıdır. Daha küçük ekipte mimarla aynı kişi olacak, daha büyüklerinde ayrı olacaktı, ancak yakın işbirliği yapmaları gerekiyordu.

4. Bir özelliği kim hazırlarsa derleme betiğini uyarlamalıdır. Ama TFS ile nasıl çalıştığından emin değilim; Yapı komut dosyasını kullandığım sistemlerde her zaman sadece sürümlenmiş bir dosyaydı, bu yüzden geliştiriciler onu diğer her şey gibi düzenledi ve diğer her şeyle entegre edildi.

5. Belirlenmiş bir entegratör varsa, genellikle (çalıştırılacak komut dosyasının) tanımlanmasına ve yapıların başlatılmasına özen gösterirler. Aksi taktirde, takım lideri bunu yapar, atanan ekip üyesi bunu yapar veya herkesin izinleri vardır ve takım lideri delegeleri her bir duruma göre özel yapımlar kurar ve başlatır.

6. Hiçbir durumda yukarıdaki işlemler ekip dışında operatör gerektirmez. Operatör yalnızca izinleri ayarlamak, kopyalar oluşturmak ve benzeri işlemler için gereklidir.

"En iyi uygulamaları" boş verin (bana katlanın) bu bir yönetim sorunudur - temelde size yüklenen kısıtlamalar nedeniyle düzgün bir şekilde iş yapamazsınız.

Aslında "en iyi uygulama" nın ne olduğu önemli değil - bu, sizin ve ekibinizin verimliliğini etkileyecek basit ve kanıtlanabilir bir konudur ve bu doğrultuda hat yönetiminizi ele almanız gerekir.

Bunun en iyi yöntem belge kudretini sallayan (bkz ama sadece olabilir belki ) olmak bir yardım ikna etmeye çalışırken ama çok daha iyi farklı bir saat diliminde birini bekleyen iken dev ekip üyeleri ellerinde oturan zorunda olacağını kavramıdır süreçler iyileştirilmediği / rasyonelleştirilmediği sürece birlikte hareket etmelerini sağlamak.

Ve çok çatışmacı olmayın - kısıtlamaların neden mevcut olduğunu, gerekçenin ne olduğunu bilmek istediğiniz kadar.