Mengintegrasikan Tes Cypress Dengan Docker, Buildkite, dan CICD #frontend@twiliosendgrid

Kami telah menulis banyak pengujian Cypress end-to-end (E2E) untuk memvalidasi aplikasi web kami masih berfungsi seperti yang diharapkan dengan backend. Setelah menulis pengujian otomatisasi browser ini, kami ingin pengujian Cypress ini selalu dijalankan atau dipicu dengan cara tertentu seperti pengujian unit kami sebelum kami menggabungkan kode dan menerapkannya ke lingkungan tertentu. Hal ini membawa kami ke jalan yang ingin menjalankan pengujian Cypress kami dalam wadah Docker untuk berintegrasi dengan penyedia continuous integration (CI) kami dan mesin yang kami gunakan di cloud untuk menjalankan wadah ini.

Dalam hal alur penerapan, kami menggunakan Buildkite sebagai penyedia CI kami. Hal ini memungkinkan kami untuk membuat langkah-langkah otomatis untuk aplikasi kami dalam pipeline Buildkite ketika kami berencana untuk memindahkan kode di seluruh papan. Untuk konteks lebih lanjut, pipeline adalah tempat yang biasanya terkait dengan repositori aplikasi tempat kita dapat melihat build atau memicu build dengan langkah-langkah tertentu untuk dijalankan saat Anda membuat permintaan tarik, mendorong perubahan kode baru, menggabungkan kode untuk dikuasai, dan menerapkan ke lingkungan yang berbeda . Kami membuat beberapa jalur pipa untuk tujuan terpisah seperti untuk penerapan, pengujian Cypress yang dipicu, dan pengujian Cypress tertentu yang berjalan sesuai jadwal.

Posting blog ini mengasumsikan Anda telah menulis pengujian Cypress sebelumnya dan menjalankan beberapa pengujian, tetapi menginginkan ide tentang cara menjalankan pengujian ini sepanjang waktu dalam alur pengembangan dan penerapan Anda. Jika Anda ingin lebih banyak ikhtisar tentang menulis tes Cypress, Anda dapat melihat posting blog sebelumnya ini dan kemudian mengunjungi kembali ini ketika Anda memiliki sesuatu untuk dijalankan.

Kami bertujuan untuk memandu Anda melalui ide-ide tentang bagaimana Anda dapat mengintegrasikan pengujian Cypress dalam wadah Docker dengan penyedia CI Anda dengan melihat bagaimana kami telah melakukannya dengan Docker Compose dan Buildkite dalam alur penerapan kami. Ide-ide ini dapat diperluas di infrastruktur Anda untuk strategi, perintah, dan variabel lingkungan untuk diterapkan saat memicu tes Cypress.

Aliran CICD standar kami

Dalam alur pengembangan dan penerapan standar kami, kami menyiapkan dua jalur pipa:

1. Yang pertama menangani langkah-langkah penerapan kami ketika kami mendorong kode.
2. Yang kedua memicu pengujian Cypress kami untuk berjalan secara paralel dan direkam. Keberhasilan atau kegagalan ini mempengaruhi pipa penyebaran.

Dalam alur penerapan, kami membangun aset aplikasi web, menjalankan pengujian unit, dan memiliki langkah-langkah untuk memicu pengujian Cypress yang dipilih sebelum menerapkan ke setiap lingkungan. Kami memastikan mereka lulus sebelum melepaskan kemampuan untuk melakukan penyebaran tombol tekan. Tes Cypress yang dipicu ini di pipa kedua juga berjalan di wadah Docker dan dihubungkan ke Dasbor Cypress berbayar melalui kunci perekaman sehingga kami dapat melihat kembali video, tangkapan layar, dan keluaran konsol dari tes Cypress tersebut untuk men-debug masalah apa pun.

Menggunakan input pilih Buildkite , kami merancang dinamis, memilih petualangan Anda sendiri sehingga pengguna dapat memilih "Ya" atau "Tidak" untuk memutuskan folder spesifikasi Cypress mana yang akan dijalankan dan diverifikasi saat kami mendorong lebih banyak kode. Jawaban defaultnya adalah "Tidak" untuk semua opsi, tetapi nilai "Ya" akan menjadi jalur glob ke folder spesifikasi Cypress.

