Home 9 Integrasi Terus-terusan kanggo Kertu Teknis BI

A Technical Paper dening Lance Hankins, CTO, Motio Inc.

Keuntungan Integrasi Terus-terusan kanggo Intelijen Bisnis

Kepiye Industri Intelijen Bisnis bisa entuk manfaat saka Integrasi Terus-terusan

Ing istilah industri, Business Intelligent (BI) isih dadi lapangan sing cukup anyar. Kaya industri adhedhasar teknologi, BI wis maju kanthi tahap wiwitan kanthi implementasi sing tundhuk karo proses ad hoc lan macem-macem sukses. Biyen, wis umum yen pirang-pirang proyek BI sing dileksanakake dening organisasi sing padha njupuk pendekatan sing beda banget kanthi tujuan sing padha. Nanging ing taun-taun pungkasan, organisasi sing duwe pemikiran maju nambah kemampuan BI liwat sentralisasi ilmu lan keahlian BI. Kanthi model kayata "Pusat Kompetensi BI" (BICC) lan "Pusat Keunggulan BI" sing dadi umum, organisasi kasebut saiki nemtokake tumpukan teknologi, alat, proses lan teknik BI kanggo kabeh organisasi supaya sukses lan maksimalake ROI ing inisiatif BI anyar. Dheweke uga njupuk pitunjuk saka praktik paling apik ing kategori flanking, ing babagan iki, industri piranti lunak.

Salah sawijining praktik paling apik sing durung dingerteni dening komunitas BI yaiku Continuous Integration (CI). Ing bidang pangembangan piranti lunak, CI minangka proses codebase piranti lunak kanthi otomatis digawe lan dites kumelun kanthi interval sing asring - ing lingkungan pangembangan. Ing proyek piranti lunak sing aktif CI-aktif, "build server" ngawasi repositori kode sumber proyek lan, yen ana pangowahan dideteksi, narik salinan sumber sing resik, nggawe maneh lengkap, mbukak kabeh tes regresi, lan kanthi proaktif menehi informasi babagan pangembangan tim saka sembarang gagal. Saben siklus1 sing sukses kanthi sukses ngasilake set binar sing bisa diinstal kanggo produk piranti lunak.

Integrasi otomatis sing cepet lan cepet iki bisa nemokake kesalahan sing dilebokake ing sistem (asring sawetara menit diwiwiti), lan nggawe luwih gampang ngerti sapa sing ngenalake kesalahan lan kapan. Cacat lan kompatibilitas mesthi luwih murah kanggo didandani nalika kejiret sawetara menit wiwit dikenalake (utamane yen ora nate metu saka lingkungan pangembangan).

Prinsip Utama Integrasi Terus-terusan (CI)

  • Proses gawe lan tes sing bisa dibaleni maneh.
  • Proses pambangunan lan pangujian otomatis iki asring dieksekusi saengga masalah integrasi dideteksi luwih dhisik.
  • Siklus otomatis sing asring menehi peringatan dini kanggo artefak sing rusak / ora kompatibel.
  • Cedhak validasi lan tes langsung saka kabeh pangowahan sistem.

Ora ana regejegan manawa praktik CI wis dadi alat sing ora larang regane ing arsenal organisasi pangembangan piranti lunak modern. CI nambah kualitas lan momentum tim pangembangan piranti lunak. Tim pangembangan sing duwe konsep CI ora bisa mbayangake nindakake proyek piranti lunak sing gedhe tanpa proyek kasebut.

Praktek CI wis entuk paningkatan signifikan ing tingkat adopsi dening industri pangembangan piranti lunak wiwit wiwitan taun 2000an, amarga akeh upaya pionir individu kayata Martin Fowler2 lan Kent Beck.

Apa industri BI uga entuk bathi saka praktik Integrasi Terusan?

