Test ortamlarında sürekli entegrasyona bağlı kararsızlıklardan nasıl kaçınılır?

Bazı hedef ortamları sık sık güncelleyen sürekli entegrasyon süreçleri kullandığınızı, böylece her değişiklik yaptığınızda "siz" değişikliklerinizi hemen test edebileceğinizi varsayalım. Bu CI'nin hedeflerinin bir parçası, değil mi?

Ancak, test döngünüzde yer alan başka yöneticilerin de olduğunu varsayalım (örneğin, yöneticiler veya müşteriler). Diğer insanların gelecek değişikliklerinizi gözden geçirmeye (kırmaya?) Katılmalarını sağlamak mantıklı, değil mi?

Ancak, diğer insanların bulunduğu ortamlarda sürekli olarak değişiklikler yapmaya devam ederseniz , ciddi olarak, bunları test etmeye çalışırsanız , aşağıdakiler gibi birden fazla sorun ortaya çıkabilir:

• they (derinlemesine) raporu kaydettikleri zaman, sorunu artık kendileri bile üretemedikleri (örneğin yanlışlıkla aynı sorunla karşılaştınız ve zaten ortamlarına sabitlediniz) sorun bildirirken zamanlarını boşa harcayabilirler.
• you bir sorunla karşılaştıkları ortamlar artık aynı olmadığından (siz (!!!) çevrelerini bindirmiş olabilirsiniz) bildirdikleri sorunları yeniden oluşturamayabilir.

Peki böyle (sinir bozucu) durumlardan kaçınmak için ne yapabilirsiniz (bir şeyler nasıl yapılandırılır?)?

Bu konuda deneyimimi vereceğim, çünkü çoğunlukla bazı cevapların neden her zaman geçerli olmadığını gösteriyor.

Başlamak için bazı bağlamlar:

• Yaklaşık 80 uygulama barındıracak 7 ortamımız var, bunların çoğu db2-iSeries üzerindeki web hizmetleri veya paylaşılan tablolar aracılığıyla birbirlerine güveniyor.
• İyi ya da kötü, iSeries bizim DB referans sistemimizdir.
• Bu son nokta, her biri için bir AS400 getirmenin çok pahalıya mal olacağı ve zaten onu çalıştıracak donanıma sahip olmayacağımız için, uygulamayı yalıtılmış bir ortamda bağımlılıkları ile getirme fikrini geçersiz kılar.

Yaptığımız şey tam bir otomatik Sürekli Teslimat değil, genel operasyonlar için tutarlı bir çok uygulama getirmek için bir sürüm programımız var. Bunun yanı sıra, her test ekibi test ettikleri uygulama için Soru-Cevap ortamından birinde bir sürümü tetikleyebilir ve başka bir takımın testlerini kırmasını istememek için bazı uygulama sürümlerine kilit koyabilir.

Uygulamaların bağımlılıkları yayınlanmadan önce kontrol edilir, bu nedenle diğer uygulamalar güncellenemezse veya gereken bağımlılıklarıyla eşleşmezse sistem bir şey yayınlamaz. Ana fikir, birisini etkilemediğinde güncellemelere izin vermektir, planlanan testler yoksa, önceki ortamdan akmalıdır (ve şimdi orta vadede 5 ilk ortamdaki planlanan sürümleri kaldırmayı hedefliyoruz. bu 'isteğe bağlı' yöntem sistemini doğruladı).

Kısa versiyon, ortamdaki uygulamaların etrafında bir 'semafor' sistemine sahip olmak için, bir ekip, manuel testler için hedef uygulamasını bağımlılıkları (ve geçişli bağımlılıkları) ile kilitleyebilmelidir.
Bu semaforun uygulanması büyük ölçüde otomasyon sisteminize bağlıdır, bu yüzden bunu uzatmayacağım.

Elbette kolay yol, diğerlerinin de belirttiği gibi, yukarıda açıklanan semafordan kaçınmak için tüm bağımlılıkları olan bir uygulama için yeni bir ortam oluşturmaktır.

Her test yürütmesi için güvenilir bir şekilde yeniden başlatılmadan sürekli olarak yeniden kullanılan bir test ortamından bahsediyorsunuz . Bu böyle bir testi güvenilmez kılar. İsterseniz, güvenilirlik perspektifinden, manuel testle benzer.

