Perlu diperhatikan bahwa Anda sedang melihat dokumentasi Looker. Untuk melihat dokumentasi Looker Studio, buka https://support.google.com/looker-studio.

Halaman ini diterjemahkan oleh Cloud Translation API.

Penggunaan dan alur kerja CI/CD Looker

Halaman ini menjelaskan cara menggunakan alur kerja CI/CD 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 untuk 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 Spectacles, dan melakukan commit kode mereka. Terakhir, mereka membuka permintaan pull untuk menggabungkan kode mereka dengan cabang main.

Saat dibuka, Pull Request akan mengarahkan developer ke GitHub. Developer harus menulis judul PR yang bermakna menggunakan gaya commit konvensional dan menambahkan komentar ke deskripsi yang akan disertakan dalam log perubahan. Hasil pengujian Spectacles harus ditambahkan sebagai komentar ke PR.

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 tersebut.

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

Saat PR yang dibuat 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, Pembuatan Versi Semantik 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 titik: MAJOR.MINOR.PATCH

PATCH bertambah setiap kali rilis memperbaiki bug
MINOR bertambah dan PATCH ditetapkan kembali ke nol setiap kali rilis menambahkan atau meningkatkan kualitas fitur sekaligus kompatibel dengan versi sebelumnya
MAJOR bertambah dan MINOR serta PATCH ditetapkan ke nol saat fitur ditambahkan yang tidak kompatibel dengan versi sebelumnya

Commit Konvensional adalah sistem penamaan commit berdasarkan dampaknya terhadap pengguna akhir. Meskipun tidak diwajibkan, 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 ditunjukkan dengan feat: seperti feat: added explore for sales by territory
Fitur dengan perubahan yang menyebabkan gangguan ditunjukkan oleh feat!: seperti feat!: rewrote sales explore to use the new calendar view
Jika dokumen diperbarui, tetapi LookML tidak diubah, pesan commit akan dimulai dengan doc:

Jika commit konvensional digunakan secara konsisten, menentukan nomor semantik yang akan digunakan berikutnya umumnya mudah. Jika log commit hanya terdiri dari commit fix: dan doc:, PATCH harus ditambah. Jika ada commit feat:, MINOR harus ditambah. Jika ada feat!:, MAJOR harus ditambah. Plugin Release Please bahkan dapat membuat file CHANGELOG dan memberi tag pada rilis secara otomatis.

Menggunakan Mode Deploy Lanjutan

Setelah perubahan dibuat dan dikirim sebagai PR pada instance pengembangan, plugin Release Please akan memberi tag pada perubahan dengan tag versi seperti v1.2.3. Mode Deployment Lanjutan Looker kemudian akan menyediakan versi ini 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 to Environment:

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 Deployment Manager Looker untuk men-deploy tanpa pemberian tag.

Terakhir, kirim ke produksi menggunakan Deployment Manager.

Menggunakan Spectacles

Spectacles dapat digunakan oleh setiap developer untuk memverifikasi perubahan mereka saat masih berada di cabang pengembangan. Spectacles menawarkan empat validator yang berbeda:

SQL
LookML
Konten
Assert

Saat developer mengirimkan permintaan pull, sebaiknya jalankan pengujian ini dan salin hasilnya ke komentar di PR.

Validator SQL

Validator SQL menguji setiap Jelajah untuk memastikan bahwa semua kolom yang ditentukan dalam Tampilan LookML sesuai dengan kolom SQL yang sebenarnya atau ekspresi SQL yang valid dalam database. Validator SQL dipanggil seperti yang ditunjukkan di samping:

$ spectacles sql --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --explores MODEL_NAME/EXPLORE_NAME \
    --branch DEV_BRANCH_NAME

Contoh:

$ spectacles sql --config-file config-dev.yaml \
    --project thelook_cicd \
    --explores thelook_cicd/users \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0

=================== Testing 1/1 explores [concurrency = 10] ===================

✓ thelook_cicd.users passed

Completed SQL validation in 1 minute and 7 seconds.

Validator LookML

Validator LookML memastikan bahwa perubahan LookML valid dan tidak memiliki error sintaksis. Metode ini dipanggil seperti yang ditunjukkan di bawah:

$ spectacles lookml --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --branch DEV_BRANCH_NAME

Contoh:

$ spectacles lookml --config-file config-dev.yaml \
    --project thelook_cicd \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0

============= Validating LookML in project thelook_cicd [warning] ==============

✗ thelook_cicd/business_pulse.dashboard.lookml failed
✗ thelook_cicd/thelook_cicd.model.lkml failed

