Penggunaan dan alur kerja CI/CD Looker multi-tingkatan

Halaman ini menjelaskan cara menggunakan alur kerja CI/CD multi-tingkat di Looker setelah alur kerja tersebut diinstal dan dikonfigurasi.

Petunjuk ini menggunakan sistem tiga tingkat yang terdiri dari pengembangan, QA, dan produksi. Namun, Anda dapat menerapkan prinsip yang sama ke sistem dua tingkat atau empat tingkat.

Petunjuk ini juga mengasumsikan penggunaan GitHub sebagai penyedia Git Anda. Anda dapat menggunakan penyedia Git lain untuk membuat alur kerja CI/CD; namun, Anda harus memiliki keahlian untuk mengubah petunjuk ini agar sesuai dengan penyedia Anda.

Ringkasan alur kerja

Developer LookML memulai dengan menulis kode di cabang pengembangan mereka, yang biasanya diberi nama seperti dev-my-user-ydnv, menguji perubahan mereka dengan Integrasi Berkelanjutan Looker (atau dengan menjalankan rangkaian CI secara manual), dan melakukan commit kode mereka. Terakhir, mereka membuka permintaan pull untuk menggabungkan kode mereka dengan branch main.

Saat permintaan pull dibuka, developer akan diarahkan ke GitHub. Developer harus menulis judul PR yang bermakna dengan menggunakan gaya commit konvensional dan menambahkan komentar ke deskripsi yang akan disertakan dalam log perubahan. Jika pemicuan permintaan pull dikonfigurasi, Continuous Integration Looker akan otomatis memvalidasi permintaan pull, dan developer dapat melihat hasilnya di Looker atau di GitHub.

Selanjutnya, developer harus memilih peninjau di GitHub. Peninjau akan menerima notifikasi dan dapat menambahkan ulasan mereka ke PR. Jika peninjau menyetujui perubahan, PR akan digabungkan dengan cabang main. WebHook dipanggil dan lingkungan pengembangan sekarang melihat perubahan.

Secara otomatis, Release Please automation akan berjalan dan membuka PR kedua untuk membuat rilis baru yang diberi tag. Atau, jika sudah ada PR yang dibuka untuk tujuan ini, Release Please akan memperbarui PR tersebut. PR rilis memiliki nomor versi yang terkait dengannya, serta log perubahan yang mencakup judul dan deskripsi perubahan yang disertakan.

Saat PR yang dihasilkan Release Please disetujui dan digabungkan, tag versi baru akan dibuat dan log perubahan akan digabungkan dengan cabang main. Instance QA dan produksi Looker dapat memilih versi ini menggunakan Mode Deployment Lanjutan.

Praktik terbaik untuk memberi nomor rilis dan memberi nama commit

Rilis dan tag terkaitnya dapat diberi nama dan nomor dengan cara apa pun yang sesuai di lingkungan Anda. Namun, Semantic Versioning digunakan di sini, dan sangat disarankan karena berfungsi dengan baik dengan plugin Release Please.

Dalam Pembuatan Versi Semantik, versi terdiri dari tiga angka yang dipisahkan dengan titik: MAJOR.MINOR.PATCH

  • PATCH bertambah setiap kali rilis memperbaiki bug
  • MINOR bertambah dan PATCH disetel kembali ke nol setiap kali rilis menambahkan atau menyempurnakan fitur sekaligus kompatibel mundur
  • MAJOR bertambah dan MINOR serta PATCH disetel ke nol saat fitur yang tidak kompatibel dengan versi sebelumnya ditambahkan

Conventional Commits adalah sistem penamaan commit berdasarkan dampaknya terhadap pengguna akhir. Meskipun tidak wajib, penggunaan penamaan commit konvensional juga berguna untuk plugin Release Please.

Dalam penamaan commit konvensional, setiap pesan commit diawali dengan indikator cakupan perubahan:

  • Perbaikan bug ditunjukkan dengan fix: seperti fix: set proper currency symbol on sale_amt format
  • Fitur baru ditandai dengan feat: seperti feat: added explore for sales by territory
  • Fitur dengan perubahan yang dapat menyebabkan gangguan ditunjukkan oleh feat!: seperti feat!: rewrote sales explore to use the new calendar view
  • Saat dokumentasi diperbarui, tetapi LookML tidak diubah, pesan commit dimulai dengan doc:

