Scrum ve istikrarlı bir gelişme bir çelişki oluşturuyor mu?

Toplamda yaklaşık 40 geliştiriciden oluşan 5 ekip içeren bir geliştirme grubunun üyesiyim. Scrum metodolojisini 3 haftalık sprintlerle takip ediyoruz. Birkaç saat süren bir inşa boru hattıyla (kapsamlı otomatik testler nedeniyle) sürekli bir entegrasyon kurulumumuz (Jenkins) var. Temel olarak, geliştirme süreci iyi çalışır.

Bununla birlikte, birkaç gün sonra yeni bir sprint içinde yapımızın genellikle kararsız hale geldiğini ve sprint-sonu "kesinti duruncaya" kadar titrek kaldığını gözlemliyoruz. Bu olumsuz etki, o yapı özellikle UI- / Webtests edilir uzak boru hattı aşağı adım uzaklıktadır değil (sadece bir 'yeşil' yapı üzerinde tetiklenen çünkü) birkaç gün boyunca yürütülür. Sonuç olarak, yeni tanıtılan hatalar genellikle sprintte çok geç tespit edilir.

• Her taahhüt temel bir test grubuna göre doğrulanır. Doğrulandıktan sonra, değişiklik bir kod incelemesinden sonra master hale getirilir (Gerrit)
• Temel birim testleri her 30 dakikada bir, süresi 10 dakikadan az sürer
• Entegrasyon testleri her 2 saatte bir, 1 saatte bir yapılır
• UI- / Webtests başarılı entegrasyon testlerinde çalışır, birkaç saat sürer

Sprint sırasında inşa istikrarından kimin sorumlu olduğuna bağlı olarak (sorumluluk sprint başına aktarılır), yapıyı tekrar dengeye getirmek için ara, geçici "kesinti durakları" olabilir.

Yani, istiyoruz:

1. Geliştirici ekiplerimiz, bir sprint boyunca değişiklikleri geliştirmek ve taahhüt etmek için
2. Bir derleme adımı başarısız olursa derleme sürecimiz, sonraki derleme sonuçlarının çok az anlamı olduğundan
3. Geliştiricilere zamanında kaliteli geri bildirim vermek için oluşturma sürecimiz

(2) verildiğinde, (1) ve (3) noktaları birbiriyle çelişiyor gibi görünmektedir. Herkes bununla nasıl başa çıkılacağı konusunda iyi bir uygulama var mı?

( Şu anda (2) noktasını gevşetiyoruz ve başarısız yapım adımlarında bile yapı sürekliliğine izin veriyoruz. Bunun henüz kalitemizi nasıl etkilediğine dair bir geri bildirimim yok )

Teşekkürler, Simon

Önce birkaç temel ilke: - Büyük değişiklikler her zaman VCS'nizdeki bir özellik dalında olmalıdır - Özellik dalları, birleştirme işleminden önce tüm testleri gövdeye geçirmelidir. Eklendi - Taahhütler her zaman inşa edilmelidir - Kırık bir yapı, taşıtın ve / veya ekibin geri kalanının derhal harekete geçmesini gerektirir . - Başarısız bir test, geriye kalan testleri ancak kritik bir testse iptal etmelidir .

Eğer bir ekip olarak, bu uygulamaları takip ederseniz ve uygularsanız, örneğin: "name & shame" derlemesini bozduysanız, derlemeyi bozabilecek herhangi bir taahhüt bir özellik dalında olacağından iyi gitmelisiniz. Yapıyı bozan diğer taahhütler derhal ele alınacak ve sonra aşağı test sonuçlarınızı alacaksınız.

Ayrıca , UI / Web testleri için sabah ilk işini bildiren bir gecede çalıştırılan en son "başarılı" yapının (mutlaka entegrasyon testlerinden geçen bir değil) otomatik testini ekleyebilirsiniz .

Scrum ile bir ilgisi yok. Yapınız ne olursa olsun sürekli kararlı olmalıdır.

Yerel bir yapı gerçekleştirmedikçe ve birim testlerini yerel olarak yapmadıkça (ve her ikisi de elbette geçmedikçe) kimse hiçbir şey kontrol etmemelidir. Yerel oluşturma ve test işleminiz değişikliklere duyarlı olmalıdır ve değişmemiş kod testlerini atlayabilir.

Derlemenin başarısız olmasına veya birim testinin başarısız olmasına neden olan bir şey tanıtan herkes herkese açık şekilde utanmalıdır . Yapı bozulursa derhal düzeltilmelidir.

Sorununuz testlerin yürütülmesi çok uzun sürüyor gibi görünüyor. Neyse ki, Moore yasası bize bu soruna bir çözüm sağladı. Bugün, ileri teknoloji sunucu işlemcilerin 10'dan fazla çekirdeği (ve 10'un üzerinde HyperThreads) kolayca olabilir. Tek bir bilgisayarda böyle birden fazla CPU olabilir.

Bu kadar uzun süren testlerim olsaydı, sorunu daha fazla donanımla çözerdim. Üst düzey bir sunucu satın alırdım ve testlerin tüm CPU çekirdeklerinden tam olarak yararlanabilmesi için testleri paralelleştirirdim. Testleriniz bugün tek iş parçacıklıysa, 10 çekirdekten ve 10 HyperThreds'den yararlanmanız, muhtemelen testlerin 15 kat daha hızlı çalışmasını sağlar. Tabii ki, bu da belleğin 15 katını kullandıkları anlamına gelir, bu nedenle bilgisayarın yeterli RAM'e sahip olması gerekir.

