Özellikler büyüdükçe bir problemle karşılaşmaya başlıyoruz, burada özellikler test için sahnelemeyi yapıyor, ancak her şey test edildiğinde ve onaylandığında yeni özellikler test için hazırlanıyor.

Bu, neredeyse hiç üretime itemeyeceğimiz bir ortam yaratıyor çünkü test edilmiş ve test edilmemiş özelliklerin bir kombinasyonuna sahibiz. Bunun ortak bir sorun olduğuna eminim, ama bizim için henüz iyi bir kaynak bulamadım.

Bazı Özellikler:

• BitBucket'te GIT
• Jenkins Azure'a komut dosyası dağıtımı için

Umduğum şey, özellikleri ortamlarda dolaşırken izole etmenin ve sadece üretmeye hazır olanları itmenin bir yoludur.

Burada birkaç probleminiz var gibi görünüyor:

1. Belirli bir sürümün özelliklerini belirleme

Bu bir proje yönetimi meselesi ve bir koordinasyon meselesidir. Will bu özellik aynı zamanda, daha önce yayımlanan veya bundan sonra edilecek diğer özelliği? Sürümler bir seferde bir özellik olmak istiyorsa bunu tanımlayın. Özellikler sürümler halinde gruplanacaksa, gruplamaların ne olduğunu anlayın ve geliştiriciler ve karar vericiler ile uygulayın. Sürümleri etiketlemek için sorun izleme veya biletleme sisteminizi kullanın. Belirli bir sürümün bir özelliği hareketsizse, o zaman hepsinin olduğunu açıkça belirtin.

2. Dallanma stratejileri

Git-flow bu gibi sorunların kolay cevabıdır ve insanlar ne olduğunu bilmeseler bile çoğu kez git-flow değişkenini kullanırlar. Bunun tüm problemler için her şeyi yakalayacağını söylemeyeceğim, ama çok yardımcı oluyor.

Belirleyici olmayan yayın stratejileriyle ilgili bir sorunla karşılaştığınız anlaşılıyor, burada özellikler onaylanmış dağıtımdır ve uzun zaman önce geliştirmeye başlayan bir şey, daha yakın zamanda başlayan bir şeyden sonra sıçrayan kurbağa özellikleri olabilir.

Uzun ömürlü özellik dalları veya eşzamanlı serbest bırakma dalları muhtemelen bu tür sorunlar için en iyi yanıttır. Ustadan en son uzun süredir çalışan dallarınızda birleştirin (veya rahatsanız, yeniden doğuş) . Yalnızca halihazırda canlı olan özellikleri birleştirmeye dikkat edin , aksi takdirde şu anda yaşadığınız sorunlarla karşılaşırsınız (bir dalda çok fazla karma özellik).

"Düzeltme" veya "hata düzeltme" dalları bu işlemin önemli bir parçasıdır; bunları kısa bir KG döngüsü olan küçük bir kerelik düzeltmeler için kullanın.

Senin açıklamadan, hatta daha iyi olabilir değil bir resmi 'gelişme' dalını korumak. Aksine, tüm özellikleri master'dan ayırın ve bir sürüm tanımlandıktan sonra birleştirilmiş sürüm dalları oluşturun.

3. Ortamlar

Git = şubeleri ortamınızla eşleştirmeyin, üretim == master hariç. 'Geliştirme' dalı kırılmış sayılmalıdır. Serbest bırakma dalları, QA ortamı veya aşamalı bir ortam olsun, ortamları test etmek için itilir. Gerekirse, belirli bir özellik dalını ortama itin.

Ayrı olarak serbest bırakılması gereken ancak aynı zamanda test edilmekte olan birden fazla özellik dalınız varsa ..... ¯ \ _ (ツ) _ / ¯ .... başka bir sunucuyu döndürüyor musunuz? Belki de onları bir atıcı dalda birleştirin ... orijinal dallarda düzeltmeler / değişiklikler yapın ve atıcı dalda yeniden birleşin; tek tek serbest bırakma dallarında nihai onay ve UAT yapabilir.

