Ana Sayfa 9 BI Teknik Belgesi için Sürekli Entegrasyon

CTO, Lance Hankins'in Teknik Belgesi, Motio A.Ş.

İş Zekası İçin Sürekli Entegrasyonun Faydaları

İş Zekası Sektörü Sürekli Entegrasyondan Nasıl Yararlanabilir?

Endüstri açısından, Akıllı İş (BI) hala nispeten yeni bir alandır. Birçok teknoloji tabanlı endüstri gibi, BI da erken aşamalarda, geçici süreçlere tabi uygulamalar ve çok çeşitli başarılarla ilerlemiştir. Geçmişte, aynı kuruluş tarafından uygulanan birden fazla BI projesinin çok benzer hedeflere giden yolda çılgınca farklı yaklaşımlar benimsemesi olağandı. Ancak son yıllarda, ileri görüşlü kuruluşlar, BI bilgisi ve uzmanlığının merkezileştirilmesi yoluyla BI yeteneklerini artırdı. “BI Yetkinlik Merkezi” (BICC) ve “BI Mükemmeliyet Merkezi” gibi modellerin giderek daha yaygın hale gelmesiyle, bu kuruluşlar artık başarıyı sağlamak ve yatırım getirisini en üst düzeye çıkarmak için tüm kuruluş için BI teknoloji yığınları, araç setleri, süreçler ve teknikler tanımlıyor. yeni BI girişimleri. Ayrıca, bu durumda yazılım endüstrisindeki yan kategorilerdeki en iyi uygulamalardan ipuçları alıyorlar.

BI topluluğu tarafından henüz tanınmayan en iyi uygulamalardan biri Sürekli Entegrasyondur (CI). Yazılım geliştirme alanında, CI, bir yazılım kod tabanının otomatik olarak oluşturulduğu ve geliştirme ortamında sık aralıklarla duman testinden geçirildiği süreçtir. Tipik bir CI özellikli yazılım projesinde, bir "yapı sunucusu" projenin kaynak kodu deposunu izler ve değişiklikler tespit edildiğinde kaynağın temiz bir kopyasını alır, tam bir yeniden oluşturma yapar, tüm regresyon testlerini çalıştırır ve proaktif olarak geliştirmeyi bildirir herhangi bir başarısızlık ekibi. Her tam başarılı döngü1, yazılım ürünü için kurulabilir bir ikili dosyalar seti üretir.

Bu sık, otomatik entegrasyon, sisteme dahil edilen hataları (genellikle girdikten sonraki birkaç dakika içinde) hızlı bir şekilde yakalar ve hatayı kimin ve ne zaman yaptığını görmeyi çok daha kolay hale getirir. Kusurlar ve uyumsuzluklar, ortaya çıktıkları andan itibaren dakikalar içinde yakalandıklarında (özellikle geliştirme ortamından asla çıkamazlarsa) düzeltilmesi her zaman daha ucuza gelir.

Sürekli Entegrasyonun (CI) Temel İlkeleri

  • Tekrarlanabilir, otomatikleştirilmiş derleme ve test süreçleri.
  • Bu otomatikleştirilmiş derleme ve test süreçleri, entegrasyon sorunlarının erken saptanması için sık sık yürütülür.
  • Sık, otomatik döngüler, bozuk/uyumsuz eserler için erken uyarılar sağlar.
  • Sistemdeki tüm değişikliklerin hemen onaylanması ve test edilmesi.

CI uygulamasının modern yazılım geliştirme organizasyonunun cephaneliğinde paha biçilmez bir araç haline geldiği konusunda çok az ihtilaf vardır. CI, yazılım geliştirme ekiplerinin hem kalitesini hem de ivmesini artırır. CI kavramını benimsemiş deneyimli geliştirme ekipleri, onsuz herhangi bir büyük yazılım projesini üstlenmeyi hayal edemezler.

CI uygulaması, büyük ölçüde Martin Fowler gibi kişilerin öncü çabaları sayesinde, 2000'li yılların başından beri yazılım geliştirme endüstrisi tarafından benimsenme oranında önemli bir artış sağladı.2 ve Kent Beck.

BI endüstrisi de Sürekli Entegrasyon uygulamasından yararlanabilir mi?

