Aracılığıyla paylaş

Azure giriş bölgeleri için test temelli geliştirme

Test temelli geliştirme (TDD), kod tabanlı çözümlerde yeni özelliklerin ve geliştirmelerin kalitesini artıran bir yazılım geliştirme ve DevOps işlemidir. TDD, gerçek kodu yazmadan önce birim test durumları oluşturur ve kodu test durumlarına karşı test eder. Bu yaklaşım, önce kod geliştirmeye ve daha sonra test çalışmaları oluşturmaya karşıdır.

giriş bölgesi, kod aracılığıyla önceden sağlanan iş yüklerini barındırma ortamıdır. Giriş bölgeleri, tanımlı bir bulut hizmetleri kümesini ve en iyi yöntemleri kullanan temel özellikleri içerir. Bu makalede kalite, güvenlik, operasyonlar ve idare gereksinimlerini karşılarken başarılı giriş bölgeleri dağıtmak için TDD kullanan bir yaklaşım açıklanmaktadır.

Bulut altyapısı, kod yürütmenin çıkışıdır. İyi yapılandırılmış, test edilmiş ve doğrulanmış kod uygulanabilir bir giriş bölgesi oluşturur. Bulut tabanlı altyapı ve temel alınan kaynak kodu, giriş bölgelerinin yüksek kaliteli olduğundan ve temel gereksinimleri karşıladığından emin olmak için bu yaklaşımı kullanabilir.

Erken geliştirme sırasında basit özellik isteklerini karşılamak için bu yaklaşımı kullanın. Bulut benimseme yaşam döngüsünün ilerleyen bölümlerinde güvenlik, operasyon, idare veya uyumluluk gereksinimlerini karşılamak için bu süreci kullanabilirsiniz. Bu süreç özellikle paralel bir geliştirme çalışmasında giriş bölgelerini geliştirmek ve yeniden düzenlemek için yararlıdır.

Test temelli geliştirme döngüsü

Aşağıdaki diyagramda Azure giriş bölgeleri için test temelli geliştirme döngüsü gösterilmektedir:

Azure giriş bölgeleri için test temelli geliştirme sürecinin diyagramı.

  1. Bir test oluşturun. Bir özelliğin kabul ölçütlerinin karşılandığını doğrulamak için bir test tanımlayın. Özellikle kurumsal ölçekli dağıtımlarda el ile test çabası miktarını azaltmak için, geliştirirken testi otomatikleştirin.

  2. Giriş bölgesini test edin. Yeni testi ve mevcut testleri çalıştırın. Gerekli özellik bulut sağlayıcısının tekliflerine dahil değilse ve önceki geliştirme çalışmaları tarafından sağlanmadıysa test başarısız olmalıdır. Mevcut testleri çalıştırmak, yeni özelliğinizin veya testinizin mevcut giriş bölgesi özelliklerinin güvenilirliğini azaltmadığını doğrulamaya yardımcı olur.

  3. Giriş bölgesini genişletin ve yeniden düzenleme. İstenen değer ekleme özelliğini yerine getirmek ve kod tabanının genel kalitesini geliştirmek için kaynak kodu ekleyin veya değiştirin.

    TDD ölçütlerini karşılamak için bulut platformu ekibi yalnızca istenen özelliği karşılamak için kod ekler. Ancak, kod kalitesi ve bakımı ortak bir çabadır. Bulut platformu ekibi, yeni özellik isteklerini yerine getirdikçe yinelemeyi kaldırarak ve kodu netleştirerek kodu geliştirmeye çalışmalıdır. Yeni kod oluşturma ve kaynak kodun yeniden düzenlenmesi arasında testleri çalıştırmak kesinlikle önerilir.

  4. İniş alanını dağıtın. Kaynak kod özellik isteğini yerine getirdikten sonra, değiştirilen giriş bölgesini denetimli bir test veya korumalı alan ortamında bulut sağlayıcısına dağıtın.

  5. Giriş bölgesini test edin. Yeni kodun istenen özelliğin kabul ölçütlerini karşıladığını doğrulamak için giriş bölgesini yeniden test edin. Tüm testler geçtikten sonra özellik tamamlanmış olarak kabul edilir ve kabul ölçütleri karşılanır.