Pancen. Ing taun-taun mbesuk, praktik CI bakal diakoni potensi gedhe nalika ditrapake ing lingkungan pangembangan BI modern. Ekosistem BI sipate kompleks (deleng gambar 1). Dheweke asring digawe saka pirang-pirang bagean sing obah, kanthi akeh ketergantungan. Contone, ekosistem BI sing biasane ngemot:

  • Multiple sumber data hulu.
  • ETL proses sacara periodik ngekstrak, ngresiki lan mbukak data saka saben sumber hulu kasebut dadi data mart utawa gudang data.
  • Akeh produk BI sing nambah lapisan "model" ing ndhuwur mart utawa gudang iki.
  • Panulis BI profesional nggawe konten BI tumrap lapisan model iki (kayata laporan).

 

Sumber Data Hulu ekosistem BI khas

Minangka praktisi BI sing berpengalaman bisa mbuktekake - pangowahan suntingan ing lapisan kasebut bisa uga ripple ing saindenging sistem - nggawe kesalahan utawa efisiensi ing output BI asil. Gumantung saka tim BI sajrone siklus rilis, kesalahan utawa efisiensi kasebut bisa uga ora dingerteni pirang-pirang dina, minggu utawa malah pirang-pirang wulan.

Ing ngisor iki sawetara conto ing donya nyata:

  • Modifikasi sing katon ora aman ing lapisan model nyebabake pangowahan nomer sing ora dikarepake kanggo laporan sing durung diowahi pirang-pirang wulan. Pangowahan kasebut uga ngrusak kinerja laporan sing padha (kahanan sing luwih angel diitung lan dideteksi kanthi manual).
  • Pangowahan tampilan ing DB nyebabake peningkatan runtime laporan kanthi dramatis.
  • Modeler ngganti jeneng utawa mbusak kolom sing gumantung saka laporan.
  • Panulis laporan nyoba ngoptimalake laporan, nanging laporan anyar ora ngasilake asil sing bener nalika parameter opsional disetel.

Ing umume lingkungan pangembangan BI, pengujian konten BI sing lagi dikembangake asring ditindakake kanthi cara manual (kayata "mbukak laporan, mriksa nomer, verifikasi manawa bener"). Tim BI cenderung fokus ing tes manual iki menyang artefak3 sing lagi aktif diowahi, tinimbang sing durung diowahi saiki. Kecenderungan iki nyebabake masalah sing ora bisa dideteksi nalika owah-owahan ing tingkat ngisor sistem wiwit ripple munggah lan mengaruhi akeh artefak BI.

Umume organisasi kanthi periodik ngirim garis dasar konten BI saka lingkungan pangembangan menyang lingkungan pengujian utawa jaminan kualitas (QA), ing endi bakal ngalami uji coba luwih formal dening para profesional QA. Gumantung saka tuntas tim QA, cacat utawa degradasi kinerja bisa ditemokake ing kene, nanging ing wektu iki, biaya kanggo mbenerake masalah kasebut tambah akeh. Sawise cacat wis digawe saka lingkungan pangembangan (kayata lingkungan QA), dadi luwih larang kanggo didandani. Alur kerja umum kanggo mbenerake kalebu nggawe tiket masalah sing nggambarake cara ngasilake cacat (dening tim QA), uji coba tim BI kanggo kabeh tiket masalah sing isih ana (kanggo mutusake pilihan apa sing dadi prioritas), reproduksi masalah ing pembangunan, implementasi ndandani, banjur ganti maneh garis dasar liyane menyang QA. Kajaba iku, cacat sing ditemokake ing lingkungan produksi luwih larang regane tinimbang sing ditemokake ing QA.

Lingkungan Panggung Umum, lingkungan pangembangan, lingkungan QA, lingkungan produksi

Nggunakake prinsip CI, tim pangembangan BI kanthi proaktif bisa ndeteksi masalah kaya mengkene (asring sawetara menit sawise pangowahan sing nyebabake), lan njupuk tindakan korektif nalika isi BI isih ana ing lingkungan pangembangan. Iki tegese biaya koreksi umume luwih murah.

Dadi, kepiye prinsip CI bisa ditrapake kanggo proyek Business Intelligence sing khas? Kanggo sawetara conto konkrit, kita bakal nimbang MotioCI™, alat komersial sing ngidini Integrasi Terus-terusan kanggo lingkungan pangembangan Business Intelligence. MotioCI nyedhiyakake tim BI fitur ing ngisor iki:

Integrasi Terus-terusan kanggo Intelijen Bisnis

  1. Validasi otomatis kabeh artefak BI marang model sing cocog. Iki njamin manawa ana model utawa pangowahan basis data ora "ngilangi" artefak BI sing ana.
  2. Eksekusi kasus uji otomatis kanggo saben artefak. Kasus tes kasebut bisa digunakake kanggo mesthekake kayata:
    1. Pelaksanaan artefak ngasilake data sing akurat
    2. Pelaksanaan artefak ngasilake data sing diarepake
    3. Kinerja artefak bisa ditampa (eksekusi rampung ing wektu sing diarepake)
  3. Priksa konsistensi otomatis. Kanggo saben artefak:
    1. Verifikasi manawa tundhuk karo proyek utawa standar perusahaan sing wis ditemtokake kanggo prekara kayata warna, font, gaya, gambar semat, lsp.
    2. Verifikasi manawa jeneng paramèter cocog ing artefak
    3. Verifikasi manawa hubungan bor ing antarane artefak isih valid
  4. Pelacakan perubahan ekosistem BI saengga nalika tes wiwit gagal, para pemangku kepentingan proyek duwe pandangan sing jelas babagan "sapa sing ngowahi apa" wiwit siklus pungkasan. Contone:
    1. Model apa sing wis diganti (lan sapa?)
    2. Apa artefak sing wis diganti (lan sapa?)
    3. Apa ana pangowahan skema kanggo sumber data sing relevan?
    4. Apa ana pangowahan drastis kanggo jumlah data ing sumber data sing relevan?

Kanthi ngotomatisasi proses ing ndhuwur lan mlaku kanthi interval sing asring, konten BI sing digawe dening tim bakal terus diverifikasi kanggo akurasi, konsistensi lan kinerja nalika isih ana ing lingkungan pangembangan. Yen proses CI ndeteksi kegagalan, proaktif bakal menehi informasi babagan tim BI babagan masalah kasebut, uga katalog pangowahan ekosistem BI sing kedadeyan wiwit siklus sukses pungkasan. Cara iki nggawe tim BI bisa ndeleng kanthi cepet masalah sing digawe anyar, njupuk tindakan korektif lan nyilikake biaya.

Asil Bersih Ngleksanakake Integrasi Terus-terusan kanggo BI

  1. Kesalahan, inefisiensi, lan pelanggaran standar ditindakake banget (biasane sajrone sawetara menit utawa pirang-pirang jam.
  2. Tim BI ngasilake pirang-pirang jam uga digunakake kanthi manual nyoba kabeh artefak kanggo mesthekake yen ora ana sing rusak, ngirit wektu, nanging uga njaga momentum (ngidini penulis BI fokus ing tugas pangembangan nyata).
  3. Tim BI nambah visibilitas dadi "sapa sing ganti" ing ekosistem BI.
  4. Output sing diproduksi dening tim BI nduweni kualitas sing luwih dhuwur.
  5. Organisasi QA hulu bisa fokus tenogo kanggo tes tingkat luwih dhuwur (kabeh "woh gantung rendah" otomatis disaring sadurunge konten BI dipromosekake dadi QA).

Ringkesan, nalika Industri BI wis diwasa lan nggawe praktik paling apik ing konsolidasi, manajemen lan aplikasi intelijen bisnis, BICC anyar kudu mriksa lan nggayuh piwulang sing dipelajari ing kategori flanking, utamane industri perangkat lunak. CI ora mung praktik paling apik ing industri piranti lunak, nanging uga berkembang dadi prosedur operasi standar. Amarga praktik sing wis kabukten kayata CI diadopsi, BICC bakal terus diwasa dadi disiplin bisnis inti kanthi ora mung nambah kinerja tim BI (kritis kanggo skalabilitas), nanging uga nambah kualitas output. Dampak loro iki nuduhake kabisat ing kinerja BICC lan bakal dadi andalan kanggo lingkungan BI modern.

 

 

1 Siklus sing sukses yaiku tes sing gagal.
2 Kertas asli Martin Fowler sing nggambarake Continuous Integration diterbitake wulan September 2000.