IMHO , CI / CD kalifikasyon amaçlarınız dahilinde böyle bir test kullanmamalısınız , çünkü kalifikasyon sürecinizi etkili bir şekilde geçersiz kılacaktır (en azından bu alanda). Yazılımın, teslim edilen her yazılım sürümü için test X'i gerçekte gerçekleştirmeden veya passelde edilen sonucun (yanlış pozitifler nedeniyle) tesadüfi olmadığından emin olmadan test X'i geçtiğini söylemek, testinizin güven seviyesini düşürecektir. Yanlış negatifler güvenilirliğe zarar vermez, ancak yarattıkları gereksiz "gürültü" nedeniyle de istenmezler.

Bu tür testleri CI / CD kalifikasyon sürecinizin dışında yapmak iyidir . Ancak, bu tür bir testte başarısız olan bir sonucu tıpkı müşteri tarafından bulunan bir hata gibi ele alıyorsunuz: bir düzeltme geliştirebilmek ve düzeltmenin çalıştığını onaylamak için sorunu güvenilir bir şekilde yeniden oluşturmanız gerekir. Ve eğer test güvenilir değilse bunu gerçekten yapamazsınız.

Sorunu ele almayı planlıyorsanız, öncelikle sorunu yeniden oluşturmak için otomatik, güvenilir bir test örneği geliştirirsiniz. Bir düzeltme geliştirmek ve etkinliğini onaylamak için kullanacağınız (test sonucu FAIL'dan PASS'a geçmelidir). İsterseniz, gelecekte tekrar oluşmasını önlemek için bu test çantasını CI / CD kalifikasyon sürecinizin içine de yerleştirmelisiniz (yapmalısınız?) - genel yazılım sürümü kalite düzeyinizi artırmak için.

Genel yaklaşım farklı ortamlar yaratmaktır:

DEV - bu, dev ekibinin işleri karıştırdığı yerdir. İşte tüm değişiklikleri ayarlama, yeni sürümü dağıtmak vb. İşte CI'nin tamamen entegre olduğu yer.

PREPROD / QA - burası "play" QA / test / validation team testler yapıyor. Bu ortam genellikle testler sırasında donar. CI'nin bu ortamla entegrasyonu, yalnızca ürünün yeni sürümlerini, yapılandırmalarını vb. Sağlamaktır.

ÜRETİM - açıklamak gerekiyor mu :)?

CI / CD yapıyorsanız, dağıtımdan (CD) önce bazı otomatik testler (CI) gerçekleştiği anlamına gelir. Test ortamınızda çok fazla sorun bulursanız, konuşlandırma dağıtımdan önce yapılan testler tarafından yakalanmadığı anlamına gelir; bu yetersiz otomatik test anlamına gelir. Geliştiriciler, test ortamlarında hataların ortaya çıktığı sorunlar yaşıyorsa, bunu önlemek için otomatik test paketlerini iyileştirmeleri gerekir. Bu aynı zamanda genel olarak üretime kadar kalite ve güvenilirliği artıracaktır.

Romeo Ninov'un cevabına eklemek için, dahili olarak bir ortamda uygulamaları mümkün olduğunca ayırmaya çalışmanız gerekir. Bu kısmen docker'ın geliştirici / test için bu kadar başarılı olmasının nedenidir. Neredeyse bir ortam paylaşmıyormuş gibi davranmanıza izin veriyor.

Diğer seçenek, uygulamaların çalıştığı, ortamınızı oluşturan altyapının geri kalanından ayrı olan çok açık bir şekilde tanımlanmış sunuculara sahip olmaktır. Yani. Tüm çevre yönetimi veya etkinleştirme makineleri ayrı, uzun ömürlü sunucularda çalışır. Ardından, bir uygulamayı test etmek için bilinen bir görüntüye dayalı yeni kısa ömürlü sunucuları bağlarsınız ve temel görüntüde herhangi bir değişiklik yapılırsa, bu değişiklikleri her yeni bileşen için her yere uygulamanız gerekir . Bu, değişiklikleri her şeye karşı test etmek anlamına gelir.

Bir appdev ekibi başka birinin başvurusunu bozan bir değişiklik isterse, o zaman zor şanslar, kodlarında dahili olarak bir hafifletici oluşturmaları ve özel gereksinimlerini sunulan ortamlardan ayrı tutmaları gerekir.