Terkadang, kami tidak ingin menjalankan semua pengujian Cypress jika perubahan kode kami tidak memengaruhi halaman lain. Kami, sebaliknya, hanya ingin memicu tes yang kami tahu akan terpengaruh. Kami mungkin juga perlu menerapkan perbaikan cepat ke produksi untuk masalah bug yang mendesak karena kami merasa cukup percaya diri untuk tidak menjalankan pengujian Cypress kami yang dapat berlangsung dari 0 hingga 10 menit tergantung pada berapa banyak pengujian yang kami picu. Kami memberikan contoh baik secara visual maupun dalam langkah-langkah YML untuk bagian ini.

Selanjutnya, kami menerapkan skrip Bash kami sendiri yang disebut runCypress.sh untuk dijalankan setelah langkah pemilihan itu untuk mengurai nilai "Ya" atau "Tidak" yang dipilih. Kami melakukan ini untuk membentuk daftar jalur spesifikasi yang dipisahkan koma untuk dijalankan dan ditambahkan sebagai opsi, --spec , ke perintah Cypress akhirnya yang berjalan dalam wadah Docker dalam pipa yang dipicu. Kami mengekspor variabel lingkungan seperti daftar spesifikasi yang terbentuk di "CYPRESS_SPECS" dan lingkungan pengujian saat ini di "CYPRESS_TEST_ENV" untuk digunakan dalam pipa yang kami picu di akhir skrip dengan buildkite-agent pipeline upload "$DIRNAME"/triggerCypress.yml .

Anda mungkin telah memperhatikan bagaimana kami juga mengekspor variabel lingkungan "ASYNC". Di Buildkite, Anda dapat memilih untuk membuat langkah pembangunan yang dipicu menjadi pemblokiran atau non-pemblokiran dalam hal keberhasilan atau kegagalan. Jika kami telah "ASYNC" disetel ke true, langkah-langkah pipa penyebaran utama kami akan terus berjalan dan tidak akan menunggu tes Cypress yang dipicu di pipa yang berbeda selesai. Keberhasilan atau kegagalan pipa tidak mempengaruhi keberhasilan atau kegagalan penyebaran pipa.

Jika kami memiliki "ASYNC" yang disetel ke false, langkah-langkah pipa penyebaran utama kami akan diblokir sampai tes Cypress yang dipicu di pipa yang berbeda selesai. Keberhasilan atau kegagalan build yang dipicu mengarah pada keberhasilan atau kegagalan keseluruhan dari pipeline penerapan yang diambil setelahnya.

Saat kode kami masih dalam cabang fitur dengan permintaan tarik terbuka, kami ingin mendorong lebih banyak perubahan, memicu beberapa tes Cypress, dan melihat bagaimana perilakunya. Namun, kami tidak selalu ingin memblokir langkah-langkah pipeline penerapan lainnya agar tidak berjalan jika tes yang dipicu gagal karena kemungkinan ada lebih banyak perubahan di sepanjang jalan. Dalam skenario ini, kami menetapkan "ASYNC" ke false untuk tidak memblokir jika tes Cypress gagal. Untuk kasus di mana kami telah menggabungkan permintaan tarik kami menjadi master dan disebarkan ke staging tetapi ingin memicu tes Cypress sebelum kami menyebarkan ke produksi, kami menyetel "ASYNC" ke true karena kami ingin tes Cypress selalu lulus sebelum keluar ke produksi .

Kembali ke runCypress.sh , kita ingat bahwa skrip memicu pipeline kedua untuk dijalankan dengan memanggil file triggerCypress.yml dengan nilai variabel lingkungan yang ditetapkan. File triggerCypress.yml terlihat seperti ini. Anda akan melihat langkah "pemicu" dan interpolasi nilai ke dalam pesan build berguna untuk proses debug dan nama langkah dinamis.

Baik kami memicu pengujian Cypress untuk dijalankan dari pipeline penerapan kami ke pipeline pemicu terpisah atau menjalankan pengujian Cypress pada jadwal di pipeline khusus, kami mengikuti dan menggunakan kembali langkah yang sama sambil hanya mengubah nilai variabel lingkungan.