Jika commit konvensional digunakan secara konsisten, penentuan nomor semantik yang akan digunakan berikutnya umumnya mudah. Jika log commit hanya terdiri dari commit fix: dan doc:, PATCH harus di-increment. Jika ada commit feat:, MINOR harus di-increment. Jika ada feat!:, MAJOR harus diinkrementalkan. Plugin Release Please bahkan dapat membuat file CHANGELOG dan menandai rilis secara otomatis.

Menggunakan Mode Deploy Lanjutan

Setelah perubahan dilakukan dan dikirim sebagai PR di instance pengembangan, plugin Release Please akan memberi tag pada perubahan dengan tag versi seperti v1.2.3. Mode Deployment Lanjutan Looker kemudian membuat versi ini tersedia di UI Looker untuk instance QA dan produksi.

Untuk men-deploy perubahan, pilih Deployment Manager dari Looker IDE:

Lokasi Looker Deployment Manager di IDE.

Klik link Select Commit di kanan atas Deployment Manager. Selanjutnya, pilih menu tiga titik yang terkait dengan tag yang ingin Anda deploy, lalu pilih Deploy ke Lingkungan:

UI Deployment Manager Looker untuk men-deploy ke lingkungan.

Anda tidak perlu memberi tag pada deployment lagi, jadi pilih Deploy without tagging dan tekan tombol Deploy to Environment:

UI Looker Deployment Manager untuk men-deploy tanpa pemberian tag.

Terakhir, lakukan push ke produksi menggunakan Deployment Manager.

Menggunakan Looker Continuous Integration

Untuk memverifikasi perubahan di cabang pengembangan atau sebagai bagian dari permintaan pull, developer dapat menggunakan Integrasi Berkelanjutan Looker. Integrasi Berkelanjutan menyediakan empat validator:

  • Validator SQL — Memverifikasi bahwa dimensi dalam Eksplorasi Anda berjalan dengan benar terhadap database Anda.
  • Validator LookML — Menguji error sintaksis LookML dalam project.
  • Validator Konten — Menguji error dalam Look dan dasbor di project Anda.
  • Validator Pernyataan — Menjalankan pengujian data LookML yang ditentukan dalam project Anda.

Anda dapat mengelompokkan validator ini ke dalam suite Integrasi Berkelanjutan dan menjalankannya secara otomatis pada permintaan pull, sesuai jadwal, atau secara manual.

Validator SQL

Validator SQL Integrasi Berkelanjutan memverifikasi bahwa dimensi di Eksplorasi Anda berjalan dengan benar terhadap database Anda. Validasi ini menguji apakah kolom yang ditentukan dalam Tabel Virtual LookML sesuai dengan kolom atau ekspresi SQL yang valid dalam database.

Validator SQL memiliki kemampuan utama berikut:

Untuk mengetahui informasi dan opsi konfigurasi selengkapnya, lihat halaman dokumentasi Continuous Integration SQL Validator.

LookML Validator

Validator LookML Integrasi Berkelanjutan memeriksa project LookML Anda untuk menemukan error sintaksis, seperti tanda kurung yang tidak ada atau referensi kolom yang tidak valid. Validator ini sangat membantu developer yang menulis LookML di luar IDE Looker.

LookML Validator memiliki kemampuan utama berikut:

  • Memungkinkan Anda menyetel batas tingkat keparahan (Error, Peringatan, atau Info) yang menentukan tingkat keparahan pesan yang menyebabkan proses gagal.
  • Memungkinkan Anda mengonfigurasi durasi waktu tunggu untuk menjalankan validasi.

Untuk mengetahui informasi dan opsi konfigurasi selengkapnya, lihat halaman dokumentasi Validator LookML Integrasi Berkelanjutan.

Validator Konten

Validator Konten Integrasi Berkelanjutan memverifikasi bahwa konten tersimpan, seperti Look dan dasbor yang ditentukan pengguna (UDD), masih berfungsi dengan baik setelah perubahan LookML dilakukan.

Validator Konten memiliki kemampuan utama berikut:

Untuk mengetahui informasi dan opsi konfigurasi selengkapnya, lihat halaman dokumentasi Continuous Integration Content Validator.

