Sürekli entegrasyon yaparken kod incelemeleri ne zaman yapılır?


33

Sürekli bir entegrasyon ortamına geçmeye çalışıyoruz ancak kod incelemelerinin ne zaman yapılacağından emin değiliz. Sürekli entegrasyon okuduklarımdan itibaren, kodları günde en çok defa kontrol etmeye çalışmalıyız. Sanırım, bu henüz tamamlanmamış özellikler için bile geçerli.

Öyleyse asıl soru, kod incelemelerini ne zaman yapacağız?

Kodu kontrol etmeden önce bunu yapamayız, çünkü bu durum günlük check-in işlemlerini yapamayacağımız süreci yavaşlatır, yalnız günde çoklu check-in işlemlerini bırakmaz.

Ayrıca, kontrol ettiğimiz kod yalnızca derlenirse ancak özellik tamamlanmadıysa, kod incelemesi yapmak o zaman anlamsızdır, çünkü çoğu kod incelemesi en iyi özellik tamamlandıktan sonra yapılır. Bu, bir özellik tamamlandığında kod incelemeleri yapmamız gerektiği, ancak incelenmeyen kodların depoya gireceği anlamına mı geliyor?


Checkin'lere / itmelere gelince, çoğu yerde tek bir önemli kural vardır: Yapıyı bozmayın! Yapmayacak bir şeyi kontrol etme. Bunun dışında çoğu yerde küçük ve sınırlı check-in yapmak istedim, ancak miktar hakkında hiçbir şey söylemedim.
Bazı programcı adam

Ancak kod incelemesi ne zaman, kontrol etmeden önce veya bu özelliğe ne zaman başladınız? Bu, check-in yapılmayan bir kodun olduğu ve inceleme sonrasında bulunan herhangi bir sorunu çözdüğünüz anlamına mı geliyor?

Değişir, ancak çoğu yer ana dallardan birine dahil edilmeden önce özel dallarda kod incelemesi yapmak istemektedir,
Bazı programcı ahbap

Yanıtlar:


12

IMO, ana hattı yayınlamadan önce kodu gözden geçirmelisiniz, böylece ana hat yalnızca en yüksek kalite koduna sahip olur.

OTOH, 'CI test otomasyonu üzerinde çalışmadıysa neden incelemeyi zahmete soktunuz?'), Belki de en iyisi, geliştiricilerin her birine CI sunucusunun kendileri için oluşturup test edeceği özel bir şube vermesidir. . Bu şekilde ilk önce oraya bağlıyorlar ve itiyorlar, sonra geçtikten sonra gözden geçiriliyor, sonra ana hatta birleşiyor (CI sunucusunda başka bir işlem yapacağı yer).

Gelecekteki özellikler için iskele kurulmasının yapıldığından veya en azından söz konusu gelecekteki özelliklerin uygulanmasını engelleyebilecek hiçbir şeyin bulunmadığından emin olmak için kesinlikle özellik tamamlamayan kodu gözden geçirmelisiniz.

Ayrıca, kod incelemelerinin yavaş veya senkronize olması gerekmediğine dikkat edin - gerrit veya inceleme tahtası gibi bir araç onları asenkron ve oldukça ağrısız hale getirebilir.

(Tam açıklama: Ben eskiden kod inceleme aracı olan Code Collaborator'ın yapımcıları olan SmartBear için çalışıyordum)


4
E-posta koduyla görüntüleme, kötü bir uygulama (hiç şüphesiz, daha iyi olsa da, şüphesiz) çünkü incelemenin ne zaman yapıldığını söylemek zor. Gerrit veya reviewboard gibi gerçek bir kod inceleme aracı edinin ve kullanın ve yamaları e-postayla göndermeyi bırakın :)
pjz

1
Yine de, DVCS'den bağımsız olarak bunun ideal bir işlem olduğunu sanmıyorum. Kod incelemesinin gerekliliklerinden biri yalnızca koda bakmak değil, aynı zamanda kodu çalıştırmak veya kodu otomatik olarak test etmek ve ne olduğunu da görmektir. Bunu sadece bir dizi farkla yapamazsın.
Ürdün

2
Otomatikleştirilmiş testler yapıldıktan sonra incelemelerin yapılması önerisi için +1.
William Payne

