Google berkomitmen untuk mendorong terwujudnya keadilan ras bagi komunitas Kulit Hitam. Lihat caranya.

Basis Data Dasbor VTS

Untuk mendukung dasbor integrasi berkelanjutan yang dapat diskalakan, berkinerja, dan fleksibel, backend Dasbor VTS harus dirancang dengan cermat dengan pemahaman yang kuat tentang fungsionalitas database. Google Cloud Datastore adalah database NoSQL yang menawarkan jaminan ACID transaksional dan konsistensi akhirnya serta konsistensi yang kuat dalam grup entitas. Namun, strukturnya sangat berbeda dengan database SQL (dan bahkan Cloud Bigtable); sebagai ganti tabel, baris, dan sel ada jenis, entitas, dan properti.

Bagian berikut menguraikan struktur data dan pola kueri untuk membuat backend yang efektif untuk layanan web Dasbor VTS.

Entitas

Entitas berikut menyimpan ringkasan dan sumber daya dari pengujian VTS:

  • Entitas Uji . Menyimpan metadata tentang jalannya pengujian dari pengujian tertentu. Kuncinya adalah nama pengujian dan propertinya mencakup jumlah kegagalan, jumlah kelulusan, dan daftar kerusakan kasus uji dari saat tugas peringatan memperbaruinya.
  • Uji Coba Entitas . Berisi metadata dari jalannya pengujian tertentu. Ini harus menyimpan stempel waktu mulai dan berakhir pengujian, ID versi pengujian, jumlah kasus pengujian yang lulus dan gagal, jenis proses (misalnya, pra-pengiriman, pasca-pengiriman, atau lokal), daftar tautan log, host nama mesin, dan jumlah ringkasan cakupan.
  • Entitas Informasi Perangkat . Berisi detail tentang perangkat yang digunakan selama uji coba. Ini mencakup ID build perangkat, nama produk, target build, cabang, dan informasi ABI. Ini disimpan secara terpisah dari entitas pengujian yang dijalankan untuk mendukung pengujian multi-perangkat yang dijalankan dengan cara satu-ke-banyak.
  • Profiling Point Run Entity . Meringkas data yang dikumpulkan untuk titik pembuatan profil tertentu dalam uji coba. Ini menjelaskan label sumbu, nama titik pembuatan profil, nilai, jenis, dan mode regresi dari data pembuatan profil.
  • Entitas Cakupan . Menjelaskan data cakupan yang dikumpulkan untuk satu file. Ini berisi informasi proyek Git, jalur file, dan daftar jumlah cakupan per baris di file sumber.
  • Uji Kasus Jalankan Entitas . Menjelaskan hasil kasus uji tertentu dari uji coba, termasuk nama kasus uji dan hasilnya.
  • Entitas Favorit Pengguna . Setiap langganan pengguna dapat direpresentasikan dalam entitas yang berisi referensi untuk pengujian dan ID pengguna yang dihasilkan dari layanan pengguna App Engine. Hal ini memungkinkan pembuatan kueri dua arah yang efisien (yaitu untuk semua pengguna yang berlangganan suatu pengujian dan untuk semua pengujian yang disukai oleh seorang pengguna).

Pengelompokan entitas

Setiap modul tes mewakili root dari grup entitas. Entitas uji coba adalah turunan dari grup ini dan induk untuk entitas perangkat, entitas titik profil, dan entitas cakupan yang relevan dengan masing-masing leluhur uji dan uji coba.

Gambar 1 . Uji leluhur entitas.

Poin Utama: Saat mendesain hubungan leluhur, Anda harus menyeimbangkan kebutuhan untuk menyediakan mekanisme kueri yang efektif dan konsisten dengan batasan yang diberlakukan oleh database.

Manfaat

Persyaratan konsistensi memastikan bahwa operasi masa depan tidak akan melihat efek dari suatu transaksi sampai itu dilakukan, dan bahwa transaksi di masa lalu terlihat untuk operasi saat ini. Di Cloud Datastore, pengelompokan entitas menciptakan pulau dengan konsistensi baca dan tulis yang kuat dalam grup, yang dalam hal ini adalah semua pengujian yang berjalan dan data yang terkait dengan modul pengujian. Ini menawarkan manfaat berikut:

  • Pembacaan dan pembaruan untuk menguji status modul dengan tugas peringatan dapat diperlakukan sebagai atomic
  • Tampilan hasil kasus uji yang konsisten dan terjamin dalam modul uji
  • Kueri lebih cepat dalam pohon leluhur

Batasan

Menulis ke grup entitas dengan kecepatan yang lebih cepat dari satu entitas per detik tidak disarankan karena beberapa penulisan dapat ditolak. Selama tugas peringatan dan pengunggahan tidak terjadi pada kecepatan lebih cepat dari satu penulisan per detik, strukturnya kokoh dan menjamin konsistensi yang kuat.

Pada akhirnya, batas satu penulisan per modul pengujian per detik adalah wajar karena pengujian yang dijalankan biasanya memakan waktu setidaknya satu menit termasuk overhead kerangka kerja VTS; kecuali pengujian secara konsisten dijalankan secara bersamaan di lebih dari 60 host yang berbeda, tidak akan ada hambatan penulisan. Ini menjadi lebih tidak mungkin mengingat bahwa setiap modul merupakan bagian dari rencana pengujian yang seringkali membutuhkan waktu lebih dari satu jam. Anomali dapat dengan mudah ditangani jika host menjalankan pengujian pada saat yang sama, menyebabkan semburan singkat penulisan ke host yang sama (misalnya dengan menangkap kesalahan penulisan dan mencoba lagi).

