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

  • Makale

Test temelli geliştirme (TDD), kod tabanlı çözümlerde yeni özelliklerin ve geliştirmelerin kalitesini geliştiren bir yazılım geliştirme ve DevOps işlemidir. TDD, gerçek kodu geliştirmeden önce birim testi çalışmaları oluşturur ve kodu test çalışmalarından test edilir. 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 uygun 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 işlemi kullanabilirsiniz. Bu süreç özellikle paralel bir geliştirme çabası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 işleminin diyagramı.

  1. Test oluşturma. 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ğlanmamışsa 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 artırmak 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 ekleyebilir. Ancak, kod kalitesi ve bakımı paylaşılan çabalardır. Bulut platformu ekibi, yeni özellik isteklerini yerine getirdikçe yinelemeyi kaldırarak ve kodu netleştirerek kodu iyileştirmeye çalışmalıdır. Yeni kod oluşturma ve kaynak kodun yeniden düzenlenmesi arasında testler çalıştırılması kesinlikle önerilir.

  4. Giriş bölgesini 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ü, önceki temel adımları tamamlandı ifadesinin tam tanımına uyana kadar yineler. 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ü genellikle kı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 testle 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 yerine daha iyi bir tasarıma değinmektir. Testler, işlemi tamamlamak için değerli bir yapıttır.

Tamamlanma tanımı

Başarı, bulut platformu ekibine giriş bölgesi geliştirme veya yeniden düzenleme sırasında küçük eyleme dönüştürülebilir bilgiler 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 dahil etmek üzere 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 tümü kabul ölçütlerini karşıladığında, giriş bölgesi geçerli benimseme dalgasının veya yayının başarısını sağlamak için yeterince yapılandırılır.

Basit DoD örneği

İlk geçiş çabası için DoD çok 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 beklenmemektedir.

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 keşfine uygun 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.
  • Üretim sürümünden önce, operasyon yönetimi için devam eden kimliği ve erişimi yönetmek üzere kurumsal kimlik sağlayıcısıyla tümleştirme. Bu 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şletme gerekeceğini 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 İdare metodolojisi, bir idare ekibinin doğal olgunluğu boyunca bir anlatı yolculuğu sağlar. Bu yolculukta, ilke deyimleri biçiminde DoD ve kabul ölçütlerine birkaç örnek verilmiştir.

Yukarıdaki örnekler, giriş bölgeleriniz için bir DoD geliştirmenize yardımcı olacak temel örneklerdir. Bulut İdaresi'nin Beş Uzmanlık Alanının her biri için örnek ilkeler alabilirsiniz.

Giriş bölgesi TDD'sini desteklemek için Azure araçları ve özellikleri

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

Azure'daki 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üleriyle uyumlu 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, giriş bölgelerini kaynak kod tanımlarına göre 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 göndermek için kendi ARM şablonlarını sağlar.

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

  • Azure İlkesi, DoD'nızdaki 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 İlkesi, bir DoD içinde bireysel kabul ölçütlerini karşılayabilen yerleşik ilke tanımlarını 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 için kullanabileceğiniz yerleşik ilke girişimlerini 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 Azure İlkesi Kod iş akışları olarak tasarlayın ve gözden geçirin.

  • Azure Blueprints, ilkeleri ve diğer dağıtım araçlarını birden çok giriş bölgesine atayabileceğiniz tekrarlanabilir bir paket halinde gruplandırıyor. Şemalar, zaman içinde güncelleştirmek isteyebileceğiniz ortak Kimlikleri paylaşan birden çok benimseme çalışması için kullanışlıdır. Azure Blueprints, giriş bölgelerini genişletmek ve yeniden düzenlemek için sonraki çalışmalar sırasında dağıtım konusunda da yardımcı olabilir.

    Azure Blueprints, test ilkeleri ve dağıtım şablonları dahil olmak üzere çeşitli şema örnekleri sağlar. Bu şema örnekleri, TDD döngülerindeki geliştirme, dağıtım ve test çalışmalarını hızlandırabilir.

  • Azure Kaynak Grafı, giriş bölgesinde dağıtılan varlıklar hakkındaki bilgilere dayalı olarak 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ıyla 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 örnekleri içerir.

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

Sonraki adımlar