İş yükü geliştirme tedarik zinciri tasarlama önerileri

Bu Azure İyi Tasarlanmış Çerçeve operasyonel mükemmellik denetim listesi önerisi için geçerlidir:

Bu kılavuzda, sürekli tümleştirme ve sürekli teslim (CI/CD) işlem hatlarını temel alan bir iş yükü geliştirme tedarik zinciri tasarlama önerileri açıklanmaktadır. İş yükünüzü korumak için öngörülebilir, standartlaştırılmış bir yönteme sahip olduğunuzdan emin olmak için bir tedarik zinciri geliştirin. CI/CD işlem hatları tedarik zincirinin tezahürüdür, ancak tek bir tedarik zinciriniz olmalıdır. Ayrıca aynı işlemleri izleyen ve aynı araçları kullanan birkaç işlem hattınız olabilir.

İş yükünüzü iş yükü değişikliklerini düzgün yönetmediğinizde oluşabilecek zararlardan korumak için bir tedarik zinciri dahil edin. İş yükünüzün durumunu her zaman unutmayın, bu nedenle öngörülemeyen davranışlar yaşama riskiniz olmaz. Bu risk, sorunlar ortaya çıktığında hesaba katılmayan değişiklikleri geri çekmek için kritik zaman harcamanız gerekiyorsa bileşiktir. Bu riskleri en aza indirmek için tedarik zincirinizi tanımlayan süreçleri ve araçları standartlaştırın ve iş yükü ekibinizin kullanımlarına tam olarak bağlı olduğundan emin olun.

Tanım

Temel tasarım stratejileri

Aşağıdaki öneriler tedarik zincirinizin temel kümelerini tanımlamanıza yardımcı olabilir.

Otomatik şablon tabanlı dağıtımlar için katı bir ilke uygulama

Tedarik zinciri süreçleri ve araçları aracılığıyla önerilen iş yükü değişikliklerini yapın. Otomatik şablon tabanlı dağıtımlar için katı bir ilke uygulayın. Bu yöntem, iş yükünüzün tüm ortamlardaki yapılandırmasının standart, iyi tanımlanmış ve sıkı bir şekilde denetlenmesini sağlamaya yardımcı olur. Kod yükseltme zincirindeki ortamlar için, el ile işlemleri veya bulut platformunun kontrol düzlemiyle (örneğin portal veya API) insan etkileşimini kullanarak güncelleştirmeler gerçekleştirmayın. Tanımladığınız dağıtım uygulamalarını izleyerek bir işlem hattı aracılığıyla ortamdaki tüm değişiklikleri birleştirin. Bu ilkenin uygulanmasına yardımcı olmak için, erişimi varsayılan olarak salt okunur olarak sınırlamayı ve yazma erişimine izin vermek için erişim yetkilendirme geçidi kullanmayı göz önünde bulundurun.

Bu ağın önemli bir yönü, tüm değişikliklerin üretime dağıtılana kadar değişiklik önerilmesidir. Tümleştirme ve duman testi gibi otomatik testlerle tedarik zincirinizin değişiklikleri otomatik olarak reddetmesini sağlarsınız.

Yinelenebilir ve sabit altyapıyı kod olarak dağıtma

Yinelenebilir ve sabit altyapıyı kod olarak (IaC) dağıtın. IaC, kaynak kodu yansıtan bir sürüm oluşturma sistemi kullanan açıklayıcı bir modelde altyapı yönetimidir. Bir uygulama oluşturduğunuzda, aynı kaynak kodu her derlendiğinde aynı ikiliyi oluşturmalıdır. Benzer şekilde, bir IaC modeli her uygulandığında aynı ortamı oluşturur.

Ekibinizin standart, iyi oluşturulmuş bir süreç izlediğini güvence altına almak için IaC'yi dahil edin. Bazı kuruluşlar, altyapıyı dağıtmak ve yapılandırmak için tek bir veya küçük bir kişi grubu ayarlar. Tam otomatikleştirilmiş bir işlem uyguladığınızda, altyapı dağıtımları bireylerden daha az yönetim gerektirir. Sorumluluk otomasyon sürecine ve araçlarına aktarılır. Ekip üyeleri tutarlılığı ve kaliteyi korumak için altyapı dağıtımları başlatabilir.