1
Ürdün: gerçek kod izleme araçları (gerrit, vb.) Farktan çok daha fazlasını sağlar - tüm içeriği okumanıza izin verin, böylece kod değişikliğinin gerçekte ne etkilediğini anlayabilirsiniz. İhtiyacınız olursa, evet, yamayı indirebilir ve oluşturabilirsiniz, ancak yine de her şey CI'den geçtiğinden, otomasyon tarafından yakalanabilecek hataların olacağı varsayılmaktadır, bu nedenle konsantrasyonun otomasyona ilişkin daha uzun süren bakım ve ileri durumlarda olduğu düşünülmektedir. geçici testler uygun olmayabilir.
pjz

1
CI'nin noktalarından biri erken ve sıklıkla ana hat ile senkronize edilmesi değil midir? Yaklaşımınız birçok dezavantajı olan senkronizasyonu geciktirecektir.
Jacob R

11

Çift programlamanın ayarlanması?

İşlemin uzatılması veya başka bir adım atılmadan kodun tümü yazıldığı için gözden geçirilir.


7

Sürekli teslimat yazarının özü:

Jez Humble olarak yazıyor:

Şu anda bu konuda bir blog yazısı yazıyorum. Kısa cevap şudur:

  • Kodu incelemenin en iyi yolu çift programlamadır
  • Örgün bir inceleme sürecinde, örneğin ayrı bir şube oluşturarak ana hattına birleştirme yapmak kötü bir fikirdir. Bu sürekli entegrasyonu engeller (kötü değişiklik riskini azaltmanın en iyi yolu, ki bu gerçekten elde etmeyi hedeflediğiniz şeydir).
  • Bence Gerrit iyi bir araç, ancak check-in işleminden sonra kullanılması gerekiyor (aslında bu şekilde tasarlandı). Üst düzey geliştiricilerin işinin bir kısmı tüm check-in'leri gözden geçirmektir. Örneğin bir yayına abone olabilirler.

Özetlemek gerekirse: kod incelemesi iyidir. Çok iyi, çift programlama ve gözden geçirme komisyonları aracılığıyla sürekli yapıyor olmalıyız. Üst düzey bir dev kötü bir iş bulursa, sorunu çözmelerine yardımcı olmak için işini yapan kişiyle eşleşmelidir.

Resmi bir incelemede ana hatlara birleştirme yapmak kötüdür ve bunu yapmak için dallar oluşturmak çok kötüdür, aynı nedenle dallar kötüdür.

Teşekkürler,

Jez.

Orijinal bağlantı şudur: https://groups.google.com/forum/#!msg/continuousdelivery/LIJ1nva9Oas/y3sAaMtibGAJ


5

Bunu yapmanın en iyi yolu olup olmadığını bilmiyorum ... ama nasıl yaptığımızı açıklayacağım. Bir veya daha fazla geliştirici, belirli bir dalda çalışır ve aksi halde olmayacak birleştirme zamanını boşa harcamamak için kodlarını olabildiğince sık işler. Sadece kod hazır olduğunda başa kabul edilir. Şimdi bu komisyonlar ve şube / kafa şeyleri için.

Kod incelemesine gelince, sürekli bir entegrasyon aracı olarak Sonar'ı kullanıyoruz (ve Sonar ile etkileşimde bulunmak için Maven / Jenkins), her sabah yeni test sonuçları, kod kapsamı ve otomatik kod incelemesi sağlamak için (her gece çalışır) geliştiriciler sorunlarını / kod kokularını düzeltmek için her sabah en fazla bir saat harcayabilir. Her geliştirici yazdığı özellik için sorumluluk alır (gurur duyuyor!). Şimdi, bu potansiyel teknik / mimari problemleri bulmak için harika olan otomatik kod incelemesidir, ancak daha önemli olan, bu yeni uygulanan özelliklerin işletmenin ne yapmak istediğini doğru bir şekilde yapıp yapmadığını test etmektir.

Bunun için iki şey var: entegrasyon testleri ve eş kod incelemesi. Entegrasyon testleri, yeni kodun mevcut kodu bozmadığından emin olmanıza yardımcı olur. Eş kod incelemesine gelince, cuma öğleden sonraları yapıyoruz, bu da bunu yapmak için biraz daha rahat bir zamandır :-) Her geliştirici, üzerinde çalışmadığı bir şubeye atanır, önce yeni özellik, ardından ne yapıldığını kontrol eder. En önemli işi, gereksinimler göz önüne alındığında , yeni kodun beklendiği gibi çalıştığından , kendi "kurallarımızı" ihlal etmediğinden (bunun için bu nesneyi kullanıp kullanmadığına) emin olmaktır. kolay uzatma