Böylece, birkaç saat 10-30 dakikaya dönüşecektir.

Yapının ne kadar zaman aldığını söylemediniz, ancak yapıyı paralelleştirmeye izin verme gibi standart oluşturma araçları. Birim testlerinizi paralel hale getirirseniz ve tipik geliştirici bilgisayarında 4 çekirdek ve 4 HyperThreads varsa, 10 dakikadan daha az birim testi 2 dakikadan daha az olur. Belki de herkesin taahhütte bulunmadan önce birim testlerini yapması gereken bir politika uygulayabilirsiniz?

Daha fazla sınamayı durdurma sınama hatası hakkında: bunu yapı sunucusunda yapma! Arıza hakkında mümkün olduğunca fazla bilgi istersiniz ve diğer testler önemli bir şey ortaya çıkarabilir. Tabii ki, yapının kendisi başarısız olursa, birim testleri çalıştıramazsınız. Geliştiricinin kendi makinesinde birim testleri çalıştırması durumunda, ilk hatada iptal etmek isteyebilirsiniz.

Scrum ile problemleriniz arasında herhangi bir bağlantı görmüyorum. Sorunlar herhangi bir geliştirme sürecinde gerçekten ortaya çıkabilir.

Daha fazla Jenkins kurulumuna sahip olmak ve geliştiricileri ayrı bir Jenkins örneğini kontrol ettirmek mümkün değil mi?

Buradaki en iyi çözüm, kodun ana dalda kontrol edilmeden ve ana Jenkins örneği tarafından derlenip test edilmeden önce tüm testleri geçmesini sağlamaktır. Kullanıcıların derlemeyi bozan kodu kontrol etmesine izin vermeyin.

Kodumu geliştirme dalına kontrol ediyorum, testleri geçip geçmediğine bakın ve bir çekme isteği oluşturun. Ama açıkçası, jenkinlerin bir özellik dalını çekmesini ve test etmesini isteyebilirsiniz.

Nokta (2) en acı verici nokta gibi görünüyor, bu yüzden buna odaklanacağım.

Projeyi birden fazla modüle bölmenin zamanı gelmiş olabilir.

https://en.wikipedia.org/wiki/Dependency_inversion_principle

A. Yüksek seviyeli modüller, düşük seviyeli modüllere bağlı olmamalıdır. Her ikisi de soyutlamalara bağlı olmalıdır.

B. Soyutlamalar detaylara bağlı olmamalıdır. Ayrıntılar soyutlamalara bağlı olmalıdır.

Bir modül oluşturulamazsa, diğer modüller bir arabirime bağlı olabileceği ve bu arabirimi oluşturan kod başarıyla oluşturulduğu sürece diğer modüller için derleme devam edebilir.

Bu, bir sonraki derleme gerçekleşmeden önce birden fazla bozuk modülü düzeltmek için zamanınız olması için diğer derleme hatalarının neler olabileceği hakkında geri bildirim verecektir.

Genel olarak, SOLID ilkeleri kütüphanelerle başa çıkmak ve sorunlar oluşturmak için tasarlanmıştır. Başka bir deyişle - bu ilkeler kümesi, karşılaştığınız sorunları çözmek için tasarlanmıştır.

Bir yan not olarak (juhist'in cevabına bakın), yapıyı ayrı modüllere bölmezseniz, yapıyı daha hızlı çalıştıramazsınız (paralelleştirme ile).

Bence takımınızda scrum'un temel ilkelerinden biri eksik: bitti, çalışan yazılım. Bir PBI, ekibinizin oluşturduğu Bitti Tanımı'nı geçene kadar tamamlanmış olarak işaretlenmemelidir. Bitti'nin tanımı her takım için farklıdır, ancak muhtemelen aşağıdakileri içerir:

• Kodun birim testleri var
• Otomatik bir yapının parçası olarak birim test kartı
• Kod ana ile birleştirildi (ve anlaşmazlıklar çözüldü)
• vb.

Yani, esasen, ekibinizin aslında yapılmayan şeyleri işaretlemesi . Bu kendi başına bir problem.

Bunun dışında, uygun sürüm kontrol yönetimine dayanır. Git'i kullanıyorsanız, tüm işler geliştiricinin yerel deposunda yapılır ve "tamamlanmadı" ve potansiyel olarak serbest bırakılmadığı sürece hiçbir şeyi uzaktan kumanda etmeye zorlamamalıdır. Eksik işler asla ana havuzunuza aktarılmamalıdır. Geliştiricinin daha uzun ömürlü bir özellik dalında çalışması gerekiyorsa ve işlerini kaybetmediklerinden emin olmak için uzaktan kumandaya itmek istiyorsa, bir çataldan çalışmalıdırlar ve daha sonra özelliği "tamamlandı" ve potansiyel olarak serbest bırakılabilir - daha önce değil.

TFVC için, her şey "uzaktan" gerçekleştiğinden biraz daha karmaşıktır. Bu, devs'nin hızlı bir düzeltme olmadığı sürece her zaman dallardan çalışması gerektiği anlamına gelir. Bununla birlikte, burada Git ile aynı kurallar geçerlidir: eksik yazılım taahhüt edilmez. Dönemi. Düzgün yönetilen sürüm kontrolünde, "ana" her zaman serbest bırakılabilir olmalıdır. Eğer "ana" olan bir taahhüt yapılmışsa, o zaman doğru yapmıyorsunuz.