Aracılığıyla paylaş

Sizin için en iyi Doku CI/CD iş akışı seçeneğini belirleyin

  • Makale

Bu makalenin amacı, Doku geliştiricilerine yaygın müşteri senaryolarına göre Doku'da CI/CD işlemleri oluşturmak için farklı seçenekler sunmaktır. Bu makale, CI/CD işleminin sürekli dağıtımına (CD) daha fazla odaklanır. Sürekli tümleştirme (CI) bölümüyle ilgili bir tartışma için bkz. Git dallarını yönetme.

Bu makalede çeşitli farklı seçenekler özetlese de, birçok kuruluş karma bir yaklaşım benimser.

Önkoşullar

Dağıtım işlem hatları özelliğine erişmek için aşağıdaki koşulları karşılamanız gerekir:

Geliştirme süreci

Geliştirme süreci tüm dağıtım senaryolarında aynıdır ve yeni güncelleştirmelerin üretime nasıl yayınlanmasından bağımsızdır. Geliştiriciler kaynak denetimiyle çalışırken yalıtılmış bir ortamda çalışmaları gerekir. Doku'da, bu ortam yerel makinenizde bir IDE (Power BI Desktop veya VS Code gibi) veya Doku'daki farklı bir çalışma alanı olabilir. Git dallarını yönetme bölümünde geliştirme süreciyle ilgili dikkat edilmesi gereken farklı noktalar hakkında bilgi bulabilirsiniz

Geliştirme sürecinin nasıl çalıştığını gösteren diyagram.

Yayın işlemi

Yeni güncelleştirmeler tamamlandıktan ve çekme isteği (PR) ekibin paylaşılan dalı (Ana, Geliştirme vb.) ile birleştirildikten sonra yayın işlemi başlar. Bu noktadan itibaren, Doku'da bir yayın işlemi oluşturmak için farklı seçenekler vardır.

Seçenek 1 - Git tabanlı dağıtımlar

Git tabanlı dağıtımın nasıl çalıştığını gösteren diyagram.

Bu seçenekle, tüm dağıtımlar Git deposundan kaynaklanır. Yayın işlem hattındaki her aşamanın, Doku'da uygun çalışma alanını besleyen ayrılmış bir birincil dalı vardır (diyagramda bu aşamalar Geliştirme, Test ve Üretim aşamalarıdır).

Geliştirme dalı için bir çekme isteği onaylandıktan ve birleştirildikten sonra:

  1. Dev çalışma alanının içeriğini güncelleştirmek için bir yayın işlem hattı tetikleniyor. Bu işlem birim testlerini çalıştırmak için bir Derleme işlem hattı da içerebilir, ancak dosyaların gerçek karşıya yüklenmesi doğrudan depodan çalışma alanına, Doku Git API'leri kullanılarak yapılır. Bu çalışma alanı için belirli yapılandırmaları ayarlayan dağıtım sonrası işlemler için diğer Doku API'lerini çağırmanız veya verileri almanız gerekebilir.
  2. Daha sonra Test dalı için bir çekme isteği oluşturulur. Çoğu durumda PR, bir sonraki aşamaya geçmek için içeriği seçebilen bir yayın dalı kullanılarak oluşturulur. Çekme isteği, ekibinizdeki veya kuruluşunuzdaki diğer herkesle aynı gözden geçirme ve onay süreçlerini içermelidir.
  3. Test çalışma alanını güncelleştirmekiçin ilk adımda açıklanana benzer bir işlem kullanılarak başka bir Derleme ve yayın işlem hattı tetiklenmiştir.
  4. Prod dalında, 2. adımda açıklanana benzer bir işlem kullanılarak bir çekme isteği oluşturulur.
  5. Prod çalışma alanını güncelleştirmek için ilk adımda açıklanana benzer bir işlem kullanılarak başka bir Derleme ve yayın işlem hattı tetiklenmiştir.

1. seçeneği ne zaman kullanmayı düşünmelisiniz?

  • Git deponuzu tek gerçeklik kaynağı ve tüm dağıtımların kaynağı olarak kullanmak istediğinizde.
  • Ekibiniz , birden çok birincil dal da dahil olmak üzere dallanma stratejisi olarak Gitflow'a uyduğunda.
  • Depodan karşıya yükleme doğrudan çalışma alanına gider çünkü dağıtımlardan önce dosyaları değiştirmek için derleme ortamlarına ihtiyacımız yoktur. Api'leri çağırarak veya dağıtımdan sonra çalışma alanında öğeleri çalıştırarak bunu değiştirebilirsiniz.

Seçenek 2 - Derleme ortamlarını kullanan Git tabanlı dağıtımlar

Derleme ortamları kullanılarak Git tabanlı dağıtımın akışını gösteren diyagram.

