DVCS'de yanlış şubeyi taahhüt eden geliştiricileri durdurma

Sorun

Yaklaşık 10 geliştiricisi olan bir yazılım projesindeyim, kaynak kodunu Mercurial üzerinden paylaşıyoruz. Her sürüm için bir geliştirme ve üretim şubemiz var. Proje süresince tekrar tekrar bir şubeden kaynak kodu aldık, yani v1 yazılımın daha önceki sürümleri için yama ve bakım dallarına giriyordu, yani v2.

Bu, kodun yanlış şubeye gittiğini fark etmezsek, ya yanlış taahhüdü desteklemeye harcanan zamanla ya da yanlış (muhtemelen QAd olmayan) koda ulaşıp yanlış şubeye dağıtılmasına neden olur.

Şube ve birleştirme tasarımımız / yöntemimiz

               v1-test   v1-patch1   v1-patch2
               ^---------^-----------^                v1-prod
              /         / \           \
-----------------------/   \           \              v1-dev
              \             \           \
               --------------------------\            v2-dev
                             \       \    \ 
                              ^-------^-------------  v2-prod
                              v2-test v2-patch1      

Dolayısıyla, bir sürüm geliştirme dalında, hazır olana kadar , tüm sürümlerin ve bakımın yapıldığı tek bir test / UAT / Üretim dalı için dallayacağız. Etiketler bu şubenin sürümlerini oluşturmak için kullanılır. V1 test edilirken, v2 için bir dal oluşturulacak ve geliştiriciler yeni özellikler üzerinde çalışmaya başlayacak.

Gerçekleşmeye eğilimli olan şey, bir geliştiricinin v2-dev dalı nedeniyle v1-dev veya v1-prod'a iş yapması ya da daha kötüsü, v2-dev'i v1-prod (veya benzer hatalar) ile birleştirmesidir.

Çoğu geliştiriciye -prod dallarına erişmemelerini söyleriz , ancak kod yine de gizlice girer . Bir grup daha üst düzey geliştirici -prod dalına `` bakar ''.

V2 geliştirmeye yeni başlamış olsa da, sorunları düzeltmek için v1'e giren oldukça ağır bazı yamalar olabilir. Yani v1 sadece garip küçük yamayı almıyor olabilir.

Şimdiye kadar denediklerimiz

• Kapı bekçileri ile ayrı bir ürün dalı olması. A-prod şubesi, adı aracılığıyla uyarıları yükseltmelidir ve çoğu geliştiricinin bu şubede olması gerekmez. Bu sorunu gerçekten azaltmadı.
• Geliştiriciler arasında bu sorunun farkındalığını arttırmak, onları daha uyanık hale getirmek için. Yine bu pek başarılı olamadı.

Yanlış branşta çalışan geliştiriciler için gördüğüm olası nedenler

• Çok karmaşık bir şube tasarımı
• Paralel olarak çoklu branşlarda aktif gelişme. (Proje çığ modelini kullanma belirtileri sergilemektedir .)
• Geliştiriciler DVCS'yi yeterince iyi anlamıyor

Biraz alakalı olan okuduğum sorular

Bu soruyu yanlış dallara girmemeye dair okudum ve görsel ipuçlarıyla ilgili cevapların yararlı olabileceğini hissediyorum. Ancak yaşadığımız sorunların daha temel bir sorunun belirtisi olmadığına tamamen ikna olmadım.

Görsel ipuçları sayesinde, bunları komut satırına kolayca dahil edebiliriz, ancak takımın yaklaşık yarısı görsel ipuçlarını nasıl ekleyeceğimi bilmediğim tutulmayı kullanır.

Soru

Yazılımımızı, proje yönetimini veya yönetişim biçimini, zamanımızı alan veya dağıtılan kodumuzu kirleten yanlış şubeye indirgemek (ideal olarak durdurmak) için hangi yöntemleri kullanabiliriz?

Yukarıda belirtildiği gibi katkıda bulunabileceğine inandığım nedenlerle ilgili özel yorum takdir edilecektir, ancak bu yanıtınızı sınırlandırmamalıdır.

Sorun şu ki, bir dalın anlamının süreç boyunca kısmen ne olduğunu değiştiriyorsunuz .

Başlangıçta, v1 devşube gelişim içindir. Tüm yeni özellikler oraya gider. Gelecekte bir noktada, şube için bir bakım dalı haline gelir v1 release. Bu sorunun en önemli noktası.