Langkah-langkah ini melibatkan:

1. Membangun image Docker dengan tag terbaru dan tag versi unik
2. Mendorong image Docker ke registri pribadi kami
3. Menarik ke bawah gambar yang sama untuk menjalankan pengujian Cypress kami berdasarkan nilai variabel lingkungan kami dalam wadah Docker

Langkah-langkah ini diuraikan dalam file pipeline.cypress.yml seperti:

Saat kami memicu pengujian Cypress untuk dijalankan, itu akan memulai build terpisah di pipa pemicu Cypress. Berdasarkan keberhasilan atau kegagalan build, uji coba Cypress akan memblokir atau mengizinkan kita untuk men-deploy ke produksi saat kita beralih dari staging ke produksi untuk build cabang master.

Mengklik langkah “Triggered cypress/integration/…” akan membawa Anda ke build pipeline yang dipicu dengan tampilan seperti ini untuk melihat bagaimana pengujian berjalan.

Jika Anda ingin tahu tentang bagaimana bagian Docker semuanya terhubung, Dockerfile.cypress dan docker-compose.cypress.yml compose.cypress.yml kami menggunakan variabel lingkungan yang diekspor dari pipeline kami untuk kemudian menggunakan perintah Cypress yang tepat dari package.json aplikasi kami yang menunjuk ke kanan lingkungan pengujian dan menjalankan file spesifikasi yang dipilih. Cuplikan di bawah ini menunjukkan pendekatan umum kami yang dapat Anda kembangkan dan tingkatkan agar lebih fleksibel.


Di luar pengujian yang dijalankan selama siklus integrasi dan penerapan kami yang biasa, kami membuat pipeline Buildkite khusus. Pipeline ini berjalan sesuai jadwal untuk pengujian penting terhadap lingkungan staging kami untuk memastikan layanan frontend dan backend kami bekerja dengan benar. Kami menggunakan kembali langkah-langkah pipeline yang serupa, menyesuaikan nilai variabel lingkungan tertentu dalam pengaturan pipeline Buildkite, dan menyiapkan jadwal cron untuk dijalankan pada waktu yang dijadwalkan. Ini membantu kami menemukan banyak bug dan masalah dengan lingkungan staging saat kami terus memantau seberapa baik kinerja pengujian kami dan jika ada sesuatu yang downstream atau dari dorongan kode kami sendiri yang mungkin menyebabkan pengujian gagal.

Paralelisasi

Kami juga menggunakan flag paralelisasi untuk memanfaatkan jumlah mesin AWS yang dapat kami putar dari antrean agen build yang disiapkan oleh tim Ops kami. Dengan tanda paralelisasi ini, Cypress secara otomatis menampilkan sejumlah mesin berdasarkan jumlah yang kami tetapkan di properti "paralelisme" Buildkite.

Kami dapat menjalankan lebih dari 200 tes dalam waktu sekitar 5 menit untuk salah satu repo aplikasi kami.

Ini kemudian menyebarkan semua pengujian Cypress untuk dijalankan secara paralel di seluruh mesin tersebut sambil mempertahankan perekaman setiap pengujian untuk proses build tertentu. Ini meningkatkan waktu pengujian kami secara dramatis!

Berikut adalah beberapa tip saat memparalelkan pengujian Cypress Anda:

• Ikuti saran di Layanan Dasbor untuk jumlah mesin yang optimal dan setel jumlah mesin dalam variabel lingkungan untuk fleksibilitas dalam pipeline Anda.
• Pisahkan menjadi file pengujian yang lebih kecil, terutama memecah pengujian yang berjalan lebih lama menjadi beberapa bagian yang dapat kita paralelkan dengan lebih baik di seluruh mesin.
• Pastikan tes Cypress Anda terisolasi dan tidak saling mempengaruhi atau bergantung satu sama lain. Saat berurusan dengan memperbarui, membuat, atau menghapus alur terkait, gunakan pengguna dan sumber daya data yang terpisah untuk menghindari pengujian yang saling menginjak dan mengalami kondisi balapan. File pengujian Anda dapat berjalan dalam urutan apa pun, jadi pastikan itu tidak menjadi masalah saat menjalankan semua pengujian Anda.
• Untuk Buildkite, ingatlah untuk meneruskan nilai variabel lingkungan ID build Buildkite ke opsi --ci-build-id selain opsi parallel sehingga ia mengetahui build unik mana yang akan diasosiasikan saat memparalelkan pengujian di seluruh mesin.

