Azure Data Factory’de sürekli tümleştirme ve teslim
AŞAĞıDAKILER IÇIN GEÇERLIDIR: 
Azure Data Factory 
Azure Synapse Analytics
Sürekli tümleştirme, kod tabanınıza yapılan her değişikliği otomatik olarak ve mümkün olan en erken zamanda test etme uygulamasıdır. Sürekli teslim, sürekli tümleştirme sırasında yapılan testleri izler ve değişiklikleri hazırlama veya üretim sistemine gönderir.
Azure Data Factory'de sürekli tümleştirme ve sürekli teslim (CI/CD) Data Factory işlem hatlarını bir ortamdan (geliştirme, test, üretim) diğerine taşıma anlamına gelir. Azure Data Factory, Azure Resource Manager ADF varlıklarının (işlem hatları, veri kümeleri, veri akışları vb.) yapılandırmasını depolamak için farklı şablonlardan faydalanıyor. Bir veri fabrikasını başka bir ortama tanıtmak için önerilen iki yöntem vardır:
- Data Factory'nin Azure Pipelines kullanarak otomatik dağıtım
- Resource Manager UX tümleştirmesi kullanarak Data Factory el ile Azure Resource Manager.
Not
Bu makalede, Azure ile etkileşim kurmak için önerilen PowerShell modülü olan Azure Az PowerShell modülü kullanılır. Az PowerShell modülünü kullanmaya başlamak için Azure PowerShell’i yükleyin. Az PowerShell modülüne nasıl geçeceğinizi öğrenmek için bkz. Azure PowerShell’i AzureRM’den Az’ye geçirme.
CI/CD yaşam döngüsü
Aşağıda, Git ile yapılandırılmış bir Azure veri fabrikasında CI/CD yaşam döngüsüne örnek bir Azure Repos verilmiştir. Git deposunu yapılandırma hakkında daha fazla bilgi için bkz.Azure Data Factory.
Git ile bir geliştirme veri fabrikası oluşturulur ve Azure Repos yapılandırılır. Tüm geliştiricilerin işlem hatları ve veri kümeleri Data Factory kaynakları yazma iznine sahip olması gerekir.
Geliştirici değişiklik yapmak için bir özellik dalı oluşturur. en son değişiklikleriyle işlem hattı çalıştırmalarında hata ayıklar. bir işlem hattı çalıştırması hata ayıklama hakkında daha fazla bilgi için bkz. Azure Data Factory .
Bir geliştirici, değişikliklerinden memnun kaldıktan sonra, değişikliklerini eşler tarafından gözden geçirmek için özellik dallarından ana veya işbirliği dala bir çekme isteği oluşturabilir.
Çekme isteği onaylandıktan ve değişiklikler ana dalda birleştirdikten sonra değişiklikler geliştirme fabrikasında yayımlanır.
Takım değişiklikleri bir test veya UAT (Kullanıcı Kabul Testi) fabrikasına dağıtmaya hazır olduğunda, takım kendi Azure Pipelines sürümüne gider ve geliştirme fabrikasının istenen sürümünü UAT'ye dağıtır. Bu dağıtım, bir Azure Pipelines parçası olarak yapılır ve uygun Resource Manager uygulamak için şablon parametrelerini kullanır.
Değişiklikler test fabrikasında doğrulandıktan sonra, işlem hatları yayınlarının sonraki görevini kullanarak üretim fabrikasına dağıtın.
Not
Yalnızca geliştirme fabrikası bir git deposuyla ilişkilendirildi. Test ve üretim fabrikalarının kendileriyle ilişkilendirilmiş bir git deposu olmaması ve yalnızca bir Azure DevOps işlem hattı veya Kaynak Yönetimi şablonu aracılığıyla güncelleştirilmiş olması gerekir.
Aşağıdaki görüntüde bu yaşam döngüsünün farklı adımları vurgulanmıştır.
CI/CD için en iyi yöntemler
Veri fabrikanız ile Git tümleştirmesi kullanıyorsanız ve değişikliklerinizi geliştirme aşamasından teste ve ardından üretime aktaran bir CI/CD işlem hattınız varsa şu en iyi yöntemleri öneririz:
Git tümleştirmesi. Git tümleştirmesi ile yalnızca geliştirme veri fabrikanızı yapılandırma. Test ve üretim değişiklikleri CI/CD aracılığıyla dağıtılır ve Git tümleştirmesi gerektirmektedir.
Dağıtım öncesi ve sonrası betiği. CI/CD Resource Manager dağıtım adımını tamamlamadan önce tetikleyicileri durdurma, yeniden başlatma ve temizleme gerçekleştirme gibi belirli görevleri tamamlamanız gerekir. Dağıtım görevi öncesinde ve sonrasında PowerShell betiklerini kullanmanızı öneririz. Daha fazla bilgi için bkz. Etkin tetikleyicileri güncelleştirme. Veri fabrikası ekibi, bu sayfanın alt kısmında bulunan bir betik sağladı.
Tümleştirme çalışma zamanları ve paylaşımı. Tümleştirme çalışma zamanları sık değişmez ve CI/CD'nizin tüm aşamalarına benzer. Bu Data Factory, CI/CD'nin tüm aşamalarında aynı ad ve tümleştirme çalışma zamanı türüne sahip olmasını bekler. Tümleştirme çalışma zamanlarını tüm aşamalarda paylaşmak için yalnızca paylaşılan tümleştirme çalışma zamanlarını içeren bir üçüncül fabrika kullanmayı göz önünde bulundurabilirsiniz. Bu paylaşılan fabrikayı tüm ortamlarınızı bağlantılı tümleştirme çalışma zamanı türü olarak kullanabilirsiniz.
Yönetilen özel uç nokta dağıtımı. Bir fabrika içinde özel uç nokta zaten varsa ve aynı adla ancak değiştirilmiş özelliklere sahip özel uç nokta içeren bir ARM şablonu dağıtmayı denersiniz, dağıtım başarısız olur. Başka bir deyişle, fabrikada zaten mevcut olanla aynı özelliklere sahip olduğu sürece bir özel uç noktayı başarıyla dağıtabilirsiniz. Ortamlar arasında farklı bir özellik varsa, bu özelliği parametreleştirerek ve dağıtım sırasında ilgili değeri sağlayarak bu özelliği geçersiz kılabilirsiniz.
Key Vault. Bağlantı bilgileri farklı ortamlarda depolanan bağlı hizmetleri Azure Key Vault, farklı ortamlar için ayrı anahtar kasaları tutmanız önerilir. Ayrıca her anahtar kasası için ayrı izin düzeyleri de yapılandıramazsınız. Örneğin, ekip üyelerinizin üretim gizli dizilerine izinler atamalarını istemeyebilirsiniz. Bu yaklaşımı benimsersiniz, tüm aşamalarda aynı gizli adları tutmanı öneririz. Aynı gizli dizi adlarını alıyorsanız, her bağlantı dizesini CI/CD ortamlarında parametreleştirmeniz gerekli değildir çünkü tek değişiklik anahtar kasası adıdır ve bu ayrı bir parametredir.
Kaynak adlandırması. ARM şablonu kısıtlamaları nedeniyle, kaynaklarınız adda boşluklar içeriyorsa dağıtımda sorunlar ortaya çıkabilir. Azure Data Factory ekibi, kaynaklar için boşluk yerine "_" veya "-" karakterlerin kullanılması önerisinde bulunmaktadır. Örneğin, 'Pipeline_1', 'Pipeline 1' (İşlem Hattı 1) için tercih edilen bir ad olabilir.
Maruz kalma denetimi ve özellik bayrakları. Ekip üzerinde çalışırken, değişiklikleri birleştirebilirsiniz ancak prod ve QA gibi yükseltilmiş ortamlarda çalıştırılamalarını istemeyebilirsiniz. Bu senaryoyu işlemek için ADF ekibi, özellik bayraklarını DevOps kavramlarını kullanmayı öneriyor. ADF'de, bu ortam bayraklarına göre mantık kümelerini gizlemek için genel parametreleri ve if koşulu etkinliğini birleştirin.
Özellik bayrağı ayarlamayı öğrenmek için aşağıdaki video öğreticiye bakın:
Desteklenmeyen özellikler
Tasarıma göre Data Factory işlemelerin tek tek seçimine veya kaynakların seçmeli olarak yayım sınanmasına izin vermez. Yayımlar, veri fabrikasında yapılan tüm değişiklikleri içerir.
- Veri fabrikası varlıkları birbirine bağımlıdır. Örneğin, tetikleyiciler işlem hatlarına, işlem hatları ise veri kümelerini ve diğer işlem hatlarını bağımlıdır. Kaynakların bir alt kümesinin seçmeli olarak yayım olması beklenmeyen davranışlara ve hatalara neden olabilir.
- Seçmeli yayımlamaya ihtiyacınız olan nadir durumlarda bir düzeltme kullanmayı göz önünde bulundurmalısınız. Daha fazla bilgi için bkz. Düzeltme üretim ortamı.
Azure Data Factory ekibi, bir veri fabrikasında tek tek varlıklara (işlem hatları, veri kümeleri vb.) Azure RBAC denetimleri atamayı önerilmez. Örneğin geliştiricinin bir işlem hattına veya veri kümesine erişimi varsa, veri fabrikasındaki tüm işlem hatlarına veya veri kümelerine erişebilmelidir. Bir veri fabrikasında birçok Azure rolü uygulamanızın gerekli olduğunu biliyorsanız ikinci bir veri fabrikası dağıtmaya bakın.
Özel dallardan yayımlayam diye bir şey yok.
Şu anda Bitbucket'te projeleri barındıraz.
Şu anda uyarıları ve matrisleri parametre olarak dışarı ve içeri aktara sıralayamzın.
adf_publish dalın altındaki kod deposunda, kaynak denetimiyle yayımlamanın bir parçası olarak 'linkedTemplates' klasörünün yanına 'PartialArmTemplates' adlı bir klasör, 'ARMTemplateForFactory.json' ve 'ARMTemplateParametersForFactory.json' dosyaları eklenmiştir.
1 Kasım 2021'den başlayarak 'PartialArmTemplates' adf_publish artık yayımlamayacak.
'PartialArmTemplates' kullanmadıkça herhangi bir eylem gerekmez. Aksi takdirde, 'ARMTemplateForFactory.json' veya 'linkedTemplates' dosyalarını kullanarak dağıtımlar için desteklenen herhangi bir mekanizmaya geçiş.