Bu seçenekle, tüm dağıtımlar Git deposunun (Main) aynı dalından kaynaklanır. Yayın işlem hattındaki her aşamanın ayrılmış bir derlemesi ve Yayın işlem hattı vardır. Bu işlem hatları, çalışma alanına yüklenmeden önce öğelerdeki tanımlardan bazılarını değiştiren birim testleri ve betikler çalıştırmak için Bir Derleme ortamı kullanabilir. Örneğin, doğru aşamanın yapılandırmasını ayarlamak için veri kaynağı bağlantısını, çalışma alanı öğeleri arasındaki bağlantıları veya parametrelerin değerlerini değiştirmek isteyebilirsiniz.

Geliştirme dalı için bir çekme isteği onaylandıktan ve birleştirildikten sonra:

  1. Yeni bir Derleme ortamı oluşturmak ve geliştirme aşaması için birim testleri çalıştırmak için bir derleme işlem hattı tetikleniyor. Ardından, içeriği Derleme ortamına yüklemek, yapılandırmanın bir bölümünü değiştirmek için betikleri çalıştırmak, yapılandırmayı geliştirme aşamasına ayarlamak ve Dosyaları Çalışma Alanına yüklemek için Doku'nun Güncelleştirme öğesi tanımı API'lerini kullanmak için bir yayın işlem hattı tetikler.
  2. Yayın yöneticilerinden veri alma ve onay da dahil olmak üzere bu işlem tamamlandığında, test aşaması için bir sonraki derleme ve yayın işlem hatları oluşturulabilir. Bu aşamalar, ilk adımda açıklanana benzer bir işlemde oluşturulur. Test aşaması için, değişikliklerin Prod aşamasında yayımlanmaya hazır olduğunu doğrulamak için dağıtımdan sonra diğer otomatik veya el ile testler gerekebilir.
  3. Tüm otomatik ve el ile testler tamamlandığında yayın yöneticisi derleme ve yayın işlem hatlarını Prod aşamasına onaylayabilir ve başlatabilir. Prod aşaması genellikle test/Geliştirme aşamalarından farklı yapılandırmalara sahip olduğundan, dağıtımdan sonra değişiklikleri test etmek de önemlidir. Ayrıca dağıtım, tüketiciler için olası kullanılabilirliği en aza indirmek için değişiklik temelinde verilerin daha fazla alımını tetiklemelidir.

2. seçeneği ne zaman kullanmayı düşünmelisiniz?

  • Git'i tek gerçeklik kaynağınız ve tüm dağıtımların kaynağı olarak kullanmak istediğinizde.
  • Ekibiniz dallanma stratejisi olarak Gövde tabanlı iş akışını izlediğinde.
  • Dağıtımdan önce connectionId ve lakehouseId gibi çalışma alanına özgü öznitelikleri değiştirmek için bir derleme ortamına (özel betikle) ihtiyacınız vardır.
  • Git'ten öğe içeriğini almak ve değiştirilen Doku Öğelerini oluşturmak, güncelleştirmek veya silmek için ilgili Doku Öğesi API'sini çağırmak için bir yayın işlem hattına (özel betik) ihtiyacınız vardır.

Seçenek 3 - Doku dağıtım işlem hatlarını kullanarak dağıtma

Dağıtım işlem hatlarını kullanan Git tabanlı dağıtımın akışını gösteren diyagram.

Bu seçenekle Git yalnızca geliştirme aşamasına kadar bağlanır. Geliştirme aşamasından dağıtımlar, Doku dağıtım işlem hatlarını kullanarak doğrudan Geliştirme/Test/Üretim çalışma alanları arasında gerçekleşir. Aracın kendisi Fabric'in içinde olsa da, geliştiriciler dağıtım işlem hattı API'lerini kullanarak azure yayın işlem hattının veya GitHub iş akışının bir parçası olarak dağıtımı düzenleyebilir. Bu API'ler, otomatikleştirilmiş testleri (çalışma alanında veya geliştirme aşamasından önce yapılabilir), onayları vb. kullanarak ekibin diğer seçeneklerde olduğu gibi benzer bir derleme ve yayın süreci oluşturmasını sağlar.

Ana dala çekme isteği onaylanıp birleştirildikten sonra:

  1. Yapı Git API'lerini kullanarak değişiklikleri geliştirme aşamasına yükleyen bir derleme işlem hattı tetikleniyor. Gerekirse işlem hattı, geliştirme aşamasında dağıtım sonrası işlemleri/testleri başlatmak için diğer API'leri tetikleyebilir.
  2. Geliştirme dağıtımı tamamlandıktan sonra, geliştirme aşamasından test aşamasına değişiklikleri dağıtmak için bir yayın işlem hattı devreye girer. Üretime ulaşmadan önce değişikliklerin iyi test edilmesini sağlamak için dağıtımdan sonra otomatik ve el ile testler yapılmalıdır.
  3. Testler tamamlandıktan ve sürüm yöneticisi Prod aşamasına dağıtımı onayladıktan sonra, Prod sürümü devreye girer ve dağıtımı tamamlar.

