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

ŞUNLARA UYGULANIR: Azure Data Factory Azure Synapse Analytics

İpucu

Microsoft Fabric'daki Data Factory, daha basit bir mimariye, yerleşik yapay zekaya ve yeni özelliklere sahip yeni nesil Azure Data Factory. Veri tümleştirmeyi yeni kullanmaya başladıysanız Fabric Data Factory ile başlayın. Mevcut ADF iş yükleri veri bilimi, gerçek zamanlı analiz ve raporlama genelinde yeni özelliklere erişmek için Fabric yükseltebilir.

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 teslimat, sürekli tümleştirme sırasında yapılan testleri takip eder ve değişiklikleri hazırlık veya üretim sistemine iletir.

Azure Data Factory sürekli tümleştirme ve 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 Data Factory varlıklarınızın (örneğin boru hatları, veri setleri ve veri akışları) 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:

  • Data Factory'nin Azure Pipelines ile entegrasyonu kullanılarak otomatik dağıtım
  • Azure Kaynak Yöneticisi ile Data Factory UX entegrasyonunu kullanarak bir Kaynak Yöneticisi şablonunu elle yükleyin.

Not

Azure ile etkileşime geçmek için Azure Az PowerShell modülünü kullanmanızı öneririz. Başlamak için bkz. Azure PowerShell yükleme. Az PowerShell modülüne nasıl geçiş yapılacağını öğrenmek için bkz. AzureRM'den Az Azure PowerShell dağıtma.

CI/CD yaşam döngüsü

Not

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

Aşağıdaki genel bakış, Azure Repos Git ile yapılandırılmış bir Azure veri fabrikasında CI/CD yaşam döngüsünü göstermektedir. Git deposunu yapılandırma hakkında daha fazla bilgi için bkz. Azure Data Factory'de Kaynak Kontrolü.

  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. İmzalı commitler veri fabrikasında desteklenmiyor. 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 İteratif 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. Pull request onaylandıktan ve değişiklikler ana dalda birleştirildikten sonra değişiklikler geliştirme ortamı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, Azure Pipelines bir görevin 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.

Not

Yalnızca geliştirme fabrikası bir git deposuyla ilişkilendirilir. Test ve üretim fabrikalarının ilişkili 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ü, bu yaşam döngüsünün farklı adımlarını vurgulamaktadır.

Azure Pipelines ile sürekli entegrasyonun diyagramı.

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 entegrasyonu. 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ı komut dosyası. CI/CD'de 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ı.

    Not

    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'in en son sürümlerini ve Data Factory modülünü kullanmıyorsanız, komutları çalıştırırken deserileştirme hatalarına rastlayabilirsiniz.

  • 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 yüzden Data Factory, CI/CD'nin tüm aşamalarında aynı isim, tür ve alt türde entegrasyon çalışma zamanına sahip olmanızı bekliyor. 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.

    Not

    Tümleştirme çalışma zamanı paylaşımı yalnızca kullanıcı tarafından 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 saklanan bağlı hizmetleri kullandığınızda, farklı ortamlar için ayrı anahtar kasaları tutun. Ayrıca her anahtar kasası için ayrı izin düzeyleri yapılandırabilirsiniz. Örneğin, ekip üyelerinizin üretim sırları için izinleri olmasını istemeyebilirsiniz. Bu yaklaşımı takip ederseniz, tüm aşamalarda aynı gizli isimleri koruyun. Aynı gizli adları saklarsanız, CI/CD ortamlarında her bağlantı dizesini parametrelemeniz gerekmez çünkü değişen tek şey anahtar deposu adıdır ve bu da ayrı bir parametredir.

  • Kaynak adlandırma. ARM şablon kısıtlamaları nedeniyle, kaynaklarınızda isimde boşluk bulunursa 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' 'Pipeline 1' yerine tercih edilen bir isimdir.

  • Depo değiştiriliyor. Azure Data Factory (ADF) Git repository content'i otomatik yönetir. ADF Git depo veri klasörünün herhangi bir yerine manuel olarak alakasız dosya veya klasörleri değiştirmek veya eklemek kaynak yükleme hatalarına yol açabilir. Örneğin, .bak dosyaların varlığı ADF CI/CD hatasına neden olabilir, bu yüzden ADF'nin yüklenmesi için onları kaldırın.

  • Pozlama denetimi ve özellik bayrakları. Bir ekip içinde çalışırken, değişiklikleri birleştirebileceğiniz ama bunların üretim (PROD) ve kalite güvencesi (QA) gibi yükseltilmiş ortamlarda çalışmasını istemediğiniz durumlar olabilir. 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ğı nasıl ayarlanacağını öğrenmek için aşağıdaki video eğitimine bakabilirsiniz:

Desteklenmeyen özellikler

  • Tasarım gereği, Data Factory seçici taahhütleri veya kaynakların seçici yayımlanmasını desteklemiyor. Yayıncılık, 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 acil bir düzeltme kullanmayı düşünün. Daha fazla bilgi için bkz. Hotfix üretim ortamı.

  • Azure Data Factory ekibi, bir veri fabrikasındaki bireysel varlıklara (örneğin boru hatları ve veri setleri) Azure RBAC kontrollerinin atamasını önermiyor. Ö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. Veri fabrikası içinde birçok Azure rolünü uygulamanız gerektiğini düşünüyorsanız, ikinci bir veri fabrikası dağıtmayı göz önünde bulundurun.

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

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

  • Şu anda uyarıları ve metrikleri parametre olarak dışa aktarıp aktaramıyorsun.

  • Yayımlama dalınızın kısmi ARM şablonları artık 1 Kasım 2021'den itibaren desteklenmez. Projeniz bu özelliği kullanıyorsa, veya dosyalarını kullanarak dağıtım ARMTemplateForFactory.jsonlinkedTemplates için desteklenen bir mekanizmaya geçin.

    'PartialArmTemplates' klasörünün diyagramı.

İlgili içerik

  • Last updated on