Azure Data Factory’de sürekli tümleştirme ve teslim

  • Makale

UYGULANANLAR: Azure Data Factory Azure Synapse Analytics

Bahşiş

Kuruluşlar için hepsi bir arada analiz çözümü olan Microsoft Fabric'te Data Factory'yi deneyin. Microsoft Fabric , veri taşımadan veri bilimine, gerçek zamanlı analize, iş zekasına ve raporlamaya kadar her şeyi kapsar. Yeni bir deneme sürümünü ücretsiz olarak başlatmayı öğrenin!

Sürekli tümleştirme, kod tabanınızda 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, çeşitli ADF varlıklarınızın (işlem hatları, veri kümeleri, veri akışları vb.) yapılandırmasını depolamak için Azure Resource Manager şablonlarını kullanır. Bir veri fabrikasını başka bir ortama yükseltmek için önerilen iki yöntem vardır:

Dekont

Azure ile etkileşim kurmak için Azure Az PowerShell modülünü kullanmanızı öneririz. Başlamak için bkz. Azure PowerShell'i yükleme. 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ü

Dekont

Daha fazla bilgi için bkz . Sürekli dağıtım geliştirmeleri.

Aşağıda Azure Repos Git ile yapılandırılmış bir Azure veri fabrikasındaki CI/CD yaşam döngüsüne örnek bir genel bakış verilmiştir. Git deposu yapılandırma hakkında daha fazla bilgi için bkz . Azure Data Factory'de kaynak denetimi.

  1. Azure Repos Git ile bir geliştirme veri fabrikası oluşturulur ve yapılandırılır. Tüm geliştiricilerin işlem hatları ve veri kümeleri gibi Data Factory kaynaklarını yazma izni olmalıdır.

  2. 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ıklarlar. İşlem hattı çalıştırmalarında hata ayıklama hakkında daha fazla bilgi için bkz . Azure Data Factory ile yinelemeli geliştirme ve hata ayıklama.

  3. Bir geliştirici değişikliklerinden memnun olduktan sonra, değişikliklerinin eşler tarafından gözden geçirilmesini sağlamak için özellik dalından ana dal veya işbirliği dalı için bir çekme isteği oluşturur.

  4. Çekme isteği onaylandıktan ve değişiklikler ana dalda birleştirildikten sonra değişiklikler geliştirme fabrikasında yayımlanır.

  5. Ekip, değişiklikleri bir test veya UAT (Kullanıcı Kabul Testi) fabrikasına dağıtmaya hazır olduğunda, 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 görevinin parçası olarak gerçekleşir ve uygun yapılandırmayı uygulamak için Resource Manager şablon parametrelerini kullanır.

  6. Değişiklikler test fabrikasında doğrulandıktan sonra, işlem hatları sürümünün sonraki görevini kullanarak üretim fabrikasına dağıtın.

Dekont

Yalnızca geliştirme fabrikası bir git deposuyla ilişkilendirilir. Test ve üretim fabrikalarının kendileriyle ilişkilendirilmiş bir Git deposu olmamalıdır ve yalnızca Azure DevOps işlem hattı veya Kaynak Yönetimi şablonu aracılığıyla güncelleştirilmelidir.

Aşağıdaki görüntüde bu yaşam döngüsünün farklı adımları vurgulanır.

Diagram of continuous integration with Azure Pipelines

CI/CD için en iyi yöntemler

