Dallanmayı anlama
Bicep şablonları derleyip bir Git deposunda çalıştığınızda, ekibinizin tüm değişiklikleri sonunda deponuzun ana dalı ile birleştirilir. Üretim ortamınıza istenmeyen değişiklikler dağıtılmaması için ana dalı korumak önemlidir. Ancak katkıda bulunanlarınızın esnek bir şekilde çalışabilmesini, ekibinizle işbirliği yapabilmesini ve fikirleri kolayca denemesini istiyorsunuz.
Bu ünitede dallanma stratejileri ve ana dalı koruma hakkında bilgi edineceksiniz. Ayrıca dallarınız için bir gözden geçirme işlemi ayarlamayı da öğreneceksiniz.
Ana dalı neden korumak istiyorsunuz?
Ana dal, Azure ortamlarınıza dağıtılanların gerçek kaynağıdır. Birçok çözüm için geliştirme, kalite güvencesi (QA) ve üretim gibi birden çok ortamınız olacaktır. Diğer senaryolarda yalnızca bir üretim ortamınız olabilir. Kaç ortam kullandığınızdan bağımsız olarak, ana dal, ekip üyelerinizin katkıda bulunduğu daldır. Onların değişiklikleri nihai olarak ana dala iner.
Tipik bir işlem aşağıdaki gibi olabilir:
- Ekip üyesi paylaşılan deponuzu klonlar.
- Deponun kendi yerel kopyasındaki bir dalda yerel değişiklikler yapar.
- Değişiklikleri tamamladıktan sonra bu değişiklikleri yerel depolarının ana dalında birleştirir.
- Bu değişiklikleri uzak deponun ana dalına gönderiyorlar.
- Bazı senaryolarda, uzak deponun gönderimi kodu doğrulamak, test etmek ve dağıtmak için otomatik bir işlem hattı tetikler. Diğer Microsoft Learn modüllerindeki işlem hatları hakkında daha fazla bilgi edineceksiniz.
Aşağıdaki diyagramda bu işlem gösterilmektedir:
Ekip üyesinin değişikliklerinin küçük bir hataya neden olduğunu varsayalım. İşlem tamamlandıktan sonra hata artık projenin ana dalındadır ve üretime dağıtılır. Dağıtmayı deneyip bir hata alıncaya kadar bulmayabilirsiniz. Veya diğer hata türleri için dağıtım başarılı olabilir, ancak daha sonra küçük sorunlara neden olabilir.
Başka bir senaryoda, bir ekip üyesinin bir özellik üzerinde çalıştığını ve özelliğin tamamlanan çalışmasının yarısını paylaşılan deponun ana dalına göndererek tamamladığınızı varsayalım. Artık ana dalda tamamlanmamış veya test edilmiş değişiklikleriniz var. Bu değişiklikler büyük olasılıkla üretim ortamınıza dağıtılmamalıdır. Özellik tamamlanana kadar üretim dağıtımlarının engellenmesi gerekebilir. Yeni tamamlanan özellikler ana dalda yer alıyorsa, bunları müşterilerinize dağıtamayabilirsiniz.
İpucu
Bu sorunlar, birden çok kişinin aynı koda katkıda bulunduğu büyük ekipler için özellikle zordur, ancak birden fazla kişiyle işbirliği yaptığınız anda bu modüldeki rehberlik değerlidir. Yalnızca bir proje üzerinde çalışıyor olsanız ve aynı anda birden çok özellik üzerinde çalışıyor olsanız bile kılavuz değerlidir.
Üzerinde çalışırken değişikliklerinizi ayrı tutmak daha iyi bir çalışma yöntemidir. Daha sonra, başka bir ekip üyesinin değişiklikleri ekibinizin paylaşılan deposunun ana dalı ile birleştirilmeden önce gözden geçirmesini sağlayabilirsiniz. Bu işlem, bir değişikliğin birleştirilmesini onaylamadan önce ekibinizin bilinçli bir karar vermesine yardımcı olur.
Özellik dalları
Özellik dalı , başladığınız yeni bir çalışma parçasını gösterir. Çalışma, Bicep dosyanızda tanımlanan bir kaynakta yapılan yapılandırma değişikliği veya dağıtmanız gereken yeni bir kaynak kümesi olabilir. Her yeni iş parçası başlattığınızda yeni bir özellik dalı oluşturursunuz.
Ana daldan bir özellik dalı oluşturursunuz. Bir dal oluşturduğunuzda, Azure ortamınızın geçerli durumundan başladığınızdan emin olun. Ardından tüm gerekli değişikliklerinizi yaparsınız.
Kod değişikliklerinin tümü özellik dalı için işlendiği için deponun ana dalını engellemez. Ekibinizdeki başka birinin ana dalda acil bir değişiklik yapması gerekiyorsa, bunu sizinkilerden bağımsız başka bir özellik dalında yapabilir.
Özellik dalları üzerinde de işbirliği yapabilirsiniz. Özellik dalınızı yayımlayıp paylaşılan depoya göndererek, siz ve ekip üyeleriniz bir değişiklik üzerinde birlikte çalışabilirsiniz. Ayrıca, tatile çıktığınızda tamamlanması için bir özelliği başka birine de devredebilirsiniz.
Özellik dallarınızı güncelleştirme
Özellik dalınız devam ederken, diğer özellikler deponuzun ana dalı ile birleştirilebilir. Sonuç olarak özellik dalınız ve projenizin ana dalı birbirinden ayrılır. Ne kadar uzaklaşırlarsa, daha sonraki bir noktada iki dalı yeniden birleştirmek o kadar zorlaşır ve daha fazla birleştirme çakışmasıyla karşılaşabilirsiniz.
Deponun ana dalında yapılan değişiklikleri dahil etmek için özellik dalınızı düzenli olarak güncelleştirmeniz gerekir. Özellik dalını ana dalla birleştirmeye başlamadan önce özellik dalınızı güncelleştirmeniz de iyi bir fikirdir. Bu şekilde, yeni değişikliklerinizin ana dalda kolayca birleştirilebildiğinden emin olursunuz.
İpucu
Ana dalı sık sık özellik dalınızla birleştirin.
Küçük, kısa süreli dallar kullanma
Kısa süreli özellik dallarını hedefleyin. Bu yaklaşım, dallarınızın eşitlemeden çıkma süresini azaltarak birleştirme çakışmalarını önlemenize yardımcı olur. Bu yaklaşım, iş arkadaşlarınızın yaptığınız değişiklikleri anlamasını da kolaylaştırır. Bu, birisinin değişikliklerinizi gözden geçirmesi gerektiğinde yararlı olur.
Büyük iş parçalarını daha küçük parçalara ayırın ve her biri için bir özellik dalı oluşturun. Özellik ne kadar büyükse, birinin bu özellik üzerinde o kadar uzun çalışması gerekir ve özellik dalı o kadar uzun süre yaşar. Her özellik dalını birleştirip daha geniş bir çalışmayı kademeli olarak oluştururken daha küçük değişiklikleri üretime dağıtabilirsiniz.
Bicep kodu kümesinde bazı değişiklikler yaptığınız düşünün. Bazı kaynak tanımlarını modüllere taşıyorsunuz. Ayrıca Bicep dosyalarınıza bazı yeni kaynaklar eklemeniz gerekir. Modülünüzü yeniden düzenleme işleminin tamamını önce kendi dalında yapmak iyi bir fikir olabilir. Modüller birleştirildikten sonra, Bicep dosyalarınıza yapılan eklemeler üzerinde çalışmaya başlayabilirsiniz. Değişikliklerinizi ayırarak, her değişikliği (ve dalını) küçük ve anlaşılması kolay bir şekilde tutarsınız.
Bu şekilde çalışırken, kaynakları dağıtmayı hazır olana kadar devre dışı bırakmak için anahtar sözcüğünü if kullanmak yararlı olabilir. Aşağıdaki örnek kodda, anahtar sözcüğünü if kullanarak depolama hesabını tanımlayan ancak tüm değişiklikleri tamamlayana kadar depolama hesabının dağıtımını devre dışı bırakan bir Bicep dosyası oluşturma işlemi gösterilmektedir.
@description('Specifies whether the storage account is ready to be deployed.')
param storageAccountReady bool = false
resource storageAccount 'Microsoft.Storage/storageAccounts@2022-09-01' = if (storageAccountReady) {
name: storageAccountName
location: location
kind: 'StorageV2'
sku: {
name: 'Premium_LRS'
}
}
Parametreleri kullanarak farklı ortamlardaki değişken için storageAccountReady farklı değerler belirtebilirsiniz. Örneğin, parametre değerini true test ortamınız ve false üretim ortamınız için olarak ayarlayabilirsiniz. Bu şekilde, test ortamınızda yeni depolama hesabını deneyebilirsiniz.
Not
Özelliği üretim ortamında etkinleştirme zamanı geldiğinde, değişikliğinizin geçerli olması için aşağıdaki adımları uygulamanız gerektiğini unutmayın:
- Parametre değerini değiştirin.
- Bicep dosyanızı yeniden dağıt.
Özellik dallarını birleştirme
Bir özellik dalı üzerinde çalışmayı bitirdiğinizde, bunu deponuzun ana dalı ile birleştirmeniz gerekir. Birleştirmeden önce özellik dalında yapılan değişiklikleri gözden geçirmek iyi bir uygulamadır. Çekme istekleri kodunuzu gözden geçirmenizi sağlar. Bu modülün ilerleyen bölümlerinde çekme istekleri hakkında daha fazla bilgi edineceksiniz.
Dal korumaları
GitHub'da, paylaşılan deponun ana dalı için dal korumaları yapılandırabilirsiniz. Dal korumaları aşağıdaki gibi kuralları zorunlu kılar:
- Çekme isteği dışında ana dalda hiçbir değişiklik birleştirilemiyor.
- Değişikliklerin en az iki kişi daha tarafından gözden geçirilmesi gerekir.
Birisi bir işlemeyi doğrudan korumalı bir dala göndermeye çalışırsa gönderme başarısız olur. Bir sonraki ünitede dal korumalarının nasıl uygulanacağını öğreneceksiniz.
Dal ilkeleri
Azure DevOps'ta, paylaşılan deponun ana dalı için dal ilkelerini yapılandırabilirsiniz. Dal ilkeleri aşağıdaki gibi kuralları zorunlu kılar:
- Çekme isteği dışında ana dalda hiçbir değişiklik birleştirilemiyor.
- Değişikliklerin en az iki kişi daha tarafından gözden geçirilmesi gerekir.
Birisi bir işlemeyi doğrudan korumalı bir dala göndermeye çalışırsa gönderme başarısız olur. Bir sonraki ünitede dal ilkelerinin nasıl uygulanacağını öğreneceksiniz.
Diğer dallanma stratejileri
Bicep kodunuz üzerinde işbirliği yaptığınızda çeşitli dallanma stratejilerini kullanabilirsiniz. Her dallanma stratejisinin avantajları ve dezavantajları vardır.
Şimdiye kadar öğrendiğiniz süreç, gövde tabanlı geliştirme stratejisinin bir sürümüdür. Bu dallanma stratejisinde, kısa süreli özellik dallarında çalışma yapılır ve ardından tek bir ana dalda birleştirilir. Paylaşılan deponun ana dalının içeriğini her değişiklik birleştirildiğinde üretime otomatik olarak dağıtabilir veya her hafta olduğu gibi değişiklikleri toplu olarak işleyip zamanlamaya göre serbest bırakabilirsiniz. Gövde tabanlı geliştirmeyi anlamak kolaydır ve çok fazla ek yük olmadan işbirliğine olanak tanır.
Bazı ekipler, tamamladıkları işi üretim ortamına dağıtılan çalışmadan ayırır. Özellik dallarını birleştirmek için hedef olarak uzun süreli bir geliştirme dalı kullanırlar. Üretimde değişiklik yaptıklarında geliştirme dalını ana dallarıyla birleştirirler.
Diğer bazı dallanma stratejileri için yayın dalları oluşturmanız gerekir. Üretime dağıtmaya hazır bir dizi değişikliğiniz olduğunda, dağıtılacak değişiklikleri içeren bir yayın dalı oluşturursunuz. Bu stratejiler, Azure altyapınızı düzenli bir tempoda dağıttığınızda veya değişikliklerinizi diğer birçok ekiple tümleştirdiğinizde anlamlı olabilir.
Diğer dallanma stratejileri arasında Gitflow, GitHub Flow ve GitLab Flow yer alır. Bazı ekipler GitHub Flow veya GitLab Flow kullanır çünkü çalışmaları farklı ekiplerden ayırmaya ve acil hata düzeltmelerini diğer değişikliklerden ayırmaya olanak tanır. Bu işlemler, işlemelerinizi çözümünüzün kiraz toplama olarak adlandırılan farklı sürümlerine ayırmanızı da sağlayabilir. Ancak, değişikliklerinizin birbiriyle uyumlu olduğundan emin olmak için daha fazla yönetime ihtiyaç duyarlar. Bu modülün Özet bölümü, bu dallanma stratejileri hakkında daha fazla bilgi için bağlantılar sağlar.
Ekibiniz için doğru olan dallanma stratejisi, ekibinizin çalışma, işbirliği yapma ve değişikliklerini yayınlama şekline bağlıdır. Gövde tabanlı geliştirme gibi basit bir işlemden başlamak iyi bir fikirdir. Ekibinizin bu süreci kullanarak etkili bir şekilde çalışamadığını fark ederseniz, diğer dallanma katmanlarını aşamalı olarak tanıtın veya bir dallanma stratejisi benimseyin; ancak daha fazla dal eklediğinizde deponuzu yönetmenin daha karmaşık hale geldiğini unutmayın.
İpucu
Kullandığınız dallanma stratejisinden bağımsız olarak, ana dalı korumak ve değişikliklerinizi gözden geçirmek için çekme isteklerini kullanmak için dal ilkelerini kullanmak iyidir. Diğer dallanma stratejileri, korumanız gereken önemli dalları da tanıtır.
Bu modülde özellik dallarıyla gövde tabanlı geliştirmeyi kullanacağız çünkü kullanımı kolaydır.