Untuk mendukung dasbor integrasi berkelanjutan yang dapat diskalakan, berkinerja, dan fleksibel, backend Dasbor VTS harus dirancang dengan 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 SQLdatabases (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 uji coba VTS:
- Entitas Uji . Menyimpan metadata tentang uji coba dari pengujian tertentu. Kuncinya adalah nama pengujian dan propertinya mencakup jumlah kegagalan, jumlah kelulusan, dan daftar kerusakan kasus uji sejak pekerjaan peringatan memperbaruinya.
- Uji Coba Entitas . Berisi metadata dari menjalankan tes tertentu. Itu harus menyimpan stempel waktu mulai dan berakhir pengujian, ID build pengujian, jumlah kasus pengujian yang lulus dan gagal, jenis pengujian (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 pembuatan perangkat, nama produk, target pembuatan, cabang, dan informasi ABI. Ini disimpan secara terpisah dari entitas pengujian untuk mendukung pengujian multi-perangkat 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 profil, nilai, tipe, dan mode regresi dari data profil.
- Entitas Cakupan . Menjelaskan data cakupan yang dikumpulkan untuk satu file. Ini berisi informasi proyek Git, jalur file, dan daftar jumlah cakupan per baris dalam 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 ke pengujian dan ID pengguna yang dihasilkan dari layanan pengguna App Engine. Ini memungkinkan kueri dua arah yang efisien (yaitu untuk semua pengguna yang berlangganan tes dan untuk semua tes yang disukai oleh pengguna).
Pengelompokan entitas
Setiap modul pengujian mewakili akar dari grup entitas. Entitas uji coba adalah turunan dari grup ini dan induk untuk entitas perangkat, entitas titik pembuatan profil, dan entitas cakupan yang relevan dengan leluhur pengujian dan uji coba masing-masing.
Poin Kunci: 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 masa depan tidak akan melihat efek dari transaksi sampai dilakukan, dan bahwa transaksi di masa lalu terlihat untuk operasi saat ini. Di Cloud Datastore, pengelompokan entitas membuat pulau dengan konsistensi baca dan tulis yang kuat dalam grup, yang dalam hal ini adalah semua pengujian dan data yang terkait dengan modul pengujian. Ini menawarkan manfaat berikut:
- Membaca dan memperbarui untuk menguji status modul dengan tugas peringatan dapat diperlakukan sebagai atom
- Tampilan hasil uji kasus yang dijamin konsisten dalam modul pengujian
- Permintaan 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 kokoh dan menjamin konsistensi yang kuat.
Pada akhirnya, batas satu penulisan per modul pengujian per detik adalah wajar karena pengujian berjalan biasanya memakan waktu setidaknya satu menit termasuk overhead kerangka kerja VTS; kecuali jika pengujian secara konsisten dijalankan secara bersamaan pada lebih dari 60 host yang berbeda, tidak akan ada hambatan penulisan. Ini menjadi semakin tidak mungkin mengingat bahwa setiap modul adalah 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, menyebabkan ledakan singkat penulisan ke host yang sama (misalnya dengan menangkap kesalahan penulisan dan mencoba lagi).
Pertimbangan penskalaan
Uji coba tidak harus memiliki pengujian sebagai induknya (misalnya, ia 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 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 memengaruhi tampilan pengujian yang dijalankan dalam satu modul pengujian, yang mungkin tidak selalu merupakan snapshot yang konsisten dari urutan pengujian. Pada akhirnya snapshot akan konsisten, tetapi tidak ada jaminan bahwa data terbaru akan konsisten.
Kasus uji
Hambatan potensial lainnya adalah pengujian besar dengan banyak kasus uji. Dua kendala 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 uji yang memiliki uji coba sebagai leluhur (mirip dengan bagaimana data cakupan, data profil, dan informasi perangkat disimpan):
Meskipun pendekatan ini menawarkan atomisitas dan konsistensi, pendekatan ini memberlakukan batasan yang kuat pada pengujian: Jika 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 menskalakan dengan baik tanpa mengorbankan kinerja, maka solusi ini tidak direkomendasikan.
Namun, alih-alih menyimpan hasil uji kasus sebagai anak dari uji coba, kasus uji dapat disimpan secara independen dan kuncinya disediakan untuk uji coba (uji coba berisi daftar pengidentifikasi untuk entitas kasus uji):
Sepintas, 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; itu malah bisa langsung mendapatkan kasus uji dengan pengidentifikasinya, 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 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 lulus dan gagal untuk menghilangkan daftar panjang ID kasus uji yang gagal dan metadata lain yang digunakan oleh tugas peringatan.
- Tes berjalan . 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 ancestor dengan kunci entitas pengujian, pembacaan sangat konsisten. Pada titik ini, semua hasil uji kasus dapat diambil menggunakan daftar ID yang disimpan dalam properti uji coba; ini juga dijamin menjadi hasil yang sangat konsisten dengan sifat operasi pengambilan datastore.
- Profiling dan cakupan data . Membuat kueri untuk pembuatan 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 ancestor yang menggunakan kunci entitas uji coba dan uji coba akan mengambil semua titik pembuatan profil yang direkam selama uji coba; dengan juga memfilter nama titik atau nama file profil, satu profiling atau entitas cakupan dapat diambil. Berdasarkan sifat kueri leluhur, operasi ini sangat konsisten.
Untuk detail tentang UI dan tangkapan layar dari pola data ini, lihat UI Dasbor VTS .