================ thelook_cicd/business_pulse.dashboard.lookml:28 ===============

[Error] Unknown field "users.state" in explore "users" for field_filter.

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/business_pulse.dashboard.lookml?line=28

================ thelook_cicd/business_pulse.dashboard.lookml:36 ===============

[Warning] Unknown field "users.state" (for explore "orders" in model
"thelook_cicd") referenced in dashboard element.

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/business_pulse.dashboard.lookml?line=36

[Additional errors snipped]

Completed validation in 6 seconds.

Validator Konten

Validator Konten menguji apakah konten tersimpan seperti Tampilan dan dasbor yang ditentukan pengguna (UDD) masih berfungsi setelah perubahan dilakukan. Agar tugas berjalan lebih cepat dan memberikan hasil yang mudah dikelola, validasi hanya dilakukan untuk konten yang didasarkan pada Jelajah yang Anda tentukan. Validator Konten dipanggil sebagai berikut:

$ spectacles content --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --explores MODEL_NAME/EXPLORE_NAME \
    --branch DEV_BRANCH_NAME

Contoh:

$ spectacles content --config-file config-dev.yaml \
    --project thelook_cicd \
    --explores thelook_cicd/users \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0
Building LookML project hierarchy for project 'thelook_cicd' @ dev-my-user-ydnv

==================== Validating content based on 5 explores ====================

✗ thelook_cicd.users failed

================= test dashboard for spectacles [TheLook_CICD] =================

Tile 'test dashboard for spectacles' failed validation.

Error in thelook_cicd/users: Unknown field "users.state".

Dashboard: https://gcpl2318.cloud.looker.com/dashboards/223

========================= Business Pulse [TheLook_CICD] ========================

Filter 'State / Region' failed validation.

Error in thelook_cicd/users: Unknown field "users.state".

Dashboard: https://gcpl2318.cloud.looker.com/dashboards/190

Completed content validation in 27 seconds.

Validasi Pernyataan

Assert Validation menguji pernyataan data yang telah Anda tambahkan ke LookML untuk memastikan data dibaca dengan benar. Misalnya, pengujian data di LookML Anda mungkin terlihat seperti ini:

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

Validasi pernyataan dipanggil seperti yang ditunjukkan di bawah:

$ spectacles assert --config-file config-dev.yaml \
    --project PROJECT_NAME \
    --explores MODEL_NAME/EXPLORE_NAME \
    --branch DEV_BRANCH_NAME

Contoh:

$ spectacles assert --config-file config-dev.yaml \
    --project thelook_cicd \
    --explores thelook_cicd/users \
    --branch dev-my-user-ydnv

Connected to Looker version 23.18.60 using Looker API 4.0
Building LookML project hierarchy for project 'thelook_cicd' @ dev-my-user-ydnv

==================== Running data tests based on 1 explore =====================

✗ thelook_cicd.users failed

================ thelook_cicd/users/california_users_is_accurate ===============

Unknown filter field "users.state" in lookml test "california_users_is_accurate"
declaration.

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/thelook_cicd.model.lkml?line=55

================ thelook_cicd/users/california_users_is_accurate ===============

Invalid filter: users.state

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/thelook_cicd.model.lkml?line=55

================ thelook_cicd/users/california_users_is_accurate ===============

Assertion "count_is_expected_value" failed: expression evaluated to "No".

LookML: https://gcpl2318.cloud.looker.com/projects/thelook_cicd/files/thelook_cicd.model.lkml?line=55

Completed data test validation in 14 seconds.

Stabilitas penautan untuk Look dan dasbor

Secara default, Tampilan dan dasbor diberi ID numerik menaik yang digunakan di URL untuk Tampilan atau dasbor. Namun, tidak ada cara untuk menyinkronkan keduanya di seluruh sistem. Oleh karena itu, URL untuk dasbor tertentu dalam pengembangan tidak akan mengarah ke dasbor yang sama dalam UM (Uji Mutu) atau produksi.

Untuk UDD, ada opsi untuk menggunakan slug, bukan ID, sebagai bagian dari URL. Slug adalah kumpulan karakter semi-acak, bukan angka. Slug dapat ditetapkan sebagai bagian dari impor dan agar URL serupa dapat mengarah ke UDD yang sama pada pengembangan, QA, dan produksi. Menggunakan slug, bukan ID, adalah praktik terbaik, terutama saat "mengklik" ke 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 dapat membuat konten yang menampilkan penambahan LookML baru, atau memastikan bahwa konten tersimpan masih berfungsi dengan benar setelah LookML berubah. 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 UDD 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 Tampilan 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