Scrum yöntemi ile bir yazılım geliştirme şirketinde sürekli entegrasyon iş akışının nasıl daha iyi uyduğunu anlamak için bir yaklaşım üzerinde çalışıyorum.
Ben böyle bir şey düşünüyorum:
Güzel bir iş akışı olur mu?
Scrum ve sürekli entegrasyon ile yazılım geliştirme için iyi iş akışı
Yanıtlar:
Oradaki yollardan birisin, ama diyagramını biraz genişletirdim:
Temel olarak (sürüm kontrolünüz izin verirse, yani hg / git üzerindeyseniz), her geliştirici / geliştirici çiftinin üzerinde çalıştıkları tek bir kullanıcı hikayesi içeren kendi "kişisel" dalına sahip olmasını istersiniz. Özelliği tamamladıklarında, merkezi bir dal olan "Serbest Bırakma" dalına girmeleri gerekir. Bu noktada, geliştiricinin üzerinde çalışmaları gereken bir sonraki şey için yeni bir dal almasını istiyorsunuz. Orijinal özellik dalı olduğu gibi bırakılmalıdır, bu nedenle üzerinde yapılması gereken değişiklikler tek başına yapılabilir (bu her zaman geçerli değildir, ancak iyi bir başlangıç noktasıdır). Bir geliştirici eski bir özellik dalında çalışmaya dönmeden önce, garip birleştirme sorunlarından kaçınmak için en son yayın dalını çekmelisiniz.
Bu noktada, "Sürüm" dalı şeklinde olası bir sürüm adayımız var ve CI sürecimizi yürütmeye hazırız (bu dalda, açıkça her geliştirici dalında yapabilirsiniz, ancak bu büyük dev takımlarda oldukça nadir CI sunucusunu kümelendirir). Bu sabit bir süreç olabilir (ideal olarak durum budur, "Bırak" dalı her değiştiğinde CI çalışmalıdır) veya her gece olabilir.
Bu noktada, bir yapı çalıştırmak ve CI sunucusundan uygun bir yapı artefaktı elde etmek istersiniz (yani, uygun bir şekilde dağıtabileceğiniz bir şey). Dinamik bir dil kullanıyorsanız bu adımı atlayabilirsiniz! Oluşturulduktan sonra, sistemdeki tüm otomatik testlerin temelini oluşturdukları için Birim Testlerinizi çalıştırmak isteyeceksiniz; hızlı olmaları muhtemeldir (CI'nın tüm amacı geliştirme ve test arasındaki geri besleme döngüsünü kısaltmak olduğu için iyidir) ve bir konuşlandırmaya ihtiyaçları yoktur. Geçerlerse, uygulamanızı otomatik olarak bir test sunucusuna dağıtmak (mümkünse) ve mevcut tüm entegrasyon testlerini çalıştırmak isteyeceksiniz. Entegrasyon testleri, otomatik kullanıcı arayüzü testleri, BDD testleri veya Birim Testi çerçevesi (örn. "Birim") kullanılarak standart entegrasyon testleri olabilir.
Bu noktada, yapının uygulanabilir olup olmadığı konusunda oldukça kapsamlı bir göstergeye sahip olmalısınız. Normalde bir "Release" şubesiyle ayarlayacağım son adım, release adayını otomatik olarak bir test sunucusuna dağıtmasını sağlamaktır, böylece KG departmanınız manuel duman testleri yapabilir (bu genellikle check-in yerine her gece yapılır. bir test döngüsünü karıştırmamak için). Bu, yapının canlı bir sürüm için gerçekten uygun olup olmadığına dair hızlı bir insan göstergesi verir, çünkü test paketiniz kapsamlı değilse daha az şeyleri kaçırmak oldukça kolaydır ve% 100 test kapsamı ile bile yapabileceğiniz bir şeyi kaçırmak kolaydır 't otomatik olarak test etmemelidir (yanlış hizalanmış görüntü veya yazım hatası gibi).
Bu, gerçekten, Sürekli Entegrasyon ve Sürekli Dağıtımın bir kombinasyonudur, ancak Agile'deki odağın birinci sınıf bir süreç olarak yalın kodlama ve otomatik testler üzerinde olması göz önüne alındığında, mümkün olduğunca kapsamlı bir yaklaşım elde etmek istersiniz.
Belirttiğim süreç ideal bir senaryo, bunun bir kısmını terk etmenizin birçok nedeni var (örneğin, geliştirici dalları SVN'de mümkün değil), ancak mümkün olduğunca çoğunu hedeflemek istiyorsunuz .
Scrum sprint döngüsünün buna nasıl uyduğu konusunda ideal olarak, bültenlerinizin mümkün olduğunca sık gerçekleşmesini ve bir özelliğin (ve bir bütün olarak derlenmesinin) hızlı bir geri bildirim almak için sprint'in sonuna kadar bırakmasını istemezsiniz. ) üretime geçiş için uygulanabilirdir, geri bildirim döngünüzü Ürün Sahibinize kısaltmak için önemli bir tekniktir.
1
Söylediklerinizin çoğuna katılıyorum, ancak (şahsen) mümkün olduğunca insanları aynı branşta teşvik etmeye çalışacağım.
—
William Payne
@WilliamPayne Bir DVCS kullanıyorsanız, insanlar her zaman klonlama yaptığınızda "dallandığınızdan" asla aynı dalda değildir (kelimenin tam anlamıyla aynı makinede çalışmadığı sürece). Standart bir VCS'de sahip olacağınız şeye eşdeğer "Şube", özellik başına sahip olacağınız birleştirme şubesidir (bu nedenle Dev B ve Dev C, Şube C'nin dalları üzerinde çalışabilir, sonra yapıldığı gibi Şube C'yi kontrol edebilir. ikisi de C özelliği üzerinde çalışıyordu). Daha fazla şubeye sahip olmanın faydaları, birleştirme sorunlarını düzeltmek için daha az zaman harcıyor, çünkü HG / Git'te birleştirmek neredeyse tamamen ağrısız, ancak bir itme / çekme yarışı değil.
—
Ed James
Bunun bir alev savaşına dönüşme riski altında, birleşme çatışmalarından kaynaklanan sorunların sıklıkla abartıldığına inanıyorum (var olduklarını kabul etsem de). Ayrıca, DVCS araçlarına geçişin (diğer hususlar tarafından garanti edilmesine rağmen) yalnızca birleşme çatışmalarından kaçınma temelinde gerekçelendirilmemesi gerektiğine inanıyorum - Açık / topluluk geliştirme çabası dışında herhangi bir şeyde, geliştirme ekibi. Bir DVCS'ye geçmek, ekip iletişiminde yalnızca daha derin ve daha önemli bir sorunu maskeler.
—
William Payne
Hala geliştiricilerin çalışırken taahhüt ettikleri "günlük" (gövde) bir repo gerekliliğine inanıyorum. Sonuçta, sürekli entegrasyon işinizi sürekli entegre etmekle ilgilidir. Benim için dallanma, birleşme çatışması tehlikesi nedeniyle değil, geliştiricilerin diğerinin ne yaptığını izlememesi ve silolarda çalışmaya başlaması nedeniyle son çare olarak yapılan bir şeydir. Bu, kullandığımız araçların sınırlamaları değil, ekip çalışması, iletişim ve insan faktörleri ile ilgilidir. Sürekli entegrasyon yapmak için, dallamanın desteklemediği sürekli iletişime ihtiyacınız vardır.
—
William Payne
@WilliamPayne DVCS ve VCS'nin göreceli değerlerini sizinle tartışmayacağım (en azından yorumlar yoluyla), doğru iş akışını alırsanız DVCS kullanmanın önemli faydaları olurken, daha geleneksel bir iş akışı ile VCS sterlin bir iş yapacak (benim tecrübelerime göre). Bununla birlikte, size söyleyeceğim, bir DVCS'ye geçiş yaptığımdan beri ekibim çok daha hızlı geliştirme geri dönüşü ve daha sağlam dağıtımlar yaşadı. Birçok insanın bugüne kadar deneyimlediği proje sonu birleştirme cehennemi, geliştirme sürecimizden neredeyse tamamen kaldırıldı.
—
Ed James
Kavramsal olarak evet. Bir diyagram, aşağıdaki gibi çok önemli noktaları yakalamaz:
- birim testi
- artan taahhütler
- evreleme çoğu kez konuşlandırılır, üretim genellikle yapmaz.
Diyagram için daha geniş bir sistem çizmek isteyebilirsiniz. Aşağıdaki öğeleri eklemeyi düşünürdüm:
Geliştiricilere beslenen sisteme girdilerinizi gösterin. Onlara gereksinimler, hata düzeltmeleri, hikayeler veya başka bir şey deyin. Ancak şu anda iş akışınız izleyicinin bu girdilerin nasıl eklendiğini bildiğini varsayar.
İş akışı boyunca kontrol noktalarını gösterin. Bagaj / ana / serbest bırakma dalı / vb. Bir değişikliğe izin verildiğinde kim / ne karar verir? BDT üzerine hangi kodlar / projeler inşa ediliyor? Yapının kırılıp kırılmadığını görmek için bir kontrol noktası var mı? CIS'ten sahneleme / üretime kimler serbest kalır?
Kontrol noktaları ile ilgili olarak, dallanma metodolojinizin ne olduğunu ve bu iş akışına nasıl uyduğunu tanımlamaktır.
Test ekibi var mı? Ne zaman dahil olurlar veya bilgilendirilirler? BDT üzerinde otomatik test yapılıyor mu? Kırılmalar sisteme nasıl geri besleniyor?
Bu iş akışını, karar noktaları ve girdileri olan geleneksel bir akış şemasına nasıl eşleyeceğinizi düşünün. İş akışınızı yeterince tanımlamak için gereken tüm üst düzey temas noktalarını yakaladınız mı?
Asıl sorunuz bir karşılaştırma yapmaya çalışıyor, sanırım, ancak hangi yönleri karşılaştırmaya çalıştığınızdan emin değilim. Sürekli Entegrasyonun diğer SDLC modelleri gibi karar noktaları vardır, ancak süreçte farklı noktalarda olabilirler.
"Geliştirme Otomasyonu" terimini tüm otomatik derleme, dokümantasyon oluşturma, test, performans ölçümü ve dağıtım faaliyetlerini kapsayacak şekilde kullanıyorum.
Dolayısıyla bir "geliştirme otomasyon sunucusu", sürekli bir entegrasyon sunucusundan benzer, ancak biraz daha geniş bir havale sahiptir.
CI sunucusunda ek yapılandırma gerektirmeden hem özel şubelerin hem de merkezi geliştirme gövdesinin otomatikleştirilmesine izin veren işlem sonrası kancalarla yönlendirilen geliştirme otomasyon komut dosyalarını kullanmayı tercih ederim. (Bu, farkında olduğum kullanıma hazır CI sunucusu GUI'lerinin çoğunun kullanılmasını engeller).
Taahhüt sonrası komut dosyası, şubenin içeriğine göre hangi otomasyon etkinliklerinin yürütüleceğini belirler; daldaki sabit bir konumdaki taahhüt sonrası yapılandırma dosyasını okuyarak veya depodaki dalın yolunun bir bileşeni olarak belirli bir sözcüğü algılayarak (/ auto / kullanıyorum) (Svn ile).
(Svn ile kurulum Hg'den daha kolaydır).
Bu yaklaşım, geliştirme ekibinin iş akışlarını nasıl düzenledikleri konusunda daha esnek olmalarını sağlayarak CI'nin asgari (sıfıra yakın) yönetim yükü olan dallardaki gelişimi desteklemesine olanak tanır.
Asp.net üzerinde yararlı bulabileceğiniz sürekli entegrasyon ile ilgili iyi bir dizi yayın var, yaptıktan sonra nasıl göründüğünüze uyan biraz zemin ve iş akışlarını kapsıyor.
Diyagramınız, CI sunucusu (birim testi, kod kapsamı ve diğer metrikler, entegrasyon testi veya gece sürümleri) tarafından yapılan çalışmalardan bahsetmiyor, ancak bunların hepsinin "Sürekli Entegrasyon sunucusu" aşamasında olduğunu varsayıyorum. CI kutusunun neden merkezi depoya geri döneceğinden emin değilim? Açıkçası kodu alması gerekiyor ama neden geri göndermesi gerekiyor?
CI, çeşitli disiplinler tarafından önerilen uygulamalardan biridir, scrum (veya XP) için benzersiz değildir, ancak aslında şelale gibi çevik olmayan herhangi bir akış için faydaların mevcut olduğunu söyleyebilirim (belki ıslak çevik?) . Benim için en önemli faydaları sıkı geri bildirim döngüsüdür, az önce taahhüt ettiğiniz kodun kod tabanının geri kalanıyla çalışıp çalışmadığını oldukça hızlı bir şekilde bilirsiniz. Sprint'lerde çalışıyorsanız ve günlük stand-up'larınıza sahipseniz, CI sunucusunda inşa edilen son gecelerin durumlarına veya metriklerine başvurabilmek kesinlikle bir artıdır ve insanlara odaklanmanıza yardımcı olur. Ürün sahibiniz derlemenin durumunu görebiliyorsa - derleme projelerinizin durumunu gösteren paylaşılan bir alanda büyük bir monitör - o geri bildirim döngüsünü gerçekten sıkılaştırdınız. Geliştirme ekibiniz sık sık (günde bir kereden fazla ve ideal olarak saatte bir kereden fazla) işliyorsa, çözülmesi uzun süren bir entegrasyon sorunuyla karşılaşma şansınız azalır, ancak bunu yaparlarsa hepsi ve ihtiyacınız olan her şeyi alabilirsin, örneğin kırık yapı ile uğraşmak için herkes durur. Pratikte, sık sık entegre olup olmadığınızı anlamak için birkaç dakikadan fazla süren başarısız yapılara çarpmayacaksınız.
Kaynaklarınıza / ağınıza bağlı olarak farklı uç sunucular eklemeyi düşünebilirsiniz. Repo'ya bağlılık ile tetiklenen bir CI derlememiz var ve tüm testlerini derleyip geçirdiğini varsayarak geliştirme sunucusuna dağıtılarak geliştiricilerin güzel oynatıldığından emin olabilirsiniz (burada selenyum veya diğer UI testlerini dahil edebilirsiniz? ). Her taahhüt kararlı bir yapı değildir, bu nedenle bir hazırlama sunucusuna bir yapıyı tetiklemek için, inşa etmek ve konuşlandırmak istediğimiz revizyonu (civa kullanıyoruz) etiketlememiz gerekir, yine tüm bunlar otomatiktir ve sadece belirli bir işlemle taahhüt ederek tetiklenir etiket. Üretime gitmek manuel bir süreçtir; kullanmak istediğiniz düzeltmeyi / yapıyı bilmek bir numarayı zorlamak kadar basit bırakabilirsiniz, ancak revizyonu uygun şekilde etiketleyecekseniz, CI sunucusu doğru sürümü satın alabilir ve gerekli olanı yapabilir. Değişiklikleri üretim sunucu (lar) ıyla senkronize etmek veya paketlemek ve bir yöneticinin manuel olarak dağıtması için bir yere hazır hale getirmek için MS Deploy kullanıyor olabilirsiniz ... bu konuda ne kadar rahat olduğunuza bağlıdır.
Bir sürüm yukarı çıkmanın yanı sıra, başarısızlıkla nasıl başa çıkabileceğinizi ve bir sürümden nasıl aşağı inebileceğinizi de düşünmelisiniz. Umarım gerçekleşmez, ancak sunucularınızda bazı değişiklikler olabilir, bu da UAT'de çalışanların üretimde çalışmadığı anlamına gelir, bu nedenle onaylı sürümünüzü yayınlarsınız ve başarısız olur ... her zaman tanımladığınız yaklaşımı hata, biraz kod ekleyin, kesinleştirin, test edin, düzeltmek için üretime konuşlandırın ... ya da üretime yönelik otomatik sürümünüzün etrafına başka testler sarabilirsiniz ve bu başarısız olursa, otomatik olarak geri döner.
CruiseControl.Net yapıları yapılandırmak için xml kullanır, TeamCity sihirbazları kullanır, eğer takımınızdaki uzmanlardan kaçınmayı hedefliyorsanız, xml yapılandırmalarının karmaşıklığı akılda tutulması gereken başka bir şey olabilir.
Birincisi, bir uyarı: Scrum oldukça titiz bir metodolojidir. Scrum veya Scrum benzeri yaklaşımları kullanmaya çalışan birkaç kuruluş için çalıştım, ancak hiçbiri tam disiplini bütünüyle kullanmaya yaklaşmadı. Deneyimlerime göre ben bir Çevik meraklıyım, ama (isteksiz) Scrum şüpheciyim.
Anladığım kadarıyla Scrum ve diğer Çevik yöntemlerin iki ana hedefi var:
- Birincisi, risklerin yönetimi ve devam eden risklerin keşfi için açık bir mekanizma sağlamaktır.
- İkincisi, paydaş iletişimi, ihtiyaç keşfi ve ihtiyaç yönetimi için yapılandırılmış bir mekanizma sağlamaktır.
İlk (risk yönetimi) hedefi yinelemeli gelişim yoluyla elde edilir; hatalar yapmak ve dersleri hızlı bir şekilde öğrenmek, ekibin zaten çantada bulunan düşük riskli "sade" bir çözümle riski azaltmak ve düşük riskli bir çözüme doğru ilerlemek için anlayış ve entelektüel yetenek geliştirmesine olanak tanır.
Sürekli entegrasyon dahil olmak üzere Geliştirme Otomasyonu, bu yaklaşımın başarısındaki en kritik faktördür. Risk keşfi ve Ders öğrenme hızlı, sürtünmesiz ve sosyal faktörleri şaşırtmamalıdır. (İnsanlar, başka bir insandan ziyade yanlış olduklarını söyleyen bir makine olduğunda ÇOK daha hızlı öğrenirler - egolar sadece öğrenme yoluna girer).
Muhtemelen anlayacağınız gibi - ben de test odaklı geliştirmenin hayranıyım. :-)
İkinci hedefin geliştirme otomasyonu ile ve İnsan Faktörleri ile ilgisi daha azdır. Uygulanması daha zordur, çünkü formalitenin gerekliliğini görmesi olası olmayan, işin ön ucundan katılım gerektirir.
Geliştirme Otomasyonunun burada rolü olabilir, çünkü otomatik olarak oluşturulan dokümantasyon ve ilerleme raporları, geliştirme ekibinin dışındaki paydaşları sürekli olarak sürekli olarak güncel tutmak için kullanılabilir ve yapı durumunu gösteren ve başarılı / başarısız test paketlerini gösteren bilgi radyatörleri ilerlemeyi iletmek için kullanılabilir özellik geliştirme konusunda Scrum iletişim sürecinin benimsenmesine (umarım) yardımcı olmak.
Özet olarak:
Sorunuzu göstermek için kullandığınız diyagram sürecin sadece bir kısmını yakalar. Çevik / scrum ve CI okumak istiyorsanız, sürecin daha geniş sosyal ve insan faktörlerini göz önünde bulundurmanın önemli olduğunu iddia ediyorum.
Her zaman yaptığım davulu vurarak bitirmeliyim. Gerçek dünyadaki bir projede çevik bir süreç uygulamaya çalışıyorsanız, başarı şansınızın en iyi öngörücüsü konuşlandırılan otomasyon seviyesidir; sürtünmeyi azaltır, hızı arttırır ve başarıya giden yolu açar.