Untuk mendukung dasbor integrasi berkelanjutan yang terukur, berperforma tinggi, dan fleksibel, backend Dasbor VTS harus dirancang secara cermat dengan pemahaman yang kuat tentang fungsionalitas basis data. Google Cloud Datastore adalah database NoSQL yang menawarkan jaminan ACID transaksional dan konsistensi akhir serta konsistensi yang kuat dalam grup entitas. Namun, strukturnya sangat berbeda dari database SQL (dan bahkan Cloud Bigtable); alih-alih 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 yang dijalankan:
- Entitas Uji . Menyimpan metadata tentang pengujian yang dijalankan pada pengujian tertentu. Kuncinya adalah nama pengujian dan propertinya mencakup jumlah kegagalan, jumlah kelulusan, dan daftar kerusakan kasus pengujian sejak tugas peringatan memperbaruinya.
- Uji Coba Entitas . Berisi metadata dari jalannya pengujian tertentu. Ini harus menyimpan stempel waktu mulai dan berakhir pengujian, ID build 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 rincian 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 uji coba untuk mendukung uji coba multi-perangkat dengan cara satu-ke-banyak.
- Entitas Jalankan Titik Profil . 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 data pembuatan profil.
- Entitas Cakupan . Menjelaskan cakupan data yang dikumpulkan untuk satu file. Ini berisi informasi proyek Git, jalur file, dan daftar jumlah cakupan per baris dalam file sumber.
- Entitas Jalankan Kasus Uji . Menjelaskan hasil kasus pengujian tertentu dari pengujian yang dijalankan, termasuk nama kasus pengujian dan hasilnya.
- Entitas Favorit Pengguna . Setiap langganan pengguna dapat direpresentasikan dalam entitas yang berisi referensi ke pengujian dan ID pengguna yang dihasilkan dari layanan pengguna App Engine. Hal ini memungkinkan kueri dua arah yang efisien (yaitu untuk semua pengguna yang berlangganan suatu pengujian dan untuk semua pengujian yang difavoritkan oleh pengguna).
Pengelompokan entitas
Setiap modul pengujian mewakili akar grup entitas. Entitas uji coba adalah turunan dari grup ini dan induk dari entitas perangkat, entitas titik profil, dan entitas cakupan yang relevan dengan masing-masing nenek moyang pengujian dan uji coba.
Poin Penting: Saat merancang hubungan leluhur, Anda harus menyeimbangkan kebutuhan untuk menyediakan mekanisme kueri yang efektif dan konsisten terhadap batasan yang diberlakukan oleh database.
Manfaat
Persyaratan konsistensi memastikan bahwa operasi di masa depan tidak akan melihat dampak suatu transaksi sampai transaksi tersebut dilakukan, dan bahwa transaksi di masa lalu dapat dilihat oleh operasi saat ini. Di Cloud Datastore, pengelompokan entitas menciptakan pulau-pulau dengan konsistensi baca dan tulis yang kuat dalam grup, yang dalam hal ini adalah semua pengujian yang dijalankan dan data yang terkait dengan modul pengujian. Ini menawarkan manfaat berikut:
- Pembacaan dan pembaruan untuk menguji status modul dengan pekerjaan peringatan dapat diperlakukan sebagai atomik
- Jaminan tampilan hasil kasus uji yang konsisten dalam modul pengujian
- Kueri yang lebih cepat dalam pohon leluhur
Keterbatasan
Menulis ke grup entitas dengan kecepatan lebih cepat dari satu entitas per detik tidak disarankan karena beberapa penulisan mungkin ditolak. Selama tugas peringatan dan pengunggahan tidak terjadi pada kecepatan yang lebih cepat dari satu penulisan per detik, strukturnya solid dan menjamin konsistensi yang kuat.
Pada akhirnya, batasan satu penulisan per modul pengujian per detik adalah wajar karena pengujian yang berjalan biasanya memakan waktu setidaknya satu menit termasuk overhead kerangka VTS; kecuali pengujian secara konsisten dijalankan secara bersamaan pada lebih dari 60 host berbeda, tidak akan ada hambatan penulisan. Hal ini menjadi lebih tidak mungkin mengingat setiap modul merupakan bagian dari rencana pengujian yang seringkali memakan waktu lebih dari satu jam. Anomali dapat dengan mudah ditangani jika host menjalankan pengujian pada saat yang sama, sehingga menyebabkan ledakan singkat penulisan ke host yang sama (misalnya dengan menangkap kesalahan penulisan dan mencoba lagi).
Pertimbangan skala
Uji coba yang dijalankan tidak harus memiliki pengujian sebagai induknya (misalnya, pengujian dapat menggunakan kunci lain dan memiliki nama pengujian, waktu mulai pengujian sebagai properti); namun, hal ini akan menukar konsistensi yang kuat dengan konsistensi pada akhirnya. Misalnya, tugas peringatan mungkin tidak melihat snapshot yang saling konsisten dari pengujian terbaru yang dijalankan dalam modul pengujian, yang berarti bahwa status global mungkin tidak menggambarkan representasi urutan pengujian yang sepenuhnya akurat. Hal ini juga dapat berdampak pada tampilan pengujian yang dijalankan dalam satu modul pengujian, yang belum tentu merupakan cuplikan urutan eksekusi yang konsisten. Pada akhirnya, gambarannya akan konsisten, namun tidak ada jaminan bahwa data terbaru akan konsisten.
Uji kasus
Potensi hambatan lainnya adalah pengujian besar dengan banyak kasus pengujian. Dua batasan operasionalnya adalah throughput tulis maksimum dalam grup entitas sebesar satu per detik, serta ukuran transaksi maksimum sebesar 500 entitas.
Salah satu pendekatannya adalah dengan menentukan kasus pengujian yang menjalankan pengujian sebagai leluhurnya (mirip dengan cara data cakupan, data profil, dan informasi perangkat disimpan):
Meskipun pendekatan ini menawarkan atomisitas dan konsistensi, pendekatan ini menerapkan batasan yang kuat pada pengujian: Jika suatu transaksi dibatasi hingga 500 entitas, maka pengujian tidak boleh 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 penulisan grup entitas maksimum satu iterasi per detik. Karena solusi ini tidak akan berkembang dengan baik tanpa mengorbankan kinerja, maka solusi ini tidak disarankan.
Namun, alih-alih menyimpan hasil kasus pengujian sebagai turunan dari pengujian yang dijalankan, kasus pengujian dapat disimpan secara independen dan kuncinya diberikan kepada pengujian yang dijalankan (pengujian yang dijalankan berisi daftar pengidentifikasi entitas kasus pengujiannya):
Pada pandangan pertama, hal ini mungkin tampak melanggar jaminan konsistensi yang kuat. Namun, jika klien memiliki entitas uji coba dan daftar pengidentifikasi kasus uji, klien tidak perlu membuat kueri; malah bisa langsung mendapatkan kasus uji berdasarkan pengidentifikasinya, yang selalu dijamin konsisten. Pendekatan ini sangat meringankan kendala pada jumlah kasus uji yang mungkin dimiliki oleh suatu uji coba sambil mendapatkan konsistensi yang kuat tanpa mengancam penulisan yang berlebihan dalam suatu grup entitas.
Pola akses data
Dasbor VTS menggunakan pola akses data berikut:
- Favorit pengguna . Dapat ditanyakan dengan menggunakan filter kesetaraan pada entitas favorit pengguna yang memiliki objek Pengguna App Engine tertentu sebagai properti.
- Daftar tes . Kueri sederhana dari entitas pengujian. Untuk mengurangi bandwidth untuk merender halaman beranda, proyeksi dapat digunakan pada penghitungan yang lolos dan gagal sehingga menghilangkan kemungkinan daftar panjang ID kasus uji yang gagal dan metadata lain yang digunakan oleh tugas peringatan.
- Uji coba berjalan . Mengkueri entitas pengujian yang dijalankan memerlukan pengurutan pada kunci (stempel waktu) dan kemungkinan pemfilteran pada properti pengujian yang dijalankan seperti ID build, jumlah kelulusan, dll. Dengan melakukan kueri leluhur dengan kunci entitas pengujian, pembacaannya sangat konsisten. Pada titik ini, semua hasil uji kasus dapat diambil menggunakan daftar ID yang disimpan dalam properti uji coba; ini juga dijamin akan menjadi hasil yang sangat konsisten berdasarkan sifat operasi pengambilan datastore.
- Profil dan cakupan data . Mengkueri data pembuatan profil atau cakupan yang terkait dengan pengujian dapat dilakukan tanpa mengambil data uji coba lainnya (seperti data pembuatan profil/cakupan lainnya, data kasus pengujian, dll.). Kueri leluhur yang menggunakan kunci entitas uji coba dan uji coba akan mengambil semua titik pembuatan profil yang dicatat selama uji coba; dengan juga memfilter nama titik pembuatan profil atau nama file, satu entitas pembuatan profil atau cakupan dapat diambil. Berdasarkan sifat kueri leluhur, operasi ini sangat konsisten.
Untuk detail tentang UI dan tangkapan layar pola data ini, lihat VTS Dashboard UI .