TDD döngüsü, tamamlandığıtanımına tam uyan kadar önceki temel adımları tekrarlar. Tüm katma değerli özellikler ve kabul ölçütleri ilişkili testlerinden geçtiğinde, giriş bölgesi bulut benimseme planının bir sonraki dalgasını desteklemeye hazırdır.

TDD'yi etkili kılan döngü genelliklekırmızı/yeşil test olarak adlandırılır. Bu yaklaşımda bulut platformu ekibi, bitti tanımına ve tanımlanan kabul ölçütlerine göre başarısız bir test veya kırmızı testle başlar. Her özellik veya kabul ölçütü için bulut platformu ekibi, test geçene veya yeşil bir teste sahip olana kadar geliştirme görevlerini tamamlar.

TDD'nin amacı, bir test paketi oluşturmak değil, daha iyi bir tasarıma değinmektir. Testler, işlemi tamamlamak için değerli bir yapıttır.

Tamamlanmanın Tanımı

Başarı, giriş bölgesi geliştirme veya yeniden düzenleme sırasında bulut platform ekibine az eyleme dönüştürülebilir bilgi sağlayan öznel bir ölçü olabilir. Netlik eksikliği, bulut ortamında beklentilerin ve güvenlik açıklarının kaçırılmasına neden olabilir. Bulut platformu ekibi herhangi bir giriş bölgesini yeniden düzenlemeden veya genişletmeden önce, her giriş bölgesi için bitti (DoD) tanımıyla ilgili netlik aramalıdır.

DoD, bulut platformu ekibiyle etkilenen diğer ekipler arasında giriş bölgesi geliştirme çalışmalarına eklenmesi beklenen katma değerli özellikleri tanımlayan basit bir anlaşmadır. DoD genellikle kısa vadeli bulut benimseme planıyla uyumlu bir denetim listesidir.

Ekipler daha fazla iş yükü ve bulut özelliği benimsedikçe, DoD ve kabul ölçütleri daha karmaşık hale gelir. Olgun süreçlerde beklenen özelliklerin her birinin daha netlik sağlamak için kendi kabul ölçütleri vardır. Katma değerli özelliklerin tamamı kabul kriterlerini karşıladığında, giriş bölgesi mevcut benimseme dalgasının veya sürümün başarısını mümkün kılacak şekilde yeterince yapılandırılmış olur.

Basit DoD örneği

İlk geçiş çabası için DoD gereğinden fazla basit olabilir. Aşağıdaki örnek basit bir DoD'dir:

İlk giriş bölgesi, ilk öğrenme amacıyla 10 iş yükü barındıracaktır. Bu iş yükleri işletme için kritik değildir ve hassas verilere erişimi yoktur. Gelecekte bu iş yükleri büyük olasılıkla üretim ortamına sunulacaktır ancak kritiklik ve duyarlılığın değişmesi beklenmiyor.

Bu iş yüklerini desteklemek için bulut benimseme ekibinin aşağıdaki ölçütleri karşılaması gerekir:

  • Önerilen ağ tasarımıyla uyumlu hale getirmek için ağ segmentasyonu. Bu ortam, genel İnternet erişimi olan bir çevre ağı olmalıdır.
  • Dijital varlık bulmayla uyumlu iş yüklerini barındırmak için işlem, depolama ve ağ kaynaklarına erişim.
  • Kullanım kolaylığı için şemayı adlandırma ve etiketleme.
  • Benimseme sırasında bulut benimseme ekibinin hizmet yapılandırmalarını değiştirmesi için geçici erişim.
  • Üretime çıkmadan önce, operasyonların kimlik ve erişimini sürekli yönetmek amacıyla kurumsal kimlik sağlayıcısıyla tümleştirme. O sırada bulut benimseme takımının erişimi iptal edilmelidir.

Son nokta bir özellik veya kabul ölçütü değildir, ancak daha fazla genişletmenin gerekli olacağını ve diğer ekiplerle erken keşfedilmesi gerektiğini gösteren bir göstergedir.

Daha karmaşık DoD örnekleri