Geliştiriciler özensiz değil, dalın izinleri ve rolleri özensiz ve değişebilir.

Yapmanız gereken, her dalın hangi rol olduğunu belirlemek ve bu rolü sürdürmektir. Rol değişirse, şube.

Örneğin:

 developer
  commits    |   |  |   |    |     |   |     |
             v   v  v   v    v     v   v     v
 dev  +--+---------------------+------------------->
         |           ^    ^    |           ^    ^
         |           |    |    |           |    |
 v1      +----+------+----+    |           |    |
           prod  patches       |           |    |
                               |           |    |
                               |           |    |
 v2                            +-----+-----+----+
                                  prod  patches

Bu modelde, geliştiriciler her zaman dev. Bir yama oluşturuyorsanız, yamayı o sürümün dalına doğru kontrol edersiniz (ya da daha iyisi, yayın dalını bir yama için dallar ve ardından tekrar yayın dalıyla birleştirirsiniz).

Okumanız gereken bir makale (ve muhtemelen 'olması gereken' için bir eksiklik ) Stephen Vance tarafından geliştirilen Gelişmiş SCM Dallanma Stratejileri'dir .

^{Bu yazıda, ilk olarak dallanmayı genel anlamda tanımlarım. Daha sonra, daha büyük geliştirme çabaları için daha uygun olan açıktan başlayarak ve birkaçına geçerek dallanma için çeşitli stratejileri tartışacağım. Yol boyunca, her stratejinin artılarını ve eksilerini tartışıyorum, bunları daha karmaşık stratejileri oluşturan değişiklikleri motive etmek için kullanıyorum ...}

Bu makalede, dalların sahip olabileceği beş rolü tanımlamaktadır. Bazen bir şube iki rolü doldurabilir ve rol politikaları orta şubeyi değiştirmediği sürece rollerin mutlaka yeni bir şubeye ihtiyacı yoktur (bazen "uyumsuz politikada şube" ifadesini göreceksiniz).

Bu roller:

1. Anahat. Burası dalların yapıldığı yer. Her zaman ana hattan dallanma birleşmeleri kolaylaştırır, çünkü iki dalın dallar üzerinde dallanmayan ortak bir atası olacaktır.
2. Gelişme. Burası geliştiricilerin kodu girdiği yerdir. Yüksek risk değişikliklerini rutin ve sıradan olanlardan izole etmek için çok sayıda geliştirme dalı olabilir.
3. Bakım. Mevcut bir üretim ortamındaki hata düzeltmeleri.
4. Birikim. İki dalı birleştirirken, ana hattın dengesini bozma riski almak istemeyebilir. Böylece ana hattı dallayın, dalları akümülatöre birleştirin ve işler çözüldükten sonra ana hatta geri birleştirin.
5. Packaging. Paketleme, paketleme dallarında bir serbest bırakma olur. Bu genellikle sürüm haline gelir ve sürümden çıkarma çabasını gelişimden izole etmeye yarar. Bkz. Uzun süredir yayımlanan sürümleri bozan istenmeyen taahhütlerle nasıl başa çıkılır? ambalajın gelişmeyle çeliştiği bir örnek.