3. seçeneği ne zaman kullanmayı düşünmelisiniz?

  • Kaynak denetimini yalnızca geliştirme amacıyla kullanıyorsanız ve değişiklikleri yayın işlem hattının aşamaları arasında doğrudan dağıtmayı tercih ediyorsanız.
  • Dağıtım kuralları, otomatik bağlama ve diğer kullanılabilir API'ler yayın işlem hattının aşamaları arasındaki yapılandırmaları yönetmek için yeterlidir.
  • Doku dağıtım işlem hatlarının dokudaki değişiklikleri görüntüleme, dağıtım geçmişi vb. gibi diğer işlevlerini kullanmak istediğinizde.
  • Doku dağıtım işlem hatlarındaki dağıtımların doğrusal bir yapıya sahip olduğunu ve işlem hattını oluşturmak ve yönetmek için başka izinler gerektirdiğini de göz önünde bulundurun.

Seçenek 4 - Dokudaki ISV'ler için CI/CD (birden çok müşteriyi/çözümü yönetme)

ISV'ler için Git tabanlı dağıtım akışını gösteren diyagram.

Bu seçenek diğerlerinden farklıdır. Bu en çok, Fabric'in üzerinde müşterileri için SaaS uygulamaları oluşturan Bağımsız Yazılım Satıcıları (ISV) için geçerlidir. ISV'lerin genellikle her müşteri için ayrı bir çalışma alanı vardır ve en fazla birkaç yüz veya binlerce çalışma alanı olabilir. Her müşteriye sağlanan analizin yapısı benzer ve kullanıma hazır olduğunda, yalnızca Prod aşamasında her müşteriye ayrılan merkezi bir geliştirme ve test sürecine sahip olunmasını öneririz.

Bu seçenek 2. seçeneği temel alır. Ana pr onaylanıp birleştirildikten sonra:

  1. Yeni bir Derleme ortamı oluşturmak ve geliştirme aşaması için birim testleri çalıştırmak için bir derleme işlem hattı tetikleniyor. Testler tamamlandığında bir yayın işlem hattı tetiklenir. Bu işlem hattı içeriği Derleme ortamına yükleyebilir, yapılandırmanın bir bölümünü değiştirmek için betikleri çalıştırabilir, yapılandırmayı geliştirme aşamasına ayarlayabilir ve ardından Dosyaları Çalışma Alanına yüklemek için Doku'nun Güncelleştirme öğesi tanımı API'lerini kullanabilir.
  2. Bu işlem tamamlandıktan sonra, yayın yöneticilerinden veri alma ve onay da dahil olmak üzere test aşaması için bir sonraki derleme ve yayın işlem hatları başlatılabilir. Bu işlem, ilk adımda açıklanana benzer. Test aşaması için, değişikliklerin Yüksek kalitede Prod aşamasına yayımlanmaya hazır olduğunu doğrulamak için dağıtımdan sonra diğer otomatik veya el ile testler gerekebilir.
  3. Tüm testler geçtikten ve onay işlemi tamamlandıktan sonra Prod müşterilerine dağıtım başlayabilir. Her müşterinin kendi parametreleriyle kendi sürümü vardır, böylece kendi yapılandırması ve veri bağlantısı ilgili müşterinin çalışma alanında gerçekleşebilir. Yapılandırma değişikliği, derleme ortamındaki betikler veya dağıtım sonrasında API'ler kullanılarak gerçekleşebilir. Tüm sürümler birbirine bağlı veya birbirine bağlı olmadığından paralel olarak gerçekleşebilir.

#4 seçeneğini ne zaman kullanmayı düşünmelisiniz?

  • Fabric'in üzerinde uygulama oluşturan bir ISV'siniz.
  • Uygulamanızın çok kiracılılığını yönetmek için her müşteri için farklı çalışma alanları kullanıyorsunuz
  • Daha fazla ayrım veya farklı müşteriler için belirli testler için geliştirme veya testin önceki aşamalarında çok kiracılı olmak isteyebilirsiniz. Bu durumda, çok kiracılı olarak gerekli çalışma alanı sayısının önemli ölçüde arttığını düşünün.

Özet

Bu makalede, Doku'da otomatik bir CI/CD işlemi oluşturmak isteyen bir ekip için ana CI/CD seçenekleri özetlenmiştir. Dört seçeneği özetlesek de, gerçek hayattaki kısıtlamalar ve çözüm mimarisi hibrit seçeneklere veya tamamen farklı seçeneklere uygun olabilir. Bu makaleyi, farklı seçenekler ve bunları nasıl oluşturabileceğiniz konusunda size yol göstermek için kullanabilirsiniz, ancak seçeneklerden yalnızca birini seçmek zorunda kalmazsınız.

Bazı senaryolarda veya belirli öğelerde, bu senaryolardan herhangi birini benimsemenizi engelleyebilecek sınırlamalar bulunabilir.

Aynı şey araçlar için de geçerli. Burada farklı araçlardan bahsedsek de, aynı düzeyde işlevsellik sağlayabilecek diğer araçları seçebilirsiniz. Doku'nun bazı araçlarla daha iyi tümleştirmeye sahip olduğunu, dolayısıyla başkalarını seçmenin farklı geçici çözümler gerektiren daha fazla sınırlamaya neden olduğunu düşünün.

İlgili içerik