Pertimbangan penskalaan

Sebuah pengujian yang dijalankan tidak harus memiliki pengujian sebagai induknya (misalnya dapat mengambil beberapa kunci lain dan memiliki nama pengujian, waktu mulai pengujian sebagai properti); namun, ini akan menukar konsistensi yang kuat dengan konsistensi akhirnya. Misalnya, tugas peringatan mungkin tidak melihat snapshot yang sama-sama konsisten dari pengujian terbaru yang dijalankan dalam modul pengujian, yang berarti bahwa status global mungkin tidak menggambarkan representasi yang sepenuhnya akurat dari urutan pengujian yang dijalankan. Ini juga dapat memengaruhi tampilan pengujian yang dijalankan dalam satu modul pengujian, yang mungkin tidak selalu berupa cuplikan yang konsisten dari urutan proses. Pada akhirnya, snapshot akan konsisten, tetapi tidak ada jaminan bahwa data terbaru akan konsisten.

Kasus uji

Potensi kemacetan lainnya adalah pengujian besar dengan banyak kasus pengujian. Dua batasan operasi adalah throughput tulis maksimum dalam grup entitas satu per detik, bersama dengan ukuran transaksi maksimum 500 entitas.

Salah satu pendekatannya adalah dengan menentukan kasus pengujian yang menjalankan pengujian sebagai leluhur (mirip dengan cara penyimpanan data cakupan, data profil, dan informasi perangkat):

Gambar 2 . Kasus Uji diturunkan dari Uji Jalan (TIDAK DIANJURKAN).

Meskipun pendekatan ini menawarkan atomicity dan konsistensi, pendekatan ini memberlakukan batasan yang kuat pada pengujian: Jika transaksi dibatasi hingga 500 entitas, maka pengujian tidak dapat memiliki lebih dari 498 kasus pengujian (dengan asumsi tidak ada cakupan atau data profil). Jika pengujian melebihi ini, maka satu transaksi tidak dapat menulis semua hasil kasus pengujian sekaligus, dan membagi kasus pengujian menjadi transaksi terpisah dapat melebihi throughput tulis grup entitas maksimum dari satu iterasi per detik. Karena solusi ini tidak akan diskalakan dengan baik tanpa mengorbankan kinerja, ini tidak disarankan.

Namun, alih-alih menyimpan hasil kasus pengujian sebagai turunan dari pengujian yang dijalankan, kasus pengujian dapat disimpan secara independen dan kuncinya disediakan untuk pengujian yang dijalankan (pengujian yang dijalankan berisi daftar pengenal untuk entitas kasus pengujiannya):

Gambar 3 . Kasus Uji disimpan secara independen (DIANJURKAN).

Sekilas, ini mungkin tampak merusak jaminan konsistensi yang kuat. Namun, jika klien memiliki entitas uji coba dan daftar pengidentifikasi kasus uji, itu tidak perlu membuat kueri; melainkan bisa langsung mendapatkan kasus uji dengan pengenalnya, yang selalu dijamin konsisten. Pendekatan ini sangat mengurangi batasan pada jumlah kasus uji yang mungkin dimiliki uji coba sambil mendapatkan konsistensi yang kuat tanpa mengancam penulisan yang berlebihan dalam grup entitas.

Pola akses data

Dasbor VTS menggunakan pola akses data berikut:

  • Favorit pengguna . Dapat ditanyai dengan menggunakan filter kesetaraan pada entitas favorit pengguna yang memiliki objek Pengguna App Engine tertentu sebagai properti.
  • Daftar tes . Kueri sederhana dari entitas uji. Untuk mengurangi bandwidth untuk merender halaman beranda, proyeksi dapat digunakan pada penghitungan lulus dan gagal sehingga dapat menghilangkan daftar panjang ID kasus pengujian yang gagal dan metadata lain yang digunakan oleh tugas pemberitahuan.
  • Uji coba . Membuat kueri untuk entitas uji coba memerlukan pengurutan pada kunci (stempel waktu) dan kemungkinan pemfilteran pada properti uji coba seperti ID build, jumlah kelulusan, dll. Dengan melakukan kueri leluhur dengan kunci entitas uji, pembacaan sangat konsisten. Pada titik ini, semua hasil kasus uji dapat diambil menggunakan daftar ID yang disimpan dalam properti uji coba; ini juga dijamin menjadi hasil yang sangat konsisten dengan sifat operasi get datastore.
  • Profiling dan data cakupan . Membuat kueri untuk profil atau data cakupan yang terkait dengan pengujian dapat dilakukan tanpa juga mengambil data uji coba lainnya (seperti data profil / cakupan lainnya, data kasus pengujian, dll.). Kueri leluhur yang menggunakan kunci entitas uji coba dan uji coba akan mengambil semua titik profil yang direkam selama uji coba; dengan juga memfilter nama titik profil atau nama file, satu profiling atau entitas cakupan dapat diambil. Berdasarkan sifat kueri leluhur, operasi ini sangat konsisten.

Untuk detail tentang UI dan screenshot dari pola data ini yang sedang bekerja, lihat VTS Dashboard UI .