4. Onaylanmamış özellikleri bir şubeden kaldırma

Yukarıdaki düşünceler kaçınmaya çalışıyor, çünkü bu şüphesiz denemek ve yapmak için en acı verici şey. Şanslıysanız, özellikler birleştirme işlemlerini kullanarak geliştirme veya test dallarını atomik olarak birleştirmiştir. Şanssızsanız, geliştiriciler doğrudan geliştirme / test dalına kendini adamıştır.

Her iki durumda da, bir sürüm için hazırlanıyorsanız ve onaylanmamış değişiklikleriniz varsa, onaylanmamış taahhütleri sürüm dalından geri almak için Git'i kullanmanız gerekir ; en iyi fikir, sürümü test etmeden önce bunu yapmaktır .

İyi şanslar.

İşte bir fikir, Serbest bırakma dallarını kullanmayı bırak. Bunun yerine, özellik geçişleri oluşturmaya başlayın ve yapılandırma yoluyla yönetin. Bu şekilde, özellik dallarını her zaman master ile birleştirirsiniz ve hangi sürümün test edildiğinde veya üretildiği hakkında hiçbir zaman bir soru olmamalıdır. Bir ortamda hangi özelliklerin / uygulamaların etkin olduğu hakkında bir sorunuz varsa, yapılandırma dosyasını kontrol etmeniz yeterlidir.

Bu, test ve üretim arasında basit bir koordinasyon meselesi olmalıdır. Git'te özellik dalları kullanıyorsanız, bir test döngüsü sırasında tamamlanan özellik dallarını Test Et'e göndermeyi durdurun ve test tamamlandığında devam edin.

Bundan daha iyi kontrole ihtiyacınız varsa, Testi bir Geliştirme sunucusuna ve Kabul Testi sunucusuna ayırın ve Test ekibiyle Kabul Testi sunucusuna gönderilecek olan dalları koordine edin. Daha sonra birisi Kabul Testinden Üretime son konuşlandırmanın başlangıcından sorumlu olabilir.

İş yığınları

Bu benim deneyimimde evrensel bir problem. Ben ile adres:

