Geliştiriciler GitFlow kullanarak başka bir şubeden kodun birleştirilmesini bekleyerek engellendi

Ekibimiz FogBugz & Fırın / Mercurial'dan Jira & Stash / Git'e geçti. Git Flow modelini dallanma için kullanıyoruz, özellik dallarından alt görev dalları ekliyoruz (Jira özelliklerinin Jira alt görevleri ile ilgili). Üst şubeye geri birleştirmek için bir çekme isteği oluşturduğumuzda (genellikle geliştirir, ancak özellik dalına geri giden alt görevler için) bir gözden geçiren atamak için Stash'ı kullanırız.

Bulduğumuz sorun, özellik durumlarının en iyi planlanması ve dökümü ile bile, birden fazla geliştirici aynı özellik üzerinde birlikte çalışırken, ön uçta ve arka uçta, bağımsız bir kod üzerinde çalışıyorlarsa, ayrı dallarda bir geliştirici diğerini bloke eder.

Biz geliştikçe birbirimizin dalları arasında çekmeyi denedik. Ayrıca, her geliştiricinin, geliştirilirken entegrasyonu test etmek için birden çok daldan alabileceği yerel entegrasyon dalları oluşturmayı denedik. Son olarak ve bu şimdiye kadar bizim için muhtemelen en iyi şekilde çalışıyor gibi görünüyor, ancak biraz daha fazla yük ile, özellik dalından hemen yarasadan bir entegrasyon dalı oluşturmayı denedik. Bir alt görev dalı (özellik dalının dışında) çekme isteği ve kod incelemesi için hazır olduğunda, bu değişiklik kümelerini el ile bu özellik entegrasyon dalında birleştiririz. Daha sonra, ilgilenen tüm geliştiriciler bu entegrasyon dalından diğer bağımlı alt görev dallarına çekebilirler. Bu, herkesin bağımlı olduğu herhangi bir şubeyi kod incelemesini geçmesini beklemesini önler.

Bunun mutlaka bir Git sorunu olmadığını biliyorum - kendi iş sürecimiz ve kültürümüzle karışık, birden çok dalda birbirine bağlı kod üzerinde çalışmakla ilgili. Geliştirmek için katı kod inceleme politikamız yoksa (gerçek entegrasyon dalı) geliştirici 1, geliştirici 2'nin geliştirmesi için geliştirmek üzere birleştirilebilir. Diğer bir komplikasyon da, özelliği QA'ya teslim etmeden önce kod inceleme sürecinin bir parçası olarak bazı ön testler yapmamız gerektiğidir. Bu, ön uç geliştirici 1, doğrudan arka uç geliştirici 2'nin kolundan git, eğer arka uç geliştirici 2 biterse ve çekme isteği bir hafta boyunca kod incelemesinde oturuyorsa, ön uç geliştirici 2 teknik olarak çekme isteğini / kod incelemesini oluşturamaz çünkü kod inceleyicisi test çünkü arka uç geliştirici 2 '

Sonuç olarak, bu durumda hangi rotaya gittiğimize bağlı olarak kendimizi paralel bir yaklaşımdan çok daha seri bir şekilde buluyoruz ve bundan kaçınmak için kullanılacak bir süreç bulmak istiyoruz.

Bahsettiğim son şey, kodu incelenmemiş ve sonlandırılmamış dallar arasında kod paylaşarak gerçekleştirmemizdir, ancak özünde başkalarının beta kodunu kullanıyoruz. Bir dereceye kadar bundan kaçınabileceğimizi sanmıyorum ve bunu bir dereceye kadar kabul etmeye hazırız.

Sorun, arka uç ve ön uç geliştirme arasında çok katı bir görev ayrımında da olabilir.

Bir ön uç geliştiricinin yeni bir API'ya ihtiyacı varsa, düzenini doğrulamak için arka ucunda sahte bir API oluşturmasına (örneğin her zaman aynı değeri döndürerek) izin vermesi mümkün değil mi? Sonra bu kısmi uygulamayı bir saplama ile taahhüt edin ve ikinci kez bir arka uç geliştirici gerçek özelliği uygulayacaktır.

Bağımlılığı kırarak, daha iyi bir akış elde edersiniz ve darboğaz görevi gören tek bir görevi bekleyen her şeyi durdurmazsınız.

Sorununuz: Geliştirici Master'dan bir şube, Master'dan geliştirici B dalları, hem yakından ilgili özellikler üzerinde hem de Master dalda birleşmelerin zor olması kaçınılmaz bir gerçek.

Bu öngörülebilirse, A ve B önce ortak bir dal oluşturabilir, daha sonra her dal bu ortak daldan ayrı çalışmaları için, ayrı çalışmalarının her birini ortak dalda birleştirebilir ve şimdi çok fazla çatışmasız bir dalınız var. entegrasyonu daha kolay.

Geliştirici 1, A özelliği üzerinde çalışıyorsa ve geliştirici 2, A özelliğine bağlı B özelliği üzerinde çalışmayı bitirdiyse, bunun etrafında bir yol yoktur - B özelliği birleştirme beklemede. A özelliği olmadan test edemezsiniz ve henüz gözden geçirmenin bir anlamı yoktur, çünkü A özelliğindeki daha fazla ilerleme B özelliğinde değişikliklere yol açabilir.

Ancak bu, geliştirici 2'nin beklemede olduğu anlamına gelmez! Geliştirici 2, özellik C üzerinde çalışmaya başlayabilir ve özellik A tamamlandığında özellik B'nin inceleme-düzeltme döngüsüne dönebilir. Bağlam değiştirmenin en uygun olmadığını biliyorum, ancak A özelliğini tamamlamak için gereken zaman muhtemelen gün olarak ölçüldüğünden o kadar da kötü değil (15 dakikalık bir yan görev için onları "Bölge" den çıkarmıyorsunuz)

Bu duruma yardımcı olmak için yapabileceğiniz bir şey, geliştirme döngüsünü kısaltmanın yollarına iyi bir göz atmaktır.

Bir geliştiricinin başka bir geliştiriciden bir özelliği beklemesi durumunda, ilk geliştiricilerin çalışmasının bir kısmının, bloğu serbest bırakmak için tüm özellikten önce inceleme ve entegrasyondan geçmesinin bir yolu var mı?

Entegrasyon döngüsünün devam etmesini sağlamak için özellikleri daha küçük iş birimlerine bölmenin yolları var mı?

Ayrıca, entegrasyon ne kadar sürer? Bir derleme veya entegrasyonda uzun bir dönüş varsa, bu tüm kuyruğu yavaşlatabilir. Oluşturma süresini hızlandırmak için yapabileceğiniz herhangi bir şey olup olmadığına bakın, böylece kuyruklar daha hızlı boşaltılır.