Şube kalite düzeyinde herhangi bir gerilemeyi garanti etmeyen bir CI aracı var mı?

Geleneksel olarak CI sistemleri , bir entegrasyon dalındaki kalite seviyelerinin izlenmesini , değişikliklerin zaten yapıldığı kod tabanında QA doğrulamaları gerçekleştirerek, gerilemeleri izleyerek ve insan müdahalesi için bildirim göndererek gerçekleştirir.

Ancak bu gerilemeler tespit edildiğinde, şube en azından ilgili KG doğrulaması başladığından beri belada olmuştur ve tüm suçlular belirlenene kadar bu durumda kalır (hatta daha da kötüleşir!), Onarımlar yapılır ve yeni bir KG doğrulaması şube kalite düzeyinin geri yüklendiğini onaylar. Şube, tüm bu süre boyunca normal gelişim için bloke edilmiş kabul edilebilir.

Bu tür gerilemelerin gerçekleşmesini gerçekten önleyebilen , yalnızca ön taahhütlü KG doğrulamaları gerçekleştirebilecek ve yalnızca ilgili taahhütlerle güncellenen kod tabanı da ön taahhütlü KG doğrulamaları geçecekse işlemlere izin verecek bir CI aracı var mı , böylece minimum garanti şube kalite seviyesi?

Güncelleme: varsayım, ilgili regresyonları tespit edebilmek için uygun kapsama sahip uygun otomatik KG doğrulamalarının, CI araçları tarafından çağrılması için mevcut olduğudur.

Anlayabildiğim kadarıyla, yapıyı bozan taahhütleri reddedecek bir araç arıyorsunuz - bir CI aracı muhtemelen kodunuzu gerçekten düzelterek regresyonları önleyemez, ancak kötü kod eklemenizi durdurabilir depoya.

Atlassian'ın Git kancalarının birkaç ilginç uygulaması var :

Sunucu tarafı ön alma kancaları, sürekli entegrasyon için özellikle güçlü bir iltifattır, çünkü kod, elit ninja koruyucuları gibi kötü koşullardan koruyan belirli koşulları karşılamadığı sürece geliştiricilerin kodu master'a itmesini önleyebilirler.

Git'i kullanıyorsanız, kancalar çok güçlüdür (ve SVN , Mercurial ve diğer sürüm kontrol sistemleri için benzer kancalar vardır ) ve bunları ön işleme kontrolleri yapmak için kullanmanın yararlı olduğunu düşünebilirsiniz.

Git belgelerinde , bu kullanım senaryosuna kolayca uyarlanabilecek belirli kriterleri karşılamayan itmeleri reddetmek için bir kanca oluşturma sayfası vardır .

Bununla birlikte, birçok insan taahhütlerin reddedilmesinin bir dalda kötü bir fikir olduğunu iddia edecektir - featureyapı bir nedenle herhangi bir nedenle bozulduğunda, hatayı düzeltmek yerine CI sisteminize karşı savaşmak için zaman harcayacaksınız.

On masterbunu hep oluşturur sağlamak istiyoruz çünkü dalı, bu kırık birleştirmeleri reddetmek mantıklı olabilir. Bir İçin featuredalı, sen olacaktır kaçınılmaz şeyleri kırmak ve kod üretime gitmiyor çünkü artık , aslında senin tamamen taahhüt reddetmek daha Sadece seni uyarmak daha mantıklı.

Hiçbir araç, hiçbir regresyonu garanti edemez - bu, testlerinize onları çalıştıran araçtan çok daha fazla bağlıdır. Ancak, yakalanacak regresyonların entegrasyon dalına girmesini önlemeye yardımcı olabilirsiniz. Bunu ön işleme kancaları ile yapabilirsiniz, ancak çekme istekleri ile genellikle daha kolaydır (ki umarım zaten eş kodu incelemesi için kullanıyorsunuzdur).

Bir şube, yukarı akışıyla (PR'nin birleştiği yerde) güncelse ve testleri geçerse, birleştirme işleminden sonra yine de geçer; birleştirme işleminden sonra hedef dalın durumu birleştirme işleminden önce kaynak dalın durumuyla eşleşir.

Hem bir PR'daki kaynak dalın hedefle güncel olup olmadığını ve hem de geçen bir CI yapısına sahip olup olmadığını belirtmek genellikle (zor kullanılan araçlara bağlı olarak) zor değildir. Bunu, çekme isteğini birleştirmek için bir gereklilik olarak (ilke olarak ve / veya yazılımda zorunlu olarak) kullanabilirsiniz.

Reitveld ve Zuul gibi gerçek sürekli entegrasyon araçları (sadece sürekli testlerin aksine) yardımcı olabilir, ancak bunlar sadece yazdığınız testler ve yaptığınız kod incelemeleri kadar iyidir.

GitLAB'ı kullanın, yalnızca boru hattı başarılı olduğunda bir birleştirmeye izin vermek için proje ayarlarında ayarlayabilirsiniz, böylece gerçekten Sürekli Entegrasyona sahip olabilir, birleştirme onayları listesine KG'nizi ekleyerek ve Dinamik Ortamlar ile kalite güvenceniz olabilir. efendiyle birleşmeden önce.

ApartCI , regresyonları tam olarak önlemek için tasarlanmış bir CI sistemidir, böylece düz veya artan şube kalitesi seviyesini garanti eder. Hala beta sürümündedir.

Merkezi taahhüt öncesi doğrulamalarını, bir değişikliğin ancak en son şube kalite seviyesini karşılamak veya aşmak için, ondan önce yapılan tüm diğer değişikliklerle birlikte doğrulandıktan sonra yapılmasını sağlayacak şekilde düzenler.

Bu, genellikle paralel olarak yapılan geleneksel geliştirici güdümlü ön taahhüt doğrulamalarına kıyasla temel farktır ve bu da hiçbir zaman birlikte test edilmeyen müdahale değişikliklerinin neden olduğu gerilemelere yer açar.

Araç aynı zamanda kolayca ölçeklenecek şekilde tasarlanmıştır - gelen aday değişikliklerinin çok yüksek oranlarını sürdürebilir ve aynı entegrasyon dalında çalışan 100/1000 geliştiricileri destekleyebilir.

Feragatname: Aracın yazarı ve onu sunan şirketin kurucusu değilim. Reklam için özür dileriz.