KG ekibi Gitflow dallanma modelinde testi nerede yapmalı?

Aynı git deposuna sahip birden fazla proje üzerinde çalışan büyük bir ekibiz (10-12 geliştirici ve 4 qa). Onun bir bahar çizme tabanlı arka uç web hizmeti. İyi bir git dallanma ve konuşlandırma stratejisi arıyoruz. Ayrıca, özelliklerimizin beklendiği gibi çalışmasını sağlayan bir qa ekibimiz var (belirli bir ölçüde hata içermez).

Birkaç makale okuduktan sonra Gitflow modelinin bizim için iyi çalışacağını hissettim . İşte sorum geliyor.

KG ekibimiz özelliklerimizi nerede test etmelidir?

1. Özellik dalında test ederse, hataları yükseltir ve geliştirici bunu düzeltir ve KG testini geçtikten sonra geliştirmek için birleştiririz. QA yine geliştirme dalında entegrasyon testini yapacaktır.
2. tüm özellikleri (birim testleri ve geliştiriciden yapılan temel testlerden sonra) bir araya getirip şube geliştirip qa testini oradan yapalım. düzeltmeler ve testler de geliştirilecektir.

Başkaları için hangi yaklaşımın işe yaradığını merak ediyorum.

KG muhtemelen iki kez test ediyor olmalıdır.

İlk test belirli değişikliklerin etrafında yapılmalı ve özellik dalında yapılmalıdır. Bu, KG'nin belirli değişiklikler etrafında test etmesini ve belirli değişikliğin belirtildiği gibi tamamlandığını ve beklendiği gibi davrandığını görmenizi sağlar. Aynı zamanda onlara ikinci test turu için erken bir önizleme verir, bu da KG için gerçekten önemlidir.

Çeşitli düzenlenmiş ortamlarda geçmişimden geldiğimde, ikinci testin geliştirme sürümündeki bir sürüme karşılık gelen bir etikete veya sürüm şubesine veya belki de ana şubeye yapılması gerekir. Bir sürümden önce KG, dağıtılmadan önce dağıtılacak olan tam ve tam kodu test ediyor olmalı ve KG tarafından test edilen her şeyin üretime dağıtılanla tamamen aynı olduğunu iddia edebilmelisiniz. Benim tercihim, bir kod dondurulduktan sonra, serbest bırakma dalına bir etiketin uygulanması ve KG'nin bunu test etmesi olacaktır. Değişiklikler bir geliştirme dalında yapılacak, yerinde kontrol edilecek ve daha sonra serbest bırakma dalındaki yeni bir etikette tekrar test edilecektir. Sürüm dalındaki bu etiketler sürüm adaylarına karşılık gelir.

Burada birkaç varsayımda bulunuyorum. İlk olarak, geliştiriciye dayalı biraz test kapsamına sahipsiniz. İdeal olarak, bu, geliştiricilerin herhangi bir dalda herhangi bir kodu KG'ye göndermeden önce çalıştırıp yaptıkları otomatik birim ve entegrasyon testleri olacaktır. Geliştiriciler ayrıca, KG testinden önce işlerin doğru göründüğünden emin olmak için kullanıcı arayüzü etrafında bazı keşif testleri yapmak isteyebilirler. İkincisi, özelliklere göre yeterli KG süresi sağlamak için dahil edilen değişiklikleri planlamak için geliştirme ve KG arasında iyi bir koordinasyon vardır.

Harika bir soru. Bunun 'resmi' doğru cevabı olduğunu sanmıyorum. Ne kadar hızlı test edebileceğinize bağlıdır.

Temel sorun, her birleştirme, derleme ve hatta dağıtımın potansiyel olarak bir hata oluşturabilmesidir. Test ettiğiniz zincir ne kadar 'yukarı' çıkarsa, hataları o kadar çabuk bilirsiniz, aynı zamanda tekrar test etmek zorunda kalırsınız.

Müşterilerin kullandığı yazılımı test ettiğinizden emin olmak için, müşterilerin trafiği (bir web uygulaması varsayarak) bu sunuculara mavi / yeşil bir dağıtım modeli aracılığıyla yönlendirilmeden önce canlı dağıtımı gerçekten test etmeniz gerekir.

Ama açıkçası bu kodu ilk kez kontrol etmek için gün biraz geç!

Bir yayın dalını bir qa env'de test ederseniz, riski alabilir ve canlı testi yalnızca duman testlerine indirebilirsiniz. ve sürüm dalına hata düzeltmeleri uygulayın. Ancak bir sürüm oluşturmadan önce bir özelliğin tamamlanıp tamamlanmadığını değerlendiremezsiniz

Geliştirmeyi test ederseniz, mini hata düzeltme özelliği dalları alırsınız. Özellikler değerlendirilmeden önce hala birleştirilir ve bir sonraki sürümün özellikleri mevcut sürümü test etmekle çarpışabilir.

Özellik dallarını test ederseniz, bir milyon ortama ihtiyacınız vardır ve birleştirme sırasını düzenlemek ve oturumları test etmek zorundasınız. artı tekrar test.

Deneyimlerimden tavsiye ederim:

dev makinede özellik şube hızlı testi. sadece özelliklerinin eksiksiz olmasını sağlayın ve test kullanıcıları / geliştiriciler gereksinimlerin ne anlama geldiğini kabul eder.

Qa sunucularına dağıtılan geliştirici dalında günlük test / otomatik test. Tüm özellikleri birlikte test etmenizi ve ne zaman piyasaya sürülmeye hazır olduğunuzu söylemenizi sağlar.

Tüm özellikler varsa ancak test tamamlanmadıysa. örneğin sprint tamamlandı. bir yayın dalı oluşturun ve ikinci bir qa ortamına konuşlandırın. Bu, sürüm 1'deki hata düzeltme / testin sürüm 2 özellikleriyle aynı anda devam etmesini sağlar.

(scrum adanmışları sprint 2'ye sadece hata düzeltmeleri koymanız gerektiğini söyleyecektir, ancak pratik olalım)

Geçiş yapmadan önce canlı yeşil / mavi konuşlandırmasında duman testleri. Bunlar, geliştirirken kimsenin aramayacağı yapılandırma / çevre hatalarını alacağınız için çok önemlidir.

Thomas Owens'a katılıyorum. Muhtemelen iki kez test ediyor olmalısınız. Bir kez özellik dalına birleştirilmeden önce ve bir kez ana dalınıza bırakmadan önce.

Aslında, ben, bir araç yapılmış o kadar ki iş akışını seviyorum Topico otomatik oluşturur ve her çekme isteği için uygulamanızın atılabilir sürüm çalıştırır, kendine özgü test URL ile her. Bu, KG ekibinizin kendi makinelerinde oluşturulmuş bir tür dinamik test ortamına ihtiyaç duymadan özellik dallarını ayrı ayrı test etmesini sağlar.

Bu yaklaşım, yalnızca insan testlerinden geçen kodun ana şubenize ulaşacağı ve böylece bütünlüğünün korunduğu anlamına gelecektir.

Bunu birkaç şirkette tanıttım ve sürüm döngülerinize çok yardımcı oldu. Artık sürümleri doğru bir şekilde planlayabiliyoruz ve bir sonraki sürüme neyin getireceğini ve gelecekteki bir sürümü beklemek zorunda kalacağını anlama konusunda çok daha iyiyiz. Sadece size çok daha fazla güven veriyor.