• Ürün sahibi tarafından özellik sürümlerinin güçlü yönetimi
• Birleştirildiklerinde dalların silindiğinden emin olun
• Devam eden çalışmayı sınırla (Jira'da sütun sınırlarıyla)
• Hem hataları hem de özellikleri olan eski biletlerin üç ayda bir gözden geçirilmesi
• Sorunun bileşenlerini tartışmaya yönelik retrospektifler
• Herkes tarafından kod incelemeleri için sürekli teşvik
• Uzun zamandır devam eden biletler ve sorunların üstesinden gelmek için eşleştirme fırsatları
• Eski biletleri gözden geçirmek ve temizlemek için üç aylık toplantılar
• Dev, ürün ve QA / QE'nin birlikte sıkı çalışmasını sağlamak için ekip yaklaşımı
• Yeni ürün özelliklerini ve iş yükünü açık hale getirmek için iyi raporlama ve araçlar
• Eski şubeleri gözden geçirmek ve silmek için oturumları inceleyin

Dallar

Bu süreci kontrol etmek için bazı şubelere ihtiyacınız var:

• özelliği : Bu dallar ustadan doğar. Her özellik dalını bir görevle tanımlamak için bazı proje yönetimi uygulamalarını kullanın. Örneğin, TRAC kullanırsanız,: 1234-user-crud, 1235-bug-delete-catalogvb. Gibi şubeler varsa sona erdireceksiniz . Görevlerinizi de taahhütlerinizi tanımlayın, bu birleşme sorunlarınız olduğunda size çok yardımcı olacaktır (yapacaksınız).
• test : yapılan tüm özellik dalları test dalıyla birleştirilir. Sen bazı özellik dalı haline testi şube birleştirme asla size üretim (ana) olmayan başka özelliklere kodu istemiyoruz, çünkü. Aynı durum releaseşube için de geçerlidir .
• sürüm : Test edilen özelliklerin üretimde ne olabileceğine karar verdiğinizde, bu dalları (yine ...) bu dalda birleştirirsiniz. Tüm özellikleri tekrar test etmeniz gerekir, çünkü bu birleştirme yeni sorunlar getirebilir. Sürüm sınandığında ve bittiğinde, bu dalı master yapmak için birleştirir ve master için bir etiket oluşturursunuz.
• master : sadece üretim kodunu içerir.

Git akışına bakın:

                              |FEAT_2|
                                  |
                             .---C06<-------.---------.
                            /                \         \
                           /   |FEAT_1|        \         \
                          /       |            \         \
                         /    .--C07<--.--------\---------\---------.
                        /    /          \        \  |TEST| \         \
                       /    /            \        \    |    \         \
                      /    /        .-----`--C09<--`--C10    \         \ |RELEASE|
                     /    /        /                          \         \    |
    <v4.6.0>        /    /        /                       .----`--C11<---`--C12<--.
       |           /    /        /                       /                         \
C01<--C02<--C04<--´----´--------´-----------------------´---------------------------`--C13
 |           |                                                                          |
<v4.5.0>  <v4.6.1>                                                                   |MASTER|
                                                                                        |
                                                                                     <v4.7.0>

ortamları

Çok basit:

• test : bu ortam test dalını kullanır.
• release : bu ortam, gerçek release şubesini kullanır.

Geliştiriciler, her biri kendi veritabanını kullanarak makinesinde çalışır. Her geliştiricinin ayrı bir veritabanı varsa (lisanslar, veritabanı boyutu vb. Nedeniyle), geliştiriciler arasında bir veritabanını paylaşırken çok fazla sorun yaşarsınız: birisi dalındaki bir sütunu veya tabloyu sildiğinde, diğerleri dalları hala veritabanındaki bu sütun / tablo ile sayar.

sorunlar

Bu süreçteki en büyük sorun birleşmelerdir.

Sen aynı birleştirmeleri yenilettim gerekir testve release. Kodda bir sınıf silme, taşıma / yeniden adlandırma yöntemleri vb. Gibi iyi bir refactor yapılırsa bu acı verici olacaktır . (Veya ) daldan özellik dalına kod alamadığınız için , birleştirme işlemleri yalnızca (ya da ). İçinde: Öyleyse, muhtemelen gelecekte, her birleştirme farklı kod üreten ve iki farklı branşlarda aynı sorunları çözümleme sonunda, test ekibi iki kez özellikleri test etmek gerektiğini keşfedecek ve dalları, her birleştirme nedeniyle farklı hatalara neden olabilir.testreleasetestreleasetestrelease

Başka bir sorun da testşubedir. Zaman zaman bu dalı "geri dönüştürmeniz" (yeni bir tane silip oluşturmanız master) gerekecektir, çünkü bazı eski şubeler (veya eski birleştirmeler, silinmiş birleştirilen şubeler) yeni kod için çok fazla sorun getirebilir, içinde olandan çok farklı master. Bu anda, hangi dallarda tekrar birleştirmek istediğinizin kontrolüne ihtiyacınız var test.

Gerçekten en iyi çözüm, iş ekibinin bir sonraki versiyonda ne yapılması gerektiğini bilmesi ve herkesin benzersiz bir dalda (geliştirme dalında) çalışmasıdır. Onlar için ne zaman istedikleri bir sonraki sürümde hangi "bitti" özelliği seçmek için iyi bir olasılık (bu senin senaryo olduğunu düşünüyorum), ama bu geliştiriciler için bir kabus ve test takımı.

Senin gibi Sesler vardır birleştirme tam olarak söz nedenlerle IMHO iyi bir uygulama değil, üretim dalı içine entegrasyon daldan değişiklikleri. Belli bir sürüm için bir üretim dalı ana entegrasyon dalından çekilir çekilmez, entegrasyon şubesi herhangi bir anda ayrılabilir (sonuçta bir sonraki sürüme dönüşmesi gerekiyor). Entegrasyon dalından geçerli sürüm dalına birleştirme, bu sürümle uyumsuz değişiklikler getirebilir.

IMHO uygun bir süreç olacaktır:

• bir üretim dalını entegrasyon dalından ancak istenen kalite seviyesine yeterince yakın olduğu kabul edildiğinde, böylelikle serbest bırakmanın tamamlanması için sadece bir avuç değişiklik yapılması beklenir. Başka bir deyişle, özellik tamamlama, üretim dalını çekmeden önce entegrasyon dalında (sürekli) değerlendirilmelidir.
• üretim dalı çekildikten sonra, sadece kiraz tarafından seçilen değişiklikler getirilir, bağımsız / nokta düzeltmesi değişiklikleri olarak kabul edilir - yani aslında beklendiği gibi çalıştıklarını doğrular (sadece bir dalda bir değişiklik çalışması da mutlaka işe yaradığı anlamına gelmez) başka bir dalda).

Şahsen, bu bir takım sorunundan çok bir süreç sorunu olabilir gibi görünüyor. Burada önerebileceğim birkaç şey:

• Ayrı Dev ve KG gruplarınız olup olmadığından emin değilim. Bunu yaparsanız, hem Geliştirme hem de KG'nin sprint planlama ve tahmin toplantılarında yer aldığından emin olun. Önceki şirketlerimden birinde, bir hikaye atadığımız hikaye noktalarının sayısının hem geliştirme hem de test çabalarından sorumlu olduğundan emin olduk. (Ayrıca teorik olarak geliştirici ve KG çabaları için iki ayrı tahmininiz olabilir, ancak her iki şekilde de tahmininizin her ikisini de içermesi için ihtiyacınız vardır; Bir hikaye için gereken süre, onu gerçekten teslim etmek için gereken zamandır). Ayrı bir KG grubunuz olmasa bile, tahminlerinize test çalışmalarını dahil ettiğinizden emin olun.
• Yukarıdakine benzer bir damar boyunca, belirli bir sprint'e kaç hikaye ekleyeceğiniz konusunda önceden anlaşın. Kabul hikaye noktalarının sayısı, geliştiricilerin sprintteki bitirebiliriz miktarına dayanmaktadır ve QA onların sprint sınayabilmeleri öğelerin sayısı. (Elbette, Q sprintlerinin Dev sprintlerinin arkasında olduğunu varsayıyorum, ancak bunu işleminize uyarlayabilirsiniz). Geliştiricileriniz 200 öykü noktasını bitirebilir ancak KG'niz yalnızca 150 öykü noktasını bitirebilirse, işin "birikmeye" başlamadan önce sadece 150 öykü puanı yapabilirsiniz ve tarif ettiğiniz gibi bir vaka ile sonuçlanırsınız. (Böyle bir durumda, birlikte gösterimi azaltmaya çalışmak için nedenini araştırmak isteyebilirsiniz).
• Şu anda KG'deki her şey test edilip teslim edilinceye kadar hiç kimse KG'ye hiçbir şey göndermez .
• Tam bir özellik, test edilmiş ve teslim edilmiş özelliktir. Teslim edilmezse yapılmaz.
• Açıkçası, bunu bir tür sabit bir programda yapmaya çalışmak istiyorsunuz. Sürekli Entegrasyon ve Çevik'in arkasındaki fikirlerden biri yinelemedir. Tanım gereği, yineleme sık sık teslimat gerektirir. Sık entegrasyonlar ve teslimat, her birinin riskini en aza indirir.

Dürüst olmak gerekirse, bence en büyük şey ne zaman teslim edeceğiniz ve belirli bir zaman diliminde tam olarak kaç işi tamamlayabileceğiniz hakkında disiplin olacak.

Özetlemek gerekirse: KG'ye yalnızca eski özellikleri test edip sunduğunuzda teslim edin.

"Her şey test edildiğinde ve onaylandığında", test edilen ve üretime onaylananı dağıtın. Bu belirli bir taahhüt veya Jenkins tarafından üretilen belirli bir yapı artefaktı olabilir.

Aynı dalda daha sonra yapılacak taahhütlerin henüz test edilmemesi önemli değildir.