Kesinlikle. Önümüzdeki yıllarda, CI uygulaması, modern BI geliştirme ortamlarına uygulandığında sahip olduğu büyük potansiyel ile tanınacaktır. BI ekosistemleri doğal olarak karmaşıktır (bkz. Şekil 1). Genellikle birçok birbirine bağımlı olan birçok hareketli parçadan oluşurlar. Örneğin, tipik bir BI ekosistemi şunları içerebilir:

  • Çoklu yukarı akış veri kaynakları.
  • ETL süreçleri, bu yukarı akış kaynaklarının her birinden veri pazarlarına veya veri ambarlarına periyodik olarak veri çıkarır, temizler ve yükler.
  • Birçok BI ürünü, bu marketlerin veya depoların üzerine bir “model” katmanı ekler.
  • Profesyonel BI yazarları, BI içeriğini bu model katmanına (örneğin raporlar) göre oluşturur.

 

Yukarı Akış Veri Kaynakları tipik BI ekosistemi

Deneyimli BI uygulayıcılarının kanıtlayabileceği gibi - bu katmanların herhangi birindeki küçük değişiklikler tüm sistem boyunca dalgalanabilir - sonuçta ortaya çıkan BI çıktılarında hatalar veya verimsizlikler yaratabilir. BI ekibinin bir yayın döngüsünde nerede olduğuna bağlı olarak, bu hatalar veya verimsizlikler günler, haftalar ve hatta aylarca fark edilmeyebilir.

İşte gerçek dünyadan birkaç örnek:

  • Model katmanında görünüşte zararsız bir değişiklik, aylardır düzenlenmemiş bir raporun sayılarında beklenmeyen değişikliklere neden olur. Bu değişiklikler aynı raporun performansını da düşürür (manuel olarak ölçülmesi ve saptanması daha da zor olan bir durum).
  • Veritabanındaki bir görünümdeki değişiklik, rapor çalıştırma sürelerinde çarpıcı bir artışa neden olur.
  • Modelleyici, raporun bağlı olduğu bir sütunu yeniden adlandırır veya siler.
  • Bir rapor yazarı, bir raporu optimize etmeye çalışır, ancak isteğe bağlı parametreler ayarlandığında yeni rapor doğru sonuçlar üretmez.

Çoğu BI geliştirme ortamında, geliştirilmekte olan BI içeriğinin testi genellikle çok manuel bir şekilde yapılır (örneğin, "bir rapor çalıştırın, sayıları kontrol edin, doğru olduklarını doğrulayın"). BI ekipleri, bu manuel teste, yakın zamanda değiştirilmemiş olanlar yerine aktif olarak değiştirdikleri eserler3 üzerinde odaklanma eğilimindedir. Bu eğilim, sistemin daha düşük bir seviyesindeki değişiklikler yukarı doğru dalgalanmaya başladığında ve birçok BI yapaylığını etkilediğinde tespit edilemeyen sorunlara yol açar.

Çoğu kuruluş, bir geliştirme ortamından, QA uzmanları tarafından daha resmi testlerden geçecekleri bir test veya kalite güvencesi (QA) ortamına periyodik olarak BI içeriğinin temellerini sunacaktır. QA ekibinin titizliğine bağlı olarak, performanstaki kusurlar veya düşüşler burada yakalanabilir, ancak bu noktada bu sorunları düzeltmenin maliyeti önemli ölçüde artmıştır. Bir kusur onu geliştirme ortamından çıkardıktan sonra (örn. QA ortamına), düzeltilmesi çok daha pahalı hale gelir. Düzeltme için tipik iş akışı, kusurun nasıl yeniden oluşturulacağını (QA ekibi tarafından), bekleyen tüm sorun biletlerinin BI ekibi triyajını (hangilerinin öncelik alacağına karar vermek için), geliştirme sırasında sorunun yeniden üretilmesini, bir düzeltme ve ardından başka bir temelin QA'ya yeniden dağıtılması. Benzer şekilde, üretim ortamlarında keşfedilen kusurların düzeltilmesi, KG'de keşfedilen kusurlardan bile daha pahalıdır.

Tipik Aşamalı Ortamlar, geliştirme ortamı, KG ortamı, üretim ortamı

Bir BI geliştirme ekibi, CI ilkelerini kullanarak bu gibi sorunları proaktif olarak tespit edebilir (genellikle bunlara neden olan değişikliğin dakikaları içinde) ve BI içeriği hala geliştirme ortamındayken düzeltici önlemler alabilir. Bu, genel düzeltme maliyetinin çok daha ucuz olduğu anlamına gelir.

Peki, CI ilkeleri tipik bir İş Zekası projesine nasıl uygulanabilir? Bazı somut örnekler için ele alacağız MotioCI™, İş Zekası geliştirme ortamları için Sürekli Entegrasyon sağlayan ticari bir araç. MotioCI BI ekiplerine aşağıdaki özellikleri sağlar:

İş Zekası için Sürekli Entegrasyon

  1. Tüm BI yapılarının ilgili modellerine göre otomatik olarak doğrulanması. Bu, herhangi bir model veya veritabanı değişikliğinin mevcut BI yapılarını "kırmamasını" sağlar.
  2. Her yapı için test senaryolarının otomatik olarak yürütülmesi. Bu test durumları aşağıdaki gibi şeyleri sağlamak için kullanılabilir:
    1. Yapıtın yürütülmesi doğru veriler üretti
    2. Yapıtın yürütülmesi, beklenen miktarda veri üretti
    3. Yapının performansı kabul edilebilir (yürütme beklenen sürede tamamlanır)
  3. Otomatik tutarlılık kontrolü. Her eser için:
    1. Renkler, yazı tipleri, stiller, gömülü görüntüler vb. şeyler için yerleşik projeye veya kurumsal standartlara uyduğunu doğrulayın.
    2. Parametre adlarının yapılar arasında tutarlı olduğunu doğrulayın
    3. Yapıtlar arasındaki detaylandırma ilişkilerinin hala geçerli olduğunu doğrulayın
  4. BI ekosisteminin izlenmesi, bir test başarısız olmaya başladığında, proje paydaşlarının son döngüden bu yana “kimin neyi değiştirdiğine” dair net bir görüşe sahip olması için değişir. Örneğin:
    1. Hangi modeller değiştirildi (ve kim tarafından?)
    2. Hangi eserler değiştirildi (ve kim tarafından?)
    3. İlgili veri kaynaklarında şema değişiklikleri oldu mu?
    4. İlgili veri kaynaklarındaki veri miktarlarında ciddi değişiklikler oldu mu?

Yukarıdaki süreci otomatikleştirerek ve sık aralıklarla çalıştırarak, bir ekip tarafından üretilen BI içeriği, hala geliştirme ortamındayken doğruluk, tutarlılık ve performans açısından sürekli olarak doğrulanacaktır. CI süreci bir hata tespit ederse, BI ekibini proaktif olarak sorun hakkında bilgilendirecek ve son başarılı döngüden bu yana BI ekosisteminde meydana gelen değişiklikleri kataloglayacaktır. Bu yöntem, BI ekibinin son değişikliklerin yarattığı sorunları hızla fark etmesini, düzeltici önlem almasını ve maliyetleri en aza indirmesini sağlar.

BI için Sürekli Entegrasyon Uygulamasının Net Sonuçları

  1. Hatalar, verimsizlikler ve standart ihlalleri çok erken yakalanır (genellikle girişlerinden sonraki dakikalar veya saatler içinde.
  2. BI ekibi, aksi takdirde bir şeyin bozulmadığından emin olmak için tüm yapıtları manuel olarak test etmek için harcadığı sayısız saati geri kazanır, zamandan tasarruf sağlar ve aynı zamanda ivmeyi korur (BI yazarlarının gerçek geliştirme görevlerine odaklanmasına olanak tanır).
  3. BI ekibi, BI ekosistemlerinde “kimin neyi değiştirdiği” konusunda daha fazla görünürlük kazanır.
  4. BI ekibi tarafından üretilen çıktılar çok daha yüksek kalitededir.
  5. Upstream QA kuruluşları, enerjilerini daha yüksek seviyeli testlere odaklayabilir (BI içeriği QA'ya terfi ettirilmeden önce tüm "düşük asılı meyveler" otomatik olarak filtrelenir).

Özetle, BI Endüstrisi olgunlaştıkça ve iş zekasının konsolidasyonu, yönetimi ve uygulanmasında en iyi uygulamaları oluştururken, ortaya çıkan BICC'ler, yan kategorilerde, özellikle yazılım endüstrisinde öğrenilen dersleri incelemeli ve bunlardan yararlanmalıdır. CI yalnızca bir yazılım endüstrisinin en iyi uygulaması değil, aynı zamanda standart bir işletim prosedürüne dönüşüyor. CI gibi kanıtlanmış uygulamalar benimsendikçe, BICC'ler yalnızca bir BI ekibinin çıktısını (ölçeklenebilirlik açısından kritik) iyileştirmekle kalmayıp, aynı zamanda çıktılarının kalitesini de artırarak temel bir iş disiplini olarak olgunlaşmaya devam edecektir. Bu ikili etki, BICC performansında bir sıçramayı temsil ediyor ve yakında modern BI ortamları için bir dayanak noktası olacak.

 

 

1 Başarılı bir döngü, hiçbir testin başarısız olmadığı bir döngüdür.
2 Martin Fowler'ın Sürekli Entegrasyonu anlatan orijinal makalesi 2000 yılının Eylül ayında yayınlandı.