Bulut Benimseme Çerçevesi içindeki Yönetim metodolojisi, yönetim ekibinin doğal olgunluğa olan hikayesini sunar. Bu yolculukta, ilke deyimleri biçiminde DoD ve kabul ölçütlerinin birkaç örneği yer alır.

Yukarıdaki örnekler, giriş bölgeleriniz için bir DoD geliştirmenize yardımcı olacak temel örneklerdir.

Azure iniş bölgesi TDD'sini destekleyen araçlar ve özellikler

Aşağıdaki diyagramda Azure'daki kullanılabilir test temelli geliştirme araçları gösterilmektedir:

Azure'da test temelli geliştirme araçlarını gösteren Diyagramı.

Giriş bölgesi oluşturmak için bu Azure araçlarını ve özelliklerini kolayca TDD ile tümleştirebilirsiniz. Araçlar belirli amaçlara hizmet ederek giriş bölgelerini TDD döngülerine uygun olarak geliştirmeyi, test etmeyi ve dağıtmayı kolaylaştırır.

  • Azure Resource Manager, derleme ve dağıtım işlemleri için tutarlı bir platform sağlar. Resource Manager platformu, kaynak kod tanımlarına göre giriş bölgelerini dağıtabilir.

  • Azure Resource Manager (ARM) şablonları Azure'da dağıtılan ortamlar için birincil kaynak kodu sağlar. Terraform gibi bazı üçüncü taraf araçlar, Azure Resource Manager'a göndermek için kendi ARM şablonlarını sağlar.

  • Azure Hızlı Başlangıç Şablonları, iniş alanı ve iş yükü dağıtımlarını hızlandırmaya yardımcı olan kaynak kodu şablonlarını sağlar.

  • Azure İlkesi, DoD'nizdeki kabul ölçütlerini test etme için birincil mekanizmayı sağlar. Azure İlkesi ayrıca dağıtımlar idare ilkelerinden saptığında otomatik algılama, koruma ve çözüm sağlayabilir.

    TDD döngüsünde, tek bir kabul ölçütünü test etmek için bir ilke tanımı oluşturabilirsiniz. Azure Policy, bir DoD içinde bireysel kabul kriterlerini karşılayabilen yerleşik ilke tanımları içerir. Bu yaklaşım, giriş bölgesini değiştirmeden önce kırmızı testler için bir mekanizma sağlar.

    Azure İlkesi, giriş bölgesi için tam DoD'yi test etmek ve zorunlu kılmak amacıyla kullanabileceğiniz yerleşik ilke girişimleri de içerir. Aboneliğin tamamına atanmış bir ilke girişimine tüm kabul ölçütlerini ekleyebilirsiniz. Giriş bölgesi DoD'yi karşıladıktan sonra, Azure İlkesi testin gelecek sürümlerde başarısız olmasına neden olacak kod değişikliklerini önlemek için test ölçütlerini zorunlu kılabilir.

    TDD yaklaşımınızın bir parçası olarak Kod iş akışları olarak Azure İlkesi tasarlayın ve gözden geçirin.

  • Azure Kaynak Grafı, giriş bölgesine dağıtılan varlıklar hakkındaki bilgilere dayanarak veri temelli testler oluşturmak için bir sorgu dili sağlar. Benimseme planının ilerleyen bölümlerinde bu araç, iş yükü varlıkları ile temel alınan bulut ortamı arasındaki etkileşimleri temel alan karmaşık testler de tanımlayabilir.

    Kaynak Grafı, gelişmiş test senaryoları için iş yüklerinin giriş bölgesi içinde nasıl dağıtıldıklarını anlamak için kullanabileceğiniz gelişmiş sorgu örnekleriiçerir.

Tercih ettiğiniz yaklaşıma bağlı olarak aşağıdaki araçları da kullanabilirsiniz:

  • Terraformkullanarak iniş alanlarını dağıtma.
  • Bicepkullanarak iniş alanlarının dağıtımı.
  • AzOpsadlı kaynak şablonlarını ve Bicep dosyalarını tüm Azure kapsam düzeylerinde iletip, Azure kaynak hiyerarşilerini çekip dışa aktaran bir PowerShell modülü ile iniş bölgelerini yönetin.

Sonraki adımlar