Dolayısıyla, biri otomatik diğeri otomatik "insan" olmak üzere iki kod incelememiz var ve gözden geçirilmemiş kodun HEAD şubesine işlenmesini önlemeye çalışıyoruz. Şimdi ... Bazen çeşitli nedenlerden dolayı oluyor, mükemmel olmaktan çok uzaktayız, ancak kalite ve maliyet arasında adil bir denge kurmaya çalışıyoruz (zaman!)

@pjz de iyi bir cevap veriyor ve kod inceleme araçlarından bahsediyor. Ben hiç kullanmamıştım, bu yüzden bu konuda hiçbir şey söyleyemem ... daha önce JIRA kullandığımızdan beri Crucible ile çalışmaya başlamış olmama rağmen .


İncelemelerin belirli bir zaman / gün için zamanlanması gerektiği ilginç bir fikir ...
William Payne

@WilliamPayne teşekkür ederim. Bizim için çalışan bir başka şey de kod inceleme toplantılarını planlamak, bu nedenle "meşgul" olduğumuz takvimde açıkça görülüyor. İnsanları
uyarmamıza

4

Sanırım yardımcı olacak ana konsept "Evreleme" alanı.

Evet, kırılan kodu kontrol etmek istemezsiniz. Ancak aynı zamanda kodları sık sık kontrol etmelisiniz. Bu mükemmellik anlamına mı geliyor? ;) Hayır. Sadece çoklu alanlar ve git gibi bir DVCS kullanın.
Bu şekilde değişiklikler (yerel olarak) yapılır ve testler geçinceye kadar test edip, geliştikçe bunları sıkça yaparsınız. Ardından, kod incelemesi için bir hazırlama alanına bastırın.

Daha sonra, Staging (Tarayıcı) ve tarayıcı testleri ve kullanıcı testleri gibi diğer QA çabalarına gitmelisiniz. Sonunda bir hacim test alanına gidebilir, daha sonra üretim yapabilirsiniz.

Bunun içinde, ana dalda çalışan herkes veya tüm çabalar için bireysel şubeler kullanan iş akışları da vardır.

Sürekli entegrasyonun kendisi de çoklu seviyelerde olabilir. Geliştiriciler makinesinde 'testler geçinceye kadar' yerel olabilir ve ayrıca kodun kendilerine gittiği zaman evreleme ve qa alanlarında da olabilir.



2

Depolarımız için git akışını kullanıyoruz ve kod dalımızı geliştirme dalına dahil olmak üzere yapıyoruz.

Geliştirilen her şey eksiksiz, konuşlandırılabilir ve kod gözden geçirilir.

Ayrıca geliştirme ve ana şubelerimiz için CI ayarladık.


2

Ben gerçekten-gerçekten-gerçekten bunu yapmak için bir DVCS'ye (örneğin, mercurial, git) ihtiyacınız olacağını düşünüyorum. Bir CVCS ile bir şubeye ihtiyaç duyarsınız ve ne tanrınız olursa olsun birleşme cehennemi yoktur.

Bir DVCS kullanıyorsanız entegrasyon işlemini, kodun CI sunucusuna ulaşmadan önce gözden geçirmesini sağlayacak şekilde sıralayabilirsiniz. Bir DVCS'niz yoksa, kod her gözden geçiricinin değişikliklerini göndermeden önce her geliştiricinin makinesindeki kodu incelemediği sürece, kod gözden geçirilmeden önce CI sunucunuza ulaşacaktır.

Bunu yapmanın ilk yolu, özellikle kişisel depoları (örneğin bitbucket, github, rhodecode) yayınlamaya yardımcı olacak depo yönetim yazılımınız yoksa, hiyerarşik entegrasyon rollerine sahip olmaktır. Aşağıdaki diyagramlarda, teğmenlerin geliştiricilerin çalışmalarını gözden geçirmesini ve teğmenlerin çalışmayı nasıl birleştirdiğini inceleyen diktatöre sahip olmanız gerekebilir.

görüntü tanımını buraya girin

Depo yönetimi yazılımınız varsa, bunu yapmanın başka bir yolu da aşağıdaki gibi bir iş akışı kullanmaktır:

görüntü tanımını buraya girin

Havuz yönetimi yazılımı, genellikle depolarda aktivite olduğu zaman (örn. E-posta, RSS) ve çekme isteklerine izin verdiğinde bildirim yayınlamaya yardımcı olur . Kod incelemesi, çekme istekleri sırasında organik olarak gerçekleşebilir, çünkü çekme istekleri tipik olarak kodları entegre etmek için kişilerin konuşmalarına katılmasını sağlar. Al bu kamu çekme isteğini örnek olarak. Entegrasyon Yöneticisi aslında kod ihtiyaçları düzeltilmesi eğer kod mübarek deposundan (aka "Merkez depo") ulaşmasına izin olamaz.