Veri fabrikanızla Git tümleştirmesi kullanıyorsanız ve değişikliklerinizi geliştirme aşamasından teste ve ardından üretime taşıyan 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ırın. Test ve üretim değişiklikleri CI/CD aracılığıyla dağıtılır ve Git tümleştirmesi gerekmez.

  • Dağıtım öncesi ve sonrası betiği. CI/CD'deki Resource Manager dağıtım adımından önce tetikleyicileri durdurma ve yeniden başlatma ve temizleme gerçekleştirme gibi belirli görevleri tamamlamanız gerekir. Dağıtım görevinden önce ve sonra PowerShell betikleri kullanmanızı öneririz. Daha fazla bilgi için bkz . Etkin tetikleyicileri güncelleştirme. Veri fabrikası ekibi, bu sayfanın en altında bulunan bir betik sağladı.

    Dekont

    CI/CD sırasında tüm tetikleyicileri kapatmak/ açmak yerine yalnızca değiştirilmiş tetikleyicileri kapatmak/ açmak istiyorsanız PrePostDeploymentScript.Ver2.ps1 kullanın.

    Uyarı

    Betiği çalıştırmak için ADO görevinde PowerShell Core kullandığınızdan emin olun.

    Uyarı

    PowerShell ve Data Factory modülünün en son sürümlerini kullanmıyorsanız, komutları çalıştırırken seri durumdan çıkarma hatalarıyla karşılaşabilirsiniz.

  • Tümleştirme çalışma zamanları ve paylaşım. Tümleştirme çalışma zamanları sık değişmez ve CI/CD'nizdeki tüm aşamalarda benzerdir. Bu nedenle Data Factory, CI/CD'nin tüm aşamalarında aynı ada, türe ve alt tür tümleştirme çalışma zamanına sahip olduğunuzu bekler. Tümleştirme çalışma zamanlarını tüm aşamalarda paylaşmak istiyorsanız, yalnızca paylaşılan tümleştirme çalışma zamanlarını içermek için bir üçüncül fabrika kullanmayı göz önünde bulundurun. Bu paylaşılan fabrikayı tüm ortamlarınızda bağlı tümleştirme çalışma zamanı türü olarak kullanabilirsiniz.

    Dekont

    Tümleştirme çalışma zamanı paylaşımı yalnızca şirket içinde barındırılan tümleştirme çalışma zamanları için kullanılabilir. Azure-SSIS tümleştirme çalışma zamanları paylaşımı desteklemez.

  • Yönetilen özel uç nokta dağıtımı. Bir fabrikada özel uç nokta zaten varsa ve aynı ada sahip ancak değiştirilmiş özelliklere sahip bir özel uç nokta içeren bir ARM şablonu dağıtmaya çalışırsanız, dağıtım başarısız olur. Diğer bir deyişle fabrikada zaten mevcut olan özel uç noktayla aynı özelliklere sahip olduğu sürece, bir özel uç noktayı başarıyla dağıtabilirsiniz. Ortamlar arasında herhangi bir özellik farklıysa, bu özelliği parametreleştirerek ve dağıtım sırasında ilgili değeri sağlayarak geçersiz kılabilirsiniz.

  • Key Vault. Bağlantı bilgileri Azure Key Vault'ta depolanan bağlı hizmetleri kullandığınızda, farklı ortamlar için ayrı anahtar kasaları bulundurmanız önerilir. Ayrıca her anahtar kasası için ayrı izin düzeyleri yapılandırabilirsiniz. Örneğin, ekip üyelerinizin üretim gizli dizileri için izinleri olmasını istemeyebilirsiniz. Bu yaklaşımı izlerseniz, tüm aşamalarda aynı gizli dizi adlarını tutmanızı öneririz. Aynı gizli dizi adlarını saklarsanız, ci/CD ortamlarında her bağlantı dizesi parametrelemeniz gerekmez çünkü değişen tek şey anahtar kasası adıdır ve bu da ayrı bir parametredir.

  • Kaynak adlandırma. ARM şablonu kısıtlamaları nedeniyle, kaynaklarınız adında boşluklar varsa dağıtımda sorunlar ortaya çıkabilir. Azure Data Factory ekibi, kaynaklar için boşluklar yerine '_' veya '-' karakterlerini kullanmanızı önerir. Örneğin, 'Pipeline_1', 'İşlem Hattı 1' yerine tercih edilebilir bir ad olabilir.

  • Depo değiştiriyor. ADF, GIT deposu içeriğini otomatik olarak yönetir. ADF Git deposu veri klasörünün herhangi bir yerine el ile ilişkisiz dosyaları veya klasörü değiştirmek veya eklemek kaynak yükleme hatalarına neden olabilir. Örneğin, .bak dosyalarının varlığı ADF CI/CD hatasına neden olabilir, bu nedenle ADF'nin yüklenmesi için bunların kaldırılması gerekir.

  • Pozlama denetimi ve özellik bayrakları. Ekipte çalışırken, değişiklikleri birleştirebileceğiniz ancak BUNLARıN PROD ve QA gibi yükseltilmiş ortamlarda çalıştırılmasını istemediğiniz örnekler vardır. Bu senaryoyu işlemek için ADF ekibi, özellik bayraklarını kullanma DevOps kavramını önerir. ADF'de genel parametreleri ve if koşulu etkinliğini birleştirerek bu ortam bayraklarını temel alan mantık kümelerini gizleyebilirsiniz.

    Özellik bayrağını ayarlamayı öğrenmek için aşağıdaki video öğreticisine bakın:

Desteklenmeyen özellikler

  • Data Factory, tasarım gereği işlemelerin tek tek toplanması veya kaynakların seçmeli olarak yayımlanmasına izin vermez. Yayımlamalar, veri fabrikasında yapılan tüm değişiklikleri içerir.

    • Veri fabrikası varlıkları birbirine bağlıdır. Örneğin tetikleyiciler işlem hatlarına, işlem hatları ise veri kümelerine ve diğer işlem hatlarına bağlıdır. Kaynakların bir alt kümesinin seçmeli olarak yayımlanması beklenmeyen davranışlara ve hatalara yol açabilir.
    • Seçmeli yayımlamaya ihtiyaç duyduğunuz nadir durumlarda bir düzeltme kullanmayı göz önünde bulundurun. Daha fazla bilgi için bkz . Düzeltme üretim ortamı.

  • Azure Data Factory ekibi, bir veri fabrikasındaki tek tek varlıklara (işlem hatları, veri kümeleri vb.) Azure RBAC denetimleri atamanızı önermez. Ö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 gerektiğini düşünüyorsanız ikinci bir veri fabrikası dağıtma bölümüne bakın.

  • Özel dallardan yayımlayamazsınız.

  • Şu anda Bitbucket'te proje barındıramazsınız.

  • Şu anda uyarıları ve matrisleri parametre olarak dışarı ve içeri aktaramazsınız.

  • adf_publish dalının altındaki kod deposunda, kaynak denetimiyle yayımlamanın bir parçası olarak şu anda 'linkedTemplates' klasörünün , 'ARMTemplateForFactory.json' ve 'ARMTemplateParametersForFactory.json' dosyalarının yanına 'PartialArmTemplates' adlı bir klasör eklenmiştir.

    Diagram of 'PartialArmTemplates' folder.

    1 Kasım 2021'den itibaren 'PartialArmTemplates'i adf_publish dalına yayımlamayacağız.

    'PartialArmTemplates' kullanmıyorsanız hiçbir eylem gerekmez. Aksi takdirde, 'ARMTemplateForFactory.json' veya 'linkedTemplates' dosyalarını kullanarak dağıtımlar için desteklenen herhangi bir mekanizmaya geçin.

İlgili içerik