dağıtımları kolay ve tekrarlanabilir hale getirmek için iş yükünüzü tek bir şablonda paketleyebileceğiniz mantıksal bir bileşen grubu olarak tasarlayın. Bu paketleri pul veya ölçek birimi olarak düşünebilirsiniz. Daha fazla bilgi için bkz . Dağıtım Damga Damgaları düzeni. Aynı bölge içindeki başka bir bölgeye veya bölgeye ölçeği genişletmek için iş yükünüzü dağıtmanız gerektiğinde, işlem hattı kullanarak bir damga damgası dağıtın. Damga damgalarınızı nasıl tasarladığınıza bağlı olarak, iş yükünün tamamı yerine iş yükünüzün bir alt kümesini dağıtabilirsiniz. Dağıtım damgalarınızın mevcut kaynaklara otomatik olarak bağlandığından emin olmak için IaC işlem hatlarınıza ağ bileşenlerini ekleyin.

IaC işlem hattınızı tutarlılık ve verimlilik açısından iyileştirmek için, değiştirilebilir altyapı yerine sabit bir altyapı tasarlayın. Kapsamdaki tüm sistemlerin her dağıtımla aynı anda ve aynı şekilde güncelleştirilmiş yapılandırmayla değiştirildiğinden emin olmak için sabit bir altyapı uygulayın.

Tüm ortamlarda aynı dağıtım yapıtlarını kullanma

Tüm ortamlarda ve işlem hatlarında tek bir kod varlığı ve yapıt kümesi kullanın. Kuruluşlar için yaygın bir sorun, üretim dışı ortamların üretim ortamlarından farklı olmasıdır. Üretim ve üretim dışı ortamların el ile oluşturulması, ortamlar arasında eşleşmeyen yapılandırmalara neden olabilir. Bu uyuşmazlık testi yavaşlatır ve değişikliklerin üretim sistemine zarar verme olasılığını daha yüksektir. IaC yaklaşımı bu sorunları en aza indirir. IaC otomasyonunu kullandığınızda, neredeyse aynı ortamları oluşturmak için tüm ortamlar için aynı altyapı yapılandırma dosyalarını kullanabilirsiniz. Altyapı yapılandırma dosyalarına parametreler ekleyebilir ve bunları her ortamın gereksinimlerini karşılayacak şekilde ayarlayabilirsiniz.

Maliyetleri denetlemek için genellikle üretim ve üretim dışı ortamlar arasında bir fark vardır. Üretim dışı ortamlarda genellikle üretim ortamındakiyle aynı düzeyde yedekliliğe ve performansa ihtiyacınız yoktur. Kaynaklarınızın sayısı ve SKU'su ortamlar arasında farklılık gösterebilir. Değişiklik yaparken öngörülebilirliği korumanıza yardımcı olmak için standartlaştırılmış parametreler kullanarak varyansı denetlediğinizden ve anladığınızdan emin olun.

Tedarik zincirindeki kuruluş yapısını yansıtma

Tedarik zincirinize ve işlem hattı tasarımlarınıza kurumsal yapınızı yansıtabilirsiniz. Kuruluşunuz ekipler arasında silolanmış olabilir. Her ekip tedarik zincirinin bir bölümünü yönetebilir. Örneğin, birçok kuruluşun ağ, veri ve işlem kaynakları gibi altyapı etki alanlarını yöneten ekipleri vardır. Bu ekipler uygulama geliştirme, test ve dağıtımları yöneten geliştirme ekiplerinden ayrıdır. Bazı kuruluşlarda geliştirme ve altyapı ekipleri, tüm altyapı ve uygulama dağıtımlarını topluca yöneten DevOps ekiplerine dahil edilir. Tedarik zincirinde yer alan ekipleri düzenlemenin birçok yolu vardır. Tedarik zinciriniz, tüm ekiplerin sorunsuz bir şekilde birlikte çalışmasına dayanır. Tüm ekiplerin standart süreçleri izlediğinden ve tedarik zincirini mümkün olduğunca verimli hale getirmek için standart araçları kullandığından emin olun.