Örneğin, basamaklı bir ana hattınız var (bu bir sorundur - birleştirmeleri zorlaştırır - v1 için bir düzeltmeyi v2 ve v3'e birleştirmek isterseniz ne olur?), Bir bakım dalı ( Politika değişikliği, bu bir sorundur).

Tamam, diyorsunuz, bu harika, ama bu merkezi bir VCS olan performans için yazılmıştır - DVCS kullanıyorum.

Bakmak Lets git-akış modeli ve bunun uygulamaya nasıl görüyoruz.

Ana dal (mavi), etiketleme için serbest bırakma dalıdır. Ana hat değil. Ana hat aslında geliştirme dalıdır (sarı). Salım dalları (yeşil) paketleme rolüdür. Ana çizgide düşük risk gelişimi, özellik dallarında (pembe) yüksek risk gelişimi gerçekleşir. Bu modelde, geliştirme dalında birikim yapılır. Bakım kırmızı olan 'düzeltmeler' olarak kabul edilir.

Rol politikaları tam olarak eşleşmese de (her ürünün kendi biraz farklı yaşam döngüsü vardır), bunlar bir eşleşmedir.

Bunu yapmak dallanma politikanızı basitleştirmeli ve ilgili herkes için daha kolay hale getirmelidir.

Ağ geçidi denetleyicileri ile ayrı bir ürün dalı kullanmayı denemiş olsanız da, bir depo aslında üretim yapılarını yapmak için kullanılmış gibi geliyor. Üretim sadece üretim deposundan yapıldı birikirse, yazılabilir sadece o Devs buna itmek mümkün olmaz 's bağlantı kontrol bilgisayarı tarafından. Bu, bekçi üzerine, yüklendikten sonra sadece üretim deposuna itecek bir yük getirir. Tabii ki insanlar ihtiyaç duyduklarında yine de üretim deposundan çekebileceklerdi.

İnsanlar tecrübe kazandıkça, eksik göründükleri konusunda daha derin bir anlayış veya bakım elde etmek için kapı bekçisi rolü ile döndürülmelidir.

Ve genel bir kural olarak, Occam's Razor'u uygulayın: tüm repo yapısı işini mümkün olduğunca basit yapmalıdır.

Ayrıca bakınız Sean'ın yorumu.

Geliştiricilerin DVCS'yi yeterince iyi almamaları mümkündür, ancak bence çok fazla devam etmeniz çok daha olasıdır ve geliştiriciler aniden yaptıklarını takip edemezler. Hangi branşta çalışmaları gerektiğini unutuyorlar ve değişiklikleri yanlış yere çıkıyor.

Herkesin bu dalların hepsinde düzenli olarak çalıştığı gerçeği ile ilgili bir sorununuz olduğunu öneririm.

@ andy256'nın prod için ayrı bir depo önerisi kesinlikle yardımcı olacaktır, ancak belirli bir haftada hiçbir geliştiricinin birden fazla dalda çalışmaması için işi farklı şekilde paketlemeyi veya belki de düzenlemeyi düşünmeniz gerekebilir.

Bu benim büyük böcek ayılarımdan birini tanımlamış gibi görünüyor. Kaynak kontrol araçlarının çoğu, kaynak kontrol araçlarıdır. Bir grup geliştiricinin aynı kaynak dizin üzerinde çalışmasına, değişiklik yapmasına ve çakışmaları ele almasına izin veriyorlar. Yol boyunca birkaç pürüzlü kenar olmuştur, ancak cvs, yıkım, git, mercural vb.

Sonra bir sonraki adıma sahipsiniz, serbest bırakılması için kodu stabilize etmeniz gerektiğinde ve dallamayı tanıttığınızda. Araçlar geliştiricilerin başarısız olduğu yer burasıdır. Araçlar, dal oluşturma ve hatta dallara ayrıldıktan sonra dallara tahakkuk eden değişiklik kümelerini belirleme yeteneğine sahiptir, ancak şu anda karşılaştığınız sorun bu değildir.

Araçlar, hangi değişikliklerin diğer dallara kopyalanması gerektiğini ve bunun ne zaman gerçekleşmesi gerektiğini seçme konusunda gerçekten zayıftır. Git-flow bunu dallar birleştirildiğinde, TÜM değişikliklerinin birleştirildiği ve daha sonra programcının ne zaman ve hangi dalların birleştirileceği konusunda mantıklı seçimler yapmasını gerektiren bir dallanma stratejisi oluşturarak bunu çözmeye çalışır.

Tüm geliştiricilerin tek bir sürüm iş parçacığı olan tek bir proje üzerinde çalıştığı tek bir depoda, git akışı sorunu çözer, ancak hayat birçok şirket için o kadar basit değildir.

Karmaşık ortam, toplam çözümün farklı yönlerinden sorumlu birden fazla ekibinizin bulunduğu ve diğer ekiplere dahili sürümler gerçekleştirdiğiniz yerdir. git-flow bu tür bir sorunu çözemez.

Bu çalışmayı görmenin tek yolu, her takımın sürümlerini tanımlamaktan ve bağımlılıklarının ne zaman değiştiğini kontrol etmekten sorumlu olup olmadığıdır. A takımı 1.3 sürümünü piyasaya sürdüğü için, B takımı yalnızca B takımı seçtiğinde A takımının 1.3 sürümünü kullanmaya başlar.

Gerçekte bir geliştirici ekibi, taşınması gereken değişiklik gruplarını tanımlar ve değişiklikleri alan geliştiriciler, değişiklik grubunu aldıklarında tanımlar.

Bunu gerçekten sağladığını gördüğüm tek kaynak kontrol aracı doğrudur - ve o zaman bile, geliştiricilerinizin çoğu bu konuda homurdanacak çünkü GUI onlar için çok kafa karıştırıcı ve yıkım gibi davranmıyor ...