En önemlisi, bir DVCS ile hala merkezi bir iş akışını destekleyebilirsiniz, istemiyorsanız başka bir harika harika iş akışınız olması gerekmez ... ancak bir DVCS ile merkezi bir geliştirme deposunu CI'den ayırabilirsiniz. Sunucuya ve bir kod inceleme oturumu yapıldıktan sonra bir başkasına dev repo'dan CI repo'ya değişiklikleri itme yetkisi verin .

Not: Resimler için kredi git-scm.com adresine gidin.


1
Github'daki millet, kod incelemeleri yapma isteklerini kullanıyor ve Scott Chacon , Zach Holman ve diğerlerine göre iyi çalışıyor gibi görünüyor .
Spoike

1

Neden birden fazla havuz yok? Biri "günlük" iş, sürekli bir entegrasyon sunucusu kullanmak, güzel sıkı geri besleme döngüsünü elde etmek için tüm birim testlerini ve entegrasyon testlerini çalıştırmak, diğeri de taahhütlerin daha az sıklıkta olmak zorunda olduğu ancak inceleme yapması gereken "kararlı" iş için.

Değişikliklerin sistem içinde ilerledikçe izlediği yola bağlı olarak, bu biraz karmaşık bir çözüm olabilir ve Git veya Mercurial Queue gibi araçlar kullanılırken en iyi şekilde sonuçlanabilir. ancak birçok kuruluş benzer bir şey yapar.


1

Bu, bir özellik tamamlandığında kod incelemeleri yapmamız gerektiği, ancak incelenmeyen kodların depoya gireceği anlamına mı geliyor?

Çok yukarıda sürekli entegrasyonu kullanan en az üç projede görmüştüm ve hatırladığım kadarıyla cazibeye benziyordu. Bu uygulama, işlem sonrası kod incelemeleri olarak bilinir - ayrıntılarla ilgileniyorsanız, bu terim için web'de arama yapın.

  • Öte yandan, CI ile yapılan ön değerlendirme kodunun "evlenmeye" çalıştığı projede bulunduğum tek vaka oldukça acı verici çıktı. İşler% 100 sorunsuz geçtiğinde, sorun yoktu - ama sık sık yapılan kesintiler bile (ana ve yedek gözden geçirenlerin birkaç saat boyunca kullanılamadığı zamanlar gibi) fark edilebilir bir stres yarattı. Ayrıca takım moralinin biraz acı çektiğini de fark ettim - biraz fazla çatışma vardı.

-2

Öncelikle “sürekli entegrasyon” kavramını netleştirmeliyiz. Geleneksel gelişen yöntemlerde, sürekli entegrasyon, kaynak kod depomuzu her gün bütünleştirip inşa edebileceğimiz anlamına gelir; Kod incelemeleri daima Kodlama ve Ünite testi süresi arasındadır. Şubeyle birleştirme kodunun hatasız bir şekilde derlenebileceğini garanti etmeliyiz. Nadiren, özelliğin bölümlerinin birleştiği durumu vardır, çünkü arabirimin tutarlılığını ele almak ve hataları derlemek zordur.

Sürekli Entegrasyon, Aşırı Programlama sürecinde popülerdir. Test odaklı geliştirme, kod entegrasyon sürecinin gerçek parçası olan Pair programlamasını ekleyerek sürekli entegrasyonu kolaylaştırır. Extreme Programming'in kendisi sürekli bir kod inceleme ve entegrasyon sürecidir. Kod incelemeleri her yerde var.

Bazı açık kaynaklı topluluklarda, kod incelemeleri, şubeye birleştirilmiş koddan hemen önce yürütülür. Kod incelemesini yapmak ve kodun ana şubeyle birleşip birleşmeyeceğine karar vermek her zaman bu ekipteki en deneyimli kişilerdir. Bu şekilde, Sürekli Entegrasyon süresi biraz daha uzundur ancak kod kalitesi biraz daha iyidir.

Soruya dön. Kod incelemelerinin ne zaman yapılacağına ilişkin standart bir cevabı yoktur ve orijinal gelişim sürecinize ve sürekli entegrasyonunuzun gerçek uygulamasına bağlıdır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.