İş yükü yaşam döngüsünün bazı bölümlerini dış kaynak olarak kullandığınızda tedarik zinciriniz üçüncü taraf satıcılara güvenebilir. Bu satıcılar, tedarik zincirinizin başarısı için iç kaynaklar kadar kritik öneme sahiptir. Kullandığınız süreçler ve araçlar hakkında tüm ekipler arasında karşılıklı bir anlaşma olduğundan emin olun.

Doğru dağıtım yöntemini seçin

Dağıtım yönteminizi standartlaştırarak. İş yükünüz için kabul edilebilir üretim kapalı kalma süresi miktarı hakkında ürün sahibiyle görüşün. Kapalı kalma süresinin kabul edilebilir olup olmadığının ne kadar olduğuna bağlı olarak, gereksinimlerinize uygun dağıtım yöntemini seçebilirsiniz. İdeal olarak, karmaşıklığı ve riski azaltmak için bir bakım penceresi sırasında dağıtımlar gerçekleştirmeniz gerekir. Kapalı kalma süresi kabul edilebilir değilse mavi-yeşil dağıtım yöntemi kullanın.

Müşterilerinize algılanmayan hataların ortaya çıkarılma riskini azaltmak için aşamalı maruz kalma yaklaşımını kullanın. Kanarya dağıtımları olarak da bilinen bu yöntem, denetimli kullanıcı gruplarına aşamalı bir sırayla dağıtılır. Daha fazla kullanıcıyı etkilemeden önce sorunları yakalar. İlk dağıtım grubu, müşterilerinizin dağıtım stratejisinden haberdar olan bir alt bölümü olabilir. Müşterilerin bu alt bölümü, bazı beklenmeyen davranışları tolere edebilir ve geri bildirim sağlayabilir. Veya dağıtım sırasında hataların patlama yarıçapını içermeye yardımcı olan bir grup iç kullanıcı olabilir.

Dağıtım yönteminizi tanımlarken, her dağıtımda yalnızca en küçük uygulanabilir değişikliği dağıtmaya yönelik standart bir ilke benimseyin. İş yükünün kritikliği ve bileşenlerin karmaşıklığı gibi faktörlere bağlı olarak, en küçük uygulanabilir değişikliği belirleyin. Sabit bir altyapı kullanıyorsanız, en küçük uygulanabilir değişiklik genellikle kaynakların önceki sürümü çalıştıran kaynakları değiştirmek için en son yapılandırmaya sahip dağıtımıdır. Değiştirilebilir bir altyapı kullanıyorsanız, en küçük uygulanabilir değişikliğin kapsamdaki kaynak grubunda yalnızca tek bir güncelleştirme olduğuna karar verebilirsiniz.

Katmanlı bir yaklaşımı izleme

Farklı yaşam döngülerini yansıtmak için katmanlı bir yaklaşımı izleyin. Temel katmanlar, iş yükü yaşam döngüsünün çoğu boyunca statik kalmalıdır ve uygulama katmanları sık sık değişir. Bu farkları hesaba katmak için, her katmandaki değişiklikleri etkili hale getirmek için farklı işlem hatlarına sahip olmanız gerekir.

Giriş bölgesi en düşük katmandadır. Giriş bölgesi abonelikler, yönetim grupları, kaynak grupları, idare işlevleri ve ağ topolojisi gibi temel öğelerin mantıksal bir gruplandırmasıdır. Giriş bölgesi, iş yükünüzü kolayca dağıtmanıza ve yönetmenize olanak tanır ve merkezi operasyon ekiplerine veya platform ekiplerine ortam yapılandırmasına tekrarlanabilir bir yaklaşım sunar. Tutarlı ortamlar sunmak için tüm Azure giriş bölgeleri bir dizi ortak tasarım alanı, başvuru mimarisi, başvuru uygulaması ve dağıtımı tasarım gereksinimlerinize uyacak şekilde değiştirme işlemi sağlar. Azure giriş bölgesi tasarım ilkeleri, abonelik demokratikleştirmesinin yanı sıra ilke temelli idareyi temel alan önerilen uygulamalar sağlar. Giriş bölgesi, iş yükü yaşam döngünüz boyunca çok az değişiklik gerektirmelidir. Giriş bölgesi örneğini görmek için bkz . Azure giriş bölgesi nedir? Bu kavramsal mimari, Azure için önerilen bir dizi görüş sağlar.

Giriş ve çıkış ağ denetleyicileri, yük dengeleme, ağ yönlendirme çözümleri, DNS yönetimi ve çekirdek sunucular gibi temel altyapınız ve işlevleriniz de seyrek büyük değişiklikler gerektirmelidir. Ancak bunlar sık sık yapılandırma güncelleştirmeleri gerektirebilir.

Uygulamanız ve veri katmanınız için sık yapılandırma güncelleştirmeleri ve sık altyapı değişiklikleri gerekir. Bu bileşenler en dinamik işlem hatlarına sahip olmalıdır.

Kapsamlı test türlerini dahil etme

Bütünsel bir test stratejisi planlama. Sistem güvenilirliğinin temel tenetlerinden biri, sola kaydırma ilkesidir. Uygulama geliştirme ve dağıtma, soldan sağa giden bir dizi adım olarak gösterilen bir işlemdir. Testi sürecin sonuna kadar sınırlamamalısınız. Mümkün olduğunca, testi en başa veya sola doğru kaydırın. Hataları erken yakaladığınızda onarmak daha ucuz olur. Uygulama yaşam döngüsünde daha sonra düzeltmek pahalı veya imkansız olabilir.

Uygulama kodu, altyapı şablonları ve yapılandırma betikleri dahil olmak üzere tüm kodları test edin. Uygulamaları çalıştıran ortam, sürüm denetiminden geçirilmeli ve uygulama koduyla aynı mekanizmalar aracılığıyla dağıtılmalıdır. Ekiplerinizin uygulama kodu için zaten kullandığı test paradigmalarını kullanarak ortamı test edebilir ve doğrulayabilirsiniz.

Mümkün olduğunda, tutarlılığı sağlamak için otomatikleştirilmiş testi kullanın. Tedarik zinciri tasarımınıza aşağıdaki test türlerini ekleyin.

• Birim testi: Birim testleri genellikle sürekli tümleştirme yordamının bir parçası olarak çalıştırılır. Birim testleri kapsamlı ve hızlı olmalıdır. İdeal olarak kodun yüzde 100'ünün kapsaması ve 30 saniyeden kısa bir süre içinde çalıştırılması gerekir.

  Tek tek kod modüllerinin söz diziminin ve işlevselliğinin olması gerektiği gibi çalıştığını doğrulamak için birim testi uygulayın, örneğin bilinen bir giriş için tanımlı bir çıkış oluşturun. IaC varlıklarının geçerli olduğunu doğrulamak için birim testlerini de kullanabilirsiniz.

  Şablonlar ve betikler dahil olmak üzere tüm kod varlıklarına birim testleri uygulayın.

• Duman testi: Duman testleri, bir iş yükünün test ortamında bekletilebildiğini ve beklendiği gibi performans gösterebileceğini doğrular. Duman testleri bileşenlerin birlikte çalışabilirliğini doğrulamaz.

  Duman testleri, altyapı ve uygulama için dağıtım metodolojisinin çalıştığını ve işlem tamamlandıktan sonra sistemin istenen şekilde yanıt verdiğini doğrular.