Untuk meninjau:

Untuk menghubungkan tes Cypress Anda ke penyedia CI Anda seperti Buildkite, Anda perlu:

1. Buat image Docker dengan kode aplikasi Anda, menggunakan image dasar Cypress dan dependensi yang diperlukan untuk menjalankan pengujian di lingkungan Node terhadap browser tertentu.
2. Dorong gambar Docker Anda ke registri dengan tag tertentu
3. Tarik gambar yang sama ke bawah di langkah selanjutnya
4. Jalankan tes Cypress Anda dalam mode tanpa kepala dan dengan tombol perekaman jika Anda menggunakan Layanan Dasbor Cypress.
5. Tetapkan nilai variabel lingkungan yang berbeda dan hubungkan ke perintah yang Anda jalankan untuk Cypress untuk memicu pengujian Cypress yang dipilih terhadap lingkungan pengujian tertentu di wadah Docker tersebut.

Langkah-langkah umum ini dapat digunakan kembali dan diterapkan pada pengujian Cypress yang berjalan sesuai jadwal dan kasus penggunaan lainnya, seperti memicu pengujian untuk dijalankan terhadap browser yang dipilih selain pipeline penerapan Anda. Kuncinya adalah memanfaatkan kemampuan penyedia CI Anda dan menyiapkan perintah Anda agar fleksibel dan dapat dikonfigurasi berdasarkan nilai variabel lingkungan.

Atur perintah Anda agar fleksibel dan dapat dikonfigurasi berdasarkan nilai variabel lingkungan.

Setelah pengujian Anda berjalan di Docker dengan penyedia CI Anda (dan jika Anda membayar untuk Layanan Dasbor), Anda dapat memanfaatkan memparalelkan pengujian Anda di beberapa mesin. Anda mungkin harus memodifikasi pengujian dan sumber daya yang ada sehingga tidak bergantung pada yang lain untuk menghindari pengujian yang saling menginjak.

Kami juga membahas ide-ide yang dapat Anda coba sendiri seperti membuat rangkaian pengujian untuk memvalidasi API backend Anda atau memicu pengujian untuk dijalankan pada browser yang Anda pilih. Ada juga lebih banyak cara untuk menyiapkan integrasi berkelanjutan di sini di dokumen Cypress .

Selain itu, penting untuk menjalankan pengujian Cypress ini selama alur penerapan atau interval terjadwal untuk memastikan lingkungan pengembangan Anda berfungsi seperti yang diharapkan sepanjang waktu. Sudah berkali-kali pengujian Cypress kami menemukan masalah yang terkait dengan layanan backend hilir yang turun atau diubah dalam beberapa cara, yang bermanifestasi dalam kesalahan aplikasi frontend. Mereka terutama menyelamatkan kami dari bug tak terduga di halaman web kami setelah kami mendorong perubahan kode React baru.

Mempertahankan tes yang lulus dan memantau tes yang gagal berjalan dengan rajin di lingkungan pengujian kami menyebabkan lebih sedikit tiket dukungan dan pelanggan yang lebih bahagia dalam produksi. Menjaga rangkaian pengujian Cypress yang sehat dan stabil berjalan saat Anda mendorong perubahan kode baru memberikan keyakinan yang lebih besar bahwa segala sesuatunya bekerja dengan baik dan kami menyarankan Anda dan tim Anda melakukan hal yang sama dengan pengujian Cypress Anda.

Untuk sumber daya lebih lanjut tentang pengujian Cypress, lihat artikel berikut:

• Apa yang Harus Dipertimbangkan Saat Menulis Tes E2E
• 1.000 Kaki Ikhtisar Menulis Tes Cypress
• TypeScript Semua Hal dalam Tes Cypress Anda
• Berurusan Dengan Arus Email dalam Tes Cypress
• Ide untuk Mengonfigurasi, Mengatur, dan Mengonsolidasikan Tes Cypress Anda