Validator Pernyataan

Validator Pernyataan Integrasi Berkelanjutan menjalankan pengujian data LookML yang ditentukan dalam project Anda untuk memverifikasi logika model dan integritas data.

Misalnya, pengujian data LookML mungkin terlihat seperti berikut:

test: historic_revenue_is_accurate {
  explore_source: orders {
    column: total_revenue { field: orders.total_revenue }
    filters: [orders.created_date: "2024"]
  }
  assert: revenue_is_expected_value {
    expression: ${orders.total_revenue} = 626000 ;;
  }
}

Validator Assert memiliki kemampuan utama berikut:

Untuk mengetahui informasi dan opsi konfigurasi selengkapnya, lihat halaman dokumentasi Validator Pernyataan Integrasi Berkelanjutan.

Mengelola dan menjalankan rangkaian CI

Untuk mengelola dan menjalankan pengujian Integrasi Berkelanjutan, ikuti langkah-langkah berikut:

Secara default, Look dan dasbor diberi ID numerik menaik yang digunakan di URL untuk Look atau dasbor. Namun, tidak ada cara untuk menyinkronkannya di seluruh sistem. Oleh karena itu, URL untuk dasbor tertentu dalam pengembangan tidak akan mengarah ke dasbor yang sama dalam QA atau produksi.

Untuk UDD, ada opsi untuk menggunakan slug, bukan ID sebagai bagian dari URL. Slug adalah sekumpulan karakter semi-acak, bukan angka. Slug dapat ditetapkan sebagai bagian dari impor dan agar URL serupa dapat mengarah ke UDD yang sama di pengembangan, QA, dan produksi. Menggunakan slug, bukan ID, adalah praktik terbaik, terutama saat "mengklik untuk melihat" UDD dari Look atau UDD lain.

Slug dapat ditemukan dengan memeriksa output gzr dashboard cat. Slug dapat digunakan di URL dasbor sebagai pengganti ID numerik.

Memigrasikan konten pengguna dengan Gazer

Menyalin konten seperti Tampilan dan dasbor antara pengembangan, QA, dan produksi sering kali berguna. Anda mungkin ingin membuat konten yang menampilkan penambahan LookML baru, atau memverifikasi bahwa konten tersimpan masih berfungsi dengan benar setelah perubahan LookML. Dalam situasi ini, Gazer dapat digunakan untuk menyalin konten antar-instance.

Dasbor LookML

Dasbor LookML disinkronkan antar-instance selama alur kerja CI/CD LookML reguler. Namun, jika ada UDD yang disinkronkan dengan dasbor LookML, UDD tersebut dapat diperbarui dengan Gazer menggunakan perintah berikut:

gzr dashboard sync_lookml DASHBOARD_ID --host TARGET_SYSTEM_URL

Dasbor yang ditentukan pengguna

Dasbor yang Ditentukan Pengguna (UDD) dapat dimigrasikan dengan Gazer dengan mereferensikan ID dasbor dan URL instance Looker tempat UDD berada. Gazer menyimpan konfigurasi dasbor ke file JSON yang kemudian diimpor ke instance Looker target.

Perintah untuk mengekstrak konfigurasi UDD adalah sebagai berikut:

gzr dashboard cat DASHBOARD_ID --host TARGET_SYSTEM_URL --dir .

Tindakan ini akan menghasilkan file bernama Dashboard_DASHBOARD_ID_DASHBOARD_NAME.json yang berisi konfigurasi dasbor.

UDD dapat diimpor ke sistem target menggunakan perintah berikut:

gzr dashboard import Dashboard_DASHBOARD_ID_DASHBOARD_NAME.json FOLDER_ID \
    --host TARGET_SYSTEM_URL

Tampilan

Migrasi tampilan berfungsi sangat mirip dengan migrasi UDD. Pertama, gunakan Gazer untuk menyimpan konfigurasi Look ke file JSON:

gzr look cat LOOK_ID --host SOURCE_SYSTEM_URL --dir .

Kemudian, impor Tampilan ke instance target:

gzr look import Look_LOOK_ID_LOOK_NAME.json FOLDER_ID \
    --host TARGET_SYSTEM_URL