• Tümleştirme testi: Tümleştirme testleri, uygulama bileşenlerinin ayrı ayrı çalışmasını sağlar ve sonra bileşenlerin birbirleriyle olması gerektiği gibi etkileşimde bulunup bulunamayacağını belirler.

  Büyük bir tümleştirme test paketini çalıştırmak çok uzun sürebilir. Bu nedenle, en iyisi sol kaydırma ilkesini dahil etmek ve yazılım geliştirme yaşam döngüsünün erken aşamalarında test gerçekleştirmektir. Duman testi veya birim testi ile test edemediğiniz senaryolar için tümleştirme testlerini ayırın.

  Gerekirse uzun süre çalışan test işlemlerini düzenli aralıklarla çalıştırabilirsiniz. Düzenli aralık iyi bir güvenlik açığı sunar ve uygulama bileşenleri arasındaki birlikte çalışabilirlik sorunlarını kullanıma sunulduğundan en geç bir gün sonra algılar.

  Bazı test senaryoları el ile çalıştırmalardan yararlanılır. Testlere insan etkileşim öğeleri eklemeniz gerektiğinde el ile testi kullanın.

• Kabul testi: Bağlama bağlı olarak, kabul testini el ile gerçekleştirebilirsiniz. Kısmen veya tamamen otomatikleştirilebilir. Kabul testi, yazılım sisteminin gereksinim belirtimlerini karşılayıp karşılamadığını belirler.

  Bu testin temel amacı, sistemin iş gereksinimleriyle uyumluluğunu değerlendirmek ve sistemin son kullanıcılara teslim için gerekli ölçütleri karşılayıp karşılamadığını belirlemektir.

Kod yükseltme süreçlerinde kalite geçitleri uygulama

Test yoluyla kod yükseltme sürecinizde kalite geçitlerini uygulayın. Kodunuzu geliştirme ve test gibi daha düşük ortamlara ve hazırlama ve üretim gibi daha yüksek ortamlarda dağıtın. Dağıtımınız kalite kapılarından geçerken, değişiklikler üretime geçmeden önce kalite hedeflerinizi karşıladığından emin olun. İş gereksinimleriniz, kalite kapılarınızın odak noktasını belirler. Ayrıca temel İyi Tasarlanmış Çerçeve ilkelerini de göz önünde bulundurun: Güvenlik, Güvenilirlik ve Performans Verimliliği.

Ayrıca onay iş akışlarını kalite kapılarınızla tümleştirin. Uygun olduğunda onay iş akışlarını net bir şekilde tanımlayın ve otomatikleştirin. Kalite kabul ölçütlerini otomasyonunuzda tanımlayın, böylece kapılarınızdan verimli ve güvenli bir şekilde geçebilirsiniz.

Azure kolaylaştırma

Azure DevOps , işbirliğine dayalı, verimli ve tutarlı bir geliştirme uygulaması oluşturmanıza yardımcı olan bir hizmet koleksiyonudur.

Azure Pipelines , uygulamalarınızda CI/CD'yi desteklemek için derleme ve yayın hizmetleri sağlar.

Azure için GitHub Actions, dağıtımları basitleştirmek için Azure ile tümleşir. CI/CD işlemlerini otomatikleştirmek için GitHub Actions'ı kullanın. Deponuzdaki her çekme isteğini derleyip test eden iş akışları oluşturabilir veya birleştirilmiş çekme isteklerini üretim ortamına dağıtabilirsiniz.

Terraform, Bicep ve IaC dağıtımları için Azure Resource Manager'ı kullanabilirsiniz. Gereksinimlerinize ve ekibinizin araçlarla ilgili bilgisine bağlı olarak, dağıtımlarınız ve kaynakları yönetmeniz için bu araçlardan birini veya daha fazlasını kullanabilirsiniz.

Örnek

Ci/CD işlem hattı oluşturmak için Azure Pipelines'ın nasıl kullanılacağını gösteren bir örnek için bkz . Azure Pipelines temel mimarisi.

İlgili bağlantılar

• Azure DevOps
• Azure Pipelines
• Dağıtım DamgaLarı düzeni
• Azure için GitHub Actions
• Performans Verimliliği sütunu
• Güvenilirlik sütunu
• Güvenlik sütunu

Operasyon Mükemmelliği denetim listesi

Öneriler kümesinin tamamına bakın.