İş akışı ve sürüm oluşturma stratejisi tasarlama
Yeniden kullanılabilir Bicep kodunu yayımlamaya başladığınızda büyük olasılıkla el ile bir yaklaşım kullanırsınız. Yayımlamanız gereken Bicep dosyasını kolayca belirleyebilirsiniz ve büyük olasılıkla sürüm numarasını artırmaya yönelik el ile bir işleminiz vardır.
Yayımlama işlemini otomatikleştirirken bu adımları otomatikleştirmeyi göz önünde bulundurmanız gerekir. Bu ünitede, kodunuzda yaptığınız değişiklikleri bildiren bir sürüm oluşturma sistemini nasıl benimseyeceğinizi öğreneceksiniz. Ayrıca yalnızca beklediğiniz kodu yayımlamak için iş akışlarınızın kapsamını nasıl daraltabileceğinizi de öğreneceksiniz.
Sürüm numaraları
Önceki Microsoft Learn eğitim modüllerinde, şablon özellikleri ve Bicep modülleri için sürüm oluşturmanın önemini öğrendiniz. Birçok farklı sürüm oluşturma yaklaşımı arasından seçim yapabilirsiniz. Çoğu durumda, çok parçalı bir sürüm oluşturma sistemi kullanmak iyi bir uygulamadır. Çok parçalı sürüm oluşturma sistemi, aşağıdaki örneğe benzer şekilde ana sürüm, ikincil sürüm ve düzeltme numarasından oluşur:
Yukarıdaki örnekte ana sürüm 1, ikincil sürüm 4 ve düzeltme numarası 106'dır.
Sürüm numaralarının farklı bölümlerindeki değişiklikler, koddaki değişiklik türleri hakkında önemli bilgileri bildirir:
Hataya neden olan bir değişiklik yaptığınızda ana sürüm numarasını artırmanız gerekir. Örneğin, yeni bir zorunlu parametre eklediğinizi veya Bicep dosyanızdan bir parametre kaldırdığınız varsayalım. Bicep dağıtım zamanında zorunlu parametrelerin belirtilmesi gerektiğinden ve var olmayan parametreler için değerlerin ayarlanmasına izin vermediğinden, bunlar hataya neden olan değişikliklere örnek olarak verilebilir. Bu nedenle ana sürüm numarasını güncelleştirebilirsiniz.
Koda yeni bir şey eklediğinizde ancak bu hataya neden olan bir değişiklik olmadığında, ikincil sürüm numarasını artırmanız gerekir. Örneğin, varsayılan değere sahip yeni bir isteğe bağlı parametre eklediğinizi varsayalım. İsteğe bağlı parametreler değişiklikleri bozmaz, bu nedenle ikincil sürüm numarasını güncelleştirmeniz gerekir.
Kodun çalışma biçimini etkilemeyen geriye dönük uyumlu hata düzeltmeleri veya başka değişiklikler yaptığınızda, düzeltme numarasını artırmanız gerekir. Örneğin, değişkenleri ve ifadeleri daha iyi kullanmak için Bicep kodunuzu yeniden düzenlediğinizden emin olun. Yeniden düzenleme, Bicep kodunuzun davranışını hiç değiştirmezse, düzeltme numarasını güncelleştirirsiniz.
İş akışınız düzeltme numarasını da otomatik olarak ayarlayabilir. İş akışının çalıştırma numarası düzeltme numarası olarak kullanılabilir. Bu kural, sürüm numaralarınızın diğer bileşenlerini güncelleştirmeseniz bile sürüm numaralarınızın her zaman benzersiz olmasını sağlamaya yardımcı olur.
Örneğin, başka birinin yayımladığı bir Bicep modülü kullandığınızı varsayalım. Modülün sürüm numarası vardır 2.0.496. Modülün yeni bir sürümünün sürüm numarasıyla 2.1.502kullanılabilir olduğunu görürsünüz. Tek önemli değişiklik, yeni sürümü kullanırken hataya neden olan bir değişiklik beklememeniz gerektiğini gösteren ikincil sürüm numarasıdır.
Dekont
Anlamsal sürüm oluşturma , çok parçalı sürüm oluşturma işlemine benzer resmileştirilmiş bir sürüm oluşturma yapısıdır. Anlamsal sürüm oluşturma, her bileşeni ne zaman ayarlamanız veya sıfırlamanız gerektiğiyle ilgili katı kuralların yanı sıra sürüm numarasında ek bileşenler içerir. Özette anlamsal sürüm oluşturma hakkında daha fazla bilgiye bağlanıyoruz.
Ekibinizin sürüm oluşturma amacıyla hataya neden olan bir değişikliğin nasıl tanımlanacağına karar vermeleri gerekiyor. Örneğin, depolama hesabı dağıtan bir Bicep modülü oluşturduğunuzu varsayalım. Şimdi Depolama hesabınızda özel uç noktaları etkinleştirmek için Bicep dosyasını güncelleştiriyorsunuz. Bicep dosyanıza aynı anda özel bir DNS bölgesi ekliıyorsunuz.
Bu örnekte, Bicep dosyasının parametrelerini veya çıkışlarını etkilemeden değişikliği yapabilirsiniz. Bu şekilde, dosyayı dağıtan herkes herhangi bir şeyin farklı olduğunu fark etmeyebilir. Ancak bu değişiklik, kaynaklarınızın davranışında önemli bir farka neden olduğundan bunu ana sürüm güncelleştirmesi olarak ele almak isteyebilirsiniz.
Ayrıca, yalnızca iş akışının çalıştırma numarasını sürüm numaranız olarak kullanmak gibi daha basit bir sürüm oluşturma stratejisi kullanmayı da seçebilirsiniz. Bu yaklaşımı uygulamak daha kolay olsa da, sürümler arasındaki farkları kodunuzu kullanan herkese etkili bir şekilde iletemezsiniz.
Sürümler ve iş akışları
Kodunuzu etkileşimli olarak yayımladığınızda (örneğin Azure CLI kullanarak) şablon belirtiminize veya modülünüze atadığınız sürüm numarasını büyük olasılıkla düşünürsün. Ancak otomatik dağıtım iş akışında, sürüm numaraları atamak için yaklaşımınızı değiştirmeniz gerekir. İş akışınız hataya neden olan değişiklikleri otomatik olarak algılayamaz veya ana veya ikincil sürüm numaralarınızı ne zaman artırmanız gerektiğini size bildiremez. Şablon belirtimini veya modülünü yayımlamadan önce sürüm oluşturmayı dikkatlice göz önünde bulundurun.
Bir yaklaşım, aşağıdaki diyagramda gösterildiği gibi Bicep kodunuzla bir meta veri dosyası depolamaktır:
Bicep kodunuzu her güncelleştirdiğinizde, ilgili meta veri dosyasındaki sürüm bilgilerini güncelleştirirsiniz. Sürüm numaralarını doğru bir şekilde artırabilmeniz için hataya neden olan ve bölünemeyen değişiklikleri doğru şekilde tanımladığınızdan emin olun.
Bahşiş
Ekibiniz çekme isteklerini kullanarak Bicep kodunuzu gözden geçiriyorsa, gözden geçirenlerden kodunuzda yapılan herhangi bir değişikliğin ana veya ikincil sürüm numaralarınızı değiştirmeyi gerektirip gerektirmediğini doğrulamasını isteyin.
Sonraki alıştırmada meta veri dosyasını nasıl kullanabileceğinizi göreceksiniz.
Kaç iş akışı var?
Şablon belirtimleri ve modüllerinden oluşan bir koleksiyon oluşturmak yaygın bir uygulamadır. Bunları genellikle aynı Git deposunda tutmak mantıklıdır.
GitHub Actions'ta yol filtrelerini kullanarak deponuzdaki her modül veya şablon belirtimi için ayrı iş akışları oluşturabilirsiniz. Bu yaklaşım, bir dosyayı her değiştirdiğinizde depodaki her Bicep dosyasının yeni bir sürümünü yayımlamaktan kaçınmanıza yardımcı olur. yeniden kullanılabilir iş akışlarını kullanarak iş akışınızın adımlarını merkezi bir dosyada tanımlayabilir ve bu sayede her modülün ve şablon belirtimlerinin iş akışı basitliğini korur.
Örneğin, daha önce gösterilene benzer bir dosya yapınız olduğunu varsayalım. Her Bicep dosyası için birer iş akışı olan üç ayrı iş akışı yapılandırabilirsiniz. İlgili iş akışı tanımını ve yol filtresini görmek için her sekmeyi seçin:
name: 'publish-module-1'
on:
push:
branches:
- main
paths:
- 'module-1/**'
jobs:
publish:
uses: ./.github/workflows/publish-module.yml
with:
path: 'module-1/main.bicep'
Yalnızca module-2/main.bicep dosyasını değiştirdiğiniz varsayın. Yalnızca modül 2 için iş akışı çalışır. Ancak aynı işlemedeki birden çok dosyayı değiştirirseniz, ilgili iş akışlarının her biri tetikler.
Dekont
Yeniden kullanılabilir Bicep dosyalarınızın her biri için iş akışı oluşturma yaklaşımı basit ve esnektir. Ancak çok fazla sayıda Bicep dosyanız olduğunda veya her modül ve şablon belirtimi için ayrı iş akışları tutmak istemiyorsanız bu hantal hale gelebilir.
Ayrıca, değiştirilen kodu bulmak ve yalnızca bu dosyaları yayımlamak için iş akışınızda betikler yazabilirsiniz. Bu daha karmaşık bir yaklaşımdır ve bu Microsoft Learn eğitim modülünün kapsamının dışındadır.
Yeniden kullanılabilir Bicep kodu için ortamlar
Azure'a Bicep kullanarak dağıttığınızda, kodunuzu bir üretim ortamında yayımlanmadan önce doğrulamanıza ve test etmeye yardımcı olması için birden çok ortam kullanmak yaygın bir durum olur. Önceki Microsoft Learn eğitim modüllerinde, bir dağıtım iş akışından birden çok ortamla çalışmayı öğrendiniz.
Bazı kuruluşlar, Bicep modüllerine ve şablon özelliklerine aynı ilkeleri uygular. Örneğin, her modülün kullanıcılarının yeni sürümleri deneyebilmesi için önce modüllerinizin yeni sürümlerini üretim dışı bir kayıt defterine yayımlayabilirsiniz. Ardından, bunlar oturumunu kapattıktan sonra modülleri kuruluşunuzun üretim kayıt defterinde yayımlayabilirsiniz.
Normal dağıtımlar gibi işleri ve yeniden kullanılabilir iş akışlarını kullanarak ortamlarınız genelinde dağıtım sırasını tanımlayabilirsiniz. Bu Microsoft Learn eğitim modülünde, iş akışını basit tutmak için tek bir ortamda yayımlıyoruz.
Bir kayıt defterindeki modülleri kullandığınızda veya Bicep modülü olarak bir şablon belirtimi kullandığınızda, diğer adları kullanabilirsiniz. Her modül tanımladığınızda kayıt defteri adını veya şablon belirtiminin konumunu belirtmek yerine diğer adını kullanırsınız.
Diğer adları kullanarak dağıtım sürecinizin birden çok ortamda çalışmasını sağlayabilirsiniz. Örneğin, bir modül tanımlarken kayıt defteri adı yerine diğer ad kullanabilirsiniz. Ardından, eşlenecek diğer adı yapılandırmak için bir dağıtım iş akışı tasarlayabilirsiniz:
- Korumalı alan ortamına dağıtım yaparken geliştirme modülü kayıt defteri.
- Diğer ortamlara dağıtım yaparken üretim kayıt defteri.
Dekont
Diğer adlar yayımladığınızda uygulanmaz. Bunlar yalnızca bir Bicep dosyasında şablon belirtimleri veya modülleri kullandığınızda çalışır.