Bagian 1: Web/Android
Catatan: artikel ini adalah terjemahan ke dalam bahasa Rusia dari artikel aslinya Namun, semua ilustrasi, tautan, kutipan, dan istilah dipertahankan dalam bahasa aslinya untuk menghindari distorsi makna saat diterjemahkan ke dalam bahasa Rusia. Saya berharap Anda senang belajar!
Saat ini, spesialisasi DevOps adalah salah satu yang paling diminati di industri TI. Jika Anda membuka situs pencarian kerja populer dan memfilter berdasarkan gaji, Anda akan melihat bahwa pekerjaan terkait DevOps ada di daftar teratas. Namun, penting untuk dipahami bahwa hal ini terutama merujuk pada posisi 'Senior', yang menyiratkan bahwa kandidat memiliki keterampilan, pengetahuan teknologi, dan peralatan tingkat tinggi. Hal ini juga disertai dengan tanggung jawab tingkat tinggi yang terkait dengan kelancaran operasi produksi. Namun, kami mulai melupakan apa itu DevOps. Awalnya, ini bukan orang atau departemen tertentu. Jika kita mencari definisi istilah ini, kita akan menemukan banyak kata benda yang indah dan benar, seperti metodologi, praktik, filsafat budaya, kelompok konsep, dan sebagainya.
Spesialisasi saya adalah insinyur otomasi pengujian (insinyur otomasi QA), tetapi saya yakin bahwa spesialisasi saya tidak boleh hanya dikaitkan dengan penulisan pengujian otomatis atau pengembangan arsitektur kerangka pengujian. Pada tahun 2020, pengetahuan tentang infrastruktur otomasi juga penting. Hal ini memungkinkan Anda mengatur sendiri proses otomatisasi, mulai dari menjalankan pengujian hingga memberikan hasil kepada seluruh pemangku kepentingan sesuai dengan tujuan Anda. Oleh karena itu, keterampilan DevOps adalah suatu keharusan untuk menyelesaikan pekerjaan. Dan semua ini bagus, tapi sayangnya ada masalah (spoiler: artikel ini mencoba menyederhanakan masalah ini). Intinya adalah DevOps itu sulit. Dan ini jelas, karena perusahaan tidak akan membayar banyak untuk sesuatu yang mudah dilakukan... Di dunia DevOps, ada banyak sekali alat, istilah, dan praktik yang perlu dikuasai. Hal ini sangat sulit dilakukan pada awal karir dan bergantung pada akumulasi pengalaman teknis.
Sumber:
Di sini kita mungkin akan menyelesaikan bagian pendahuluan dan fokus pada tujuan artikel ini.
Tentang apa artikel ini?
Pada artikel ini, saya akan berbagi pengalaman saya membangun infrastruktur otomasi pengujian. Ada banyak sumber informasi di Internet tentang berbagai alat dan cara menggunakannya, namun saya ingin melihatnya murni dalam konteks otomatisasi. Saya yakin banyak insinyur otomasi yang akrab dengan situasi ketika tidak seorang pun kecuali Anda yang menjalankan pengujian yang dikembangkan atau peduli untuk memeliharanya. Akibatnya, pengujian menjadi ketinggalan jaman dan Anda harus menghabiskan waktu untuk memperbaruinya. Sekali lagi, di awal karir, ini bisa menjadi tugas yang cukup sulit: memutuskan dengan bijak alat mana yang dapat membantu menghilangkan masalah tertentu, bagaimana memilih, mengonfigurasi, dan memeliharanya. Beberapa penguji meminta bantuan DevOps (manusia) dan, sejujurnya, pendekatan ini berhasil. Dalam banyak kasus, ini mungkin satu-satunya pilihan karena kami tidak memiliki visibilitas ke semua dependensi. Namun seperti yang kita ketahui, DevOps adalah orang yang sangat sibuk, karena mereka harus memikirkan keseluruhan infrastruktur perusahaan, penerapan, pemantauan, layanan mikro, dan tugas serupa lainnya tergantung pada organisasi/timnya. Seperti yang biasanya terjadi, otomatisasi bukanlah prioritas. Dalam kasus seperti itu, kita harus berusaha melakukan segala kemungkinan dari awal hingga akhir. Hal ini akan mengurangi ketergantungan, mempercepat alur kerja, meningkatkan keterampilan kita dan memungkinkan kita melihat gambaran yang lebih besar tentang apa yang terjadi.
Artikel ini menyajikan alat yang paling populer dan populer serta menunjukkan cara menggunakannya untuk membangun infrastruktur otomasi langkah demi langkah. Setiap kelompok diwakili oleh alat yang telah diuji melalui pengalaman pribadi. Namun bukan berarti Anda harus menggunakan hal yang sama. Alat-alat itu sendiri tidak penting, mereka muncul dan menjadi usang. Tugas teknis kami adalah memahami prinsip-prinsip dasar: mengapa kami memerlukan kelompok alat ini dan masalah pekerjaan apa yang dapat kami selesaikan dengan bantuan mereka. Itu sebabnya di akhir setiap bagian saya meninggalkan tautan ke alat serupa yang mungkin digunakan di organisasi Anda.
Apa yang tidak ada dalam artikel ini
Saya ulangi sekali lagi bahwa artikel ini bukan tentang alat tertentu, jadi tidak akan ada sisipan kode dari dokumentasi dan deskripsi perintah tertentu. Tetapi di akhir setiap bagian saya meninggalkan tautan untuk studi mendetail.
Hal ini dilakukan karena:
- materi ini sangat mudah ditemukan di berbagai sumber (dokumentasi, buku, video kursus);
- jika kita mulai mendalami lebih dalam, kita harus menulis 10, 20, 30 bagian artikel ini (sementara rencananya 2-3);
- Saya hanya tidak ingin membuang waktu Anda karena Anda mungkin ingin menggunakan alat lain untuk mencapai tujuan yang sama.
Praktek
Saya sangat ingin materi ini bermanfaat bagi setiap pembaca, dan tidak sekedar dibaca dan dilupakan. Dalam pembelajaran apa pun, latihan adalah komponen yang sangat penting. Untuk ini saya sudah bersiap. Ada juga pekerjaan rumah yang menunggu Anda untuk memastikan bahwa Anda tidak menyalin baris perintah yang Anda jalankan tanpa berpikir panjang.
Rencana
Langkah
Teknologi
Tools
1
Berjalan lokal (menyiapkan tes demo web/android dan menjalankannya secara lokal)
Node.js, Selenium, Appium
2
Sistem kontrol versi
pergi
3
Kontainerisasi
Docker, jaringan Selenium, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Platform cloud
Google Cloud Platform
6
Orkestrasi
Kubernetes
7
Infrastruktur sebagai kode (IaC)
Terraform, Mungkin
Struktur setiap bagian
Agar narasinya tetap jelas, setiap bagian diuraikan menurut garis besar berikut:
- deskripsi singkat tentang teknologi,
- nilai untuk infrastruktur otomasi,
- ilustrasi keadaan infrastruktur saat ini,
- tautan untuk belajar,
- alat serupa.
1. Jalankan pengujian secara lokal
Deskripsi singkat tentang teknologi
Ini hanyalah langkah persiapan untuk menjalankan pengujian demo secara lokal dan memverifikasi bahwa pengujian tersebut lulus. Pada bagian praktisnya digunakan Node.js, namun bahasa pemrograman dan platformnya juga tidak penting dan Anda bisa menggunakan yang digunakan di perusahaan Anda.
Namun, sebagai alat otomatisasi, saya sarankan menggunakan Selenium WebDriver untuk platform web dan Appium untuk platform Android, karena pada langkah selanjutnya kita akan menggunakan image Docker yang dirancang khusus untuk bekerja dengan alat ini. Apalagi jika dilihat dari kebutuhan pekerjaan, alat ini paling laris di pasaran.
Seperti yang mungkin Anda ketahui, kami hanya mempertimbangkan pengujian web dan Android. Sayangnya, iOS adalah cerita yang sangat berbeda (terima kasih Apple). Saya berencana untuk menampilkan solusi dan praktik terkait IOS di bagian mendatang.
Nilai untuk infrastruktur otomasi
Dari sudut pandang infrastruktur, menjalankan secara lokal tidak memberikan manfaat apa pun. Anda hanya memeriksa apakah pengujian dijalankan pada mesin lokal di browser dan simulator lokal. Namun bagaimanapun juga, ini adalah titik awal yang penting.
Ilustrasi kondisi infrastruktur saat ini
Tautan untuk dijelajahi
Alat serupa
- bahasa pemrograman apa pun yang Anda suka sehubungan dengan tes Selenium/Appium;
- tes apa pun;
- pelari tes mana pun.
2. Sistem kontrol versi (Git)
Deskripsi singkat tentang teknologi
Tidak akan menjadi rahasia besar bagi siapa pun jika saya mengatakan bahwa kontrol versi adalah bagian yang sangat penting dari pengembangan, baik dalam tim maupun secara individu. Berdasarkan berbagai sumber, dapat dikatakan bahwa Git adalah perwakilan paling populer. Sistem kontrol versi memberikan banyak manfaat, seperti berbagi kode, menyimpan versi, memulihkan ke cabang sebelumnya, memantau riwayat proyek, dan membuat cadangan. Kami tidak akan membahas setiap poin secara detail, karena saya yakin Anda sudah sangat familiar dengannya dan menggunakannya dalam pekerjaan Anda sehari-hari. Namun jika tiba-tiba tidak, maka saya sarankan untuk berhenti sejenak membaca artikel ini dan mengisi kekosongan ini sesegera mungkin.
Nilai untuk infrastruktur otomasi
Dan di sini Anda dapat mengajukan pertanyaan yang masuk akal: βMengapa dia memberi tahu kami tentang Git? Semua orang mengetahui hal ini dan menggunakannya untuk kode pengembangan dan kode pengujian otomatis.β Anda benar sekali, tetapi dalam artikel ini kita berbicara tentang infrastruktur dan bagian ini bertindak sebagai pratinjau untuk bagian 7: βInfrastruktur sebagai Kode (IaC)β. Bagi kami, ini berarti seluruh infrastruktur, termasuk pengujian, dijelaskan dalam bentuk kode, sehingga kami juga dapat menerapkan sistem versi padanya dan mendapatkan manfaat serupa seperti kode pengembangan dan otomatisasi.
Kita akan melihat IaC secara lebih rinci pada Langkah 7, namun sekarang Anda dapat mulai menggunakan Git secara lokal dengan membuat repositori lokal. Gambaran besarnya akan diperluas ketika kita menambahkan repositori jarak jauh ke infrastruktur.
Ilustrasi kondisi infrastruktur saat ini
Tautan untuk dijelajahi
Alat serupa
3. Kontainerisasi (Docker)
Deskripsi singkat tentang teknologi
Untuk menunjukkan bagaimana containerisasi telah mengubah aturan mainnya, mari kita kembali ke beberapa dekade lalu. Saat itu, orang membeli dan menggunakan mesin server untuk menjalankan aplikasi. Namun dalam banyak kasus, sumber daya startup yang dibutuhkan tidak diketahui sebelumnya. Akibatnya, perusahaan mengeluarkan uang untuk membeli server yang mahal dan kuat, namun sebagian dari kapasitas ini tidak dimanfaatkan sepenuhnya.
Tahap evolusi selanjutnya adalah mesin virtual (VM), yang memecahkan masalah pemborosan uang untuk sumber daya yang tidak terpakai. Teknologi ini memungkinkan untuk menjalankan aplikasi secara independen satu sama lain dalam server yang sama, mengalokasikan ruang yang sepenuhnya terisolasi. Namun sayangnya, teknologi apa pun memiliki kekurangannya. Menjalankan VM memerlukan sistem operasi lengkap, yang menggunakan CPU, RAM, penyimpanan dan, bergantung pada OS, biaya lisensi perlu diperhitungkan. Faktor-faktor ini mempengaruhi kecepatan pemuatan dan mempersulit portabilitas.
Dan sekarang kita sampai pada containerisasi. Sekali lagi, teknologi ini memecahkan masalah sebelumnya, karena container tidak menggunakan OS lengkap, sehingga menghemat banyak sumber daya dan memberikan solusi portabilitas yang cepat dan fleksibel.
Tentu saja, teknologi containerisasi bukanlah hal baru dan pertama kali diperkenalkan pada akhir tahun 70an. Pada masa itu, banyak penelitian, pengembangan, dan upaya yang dilakukan. Namun Docker-lah yang mengadaptasi teknologi ini dan membuatnya mudah diakses oleh banyak orang. Saat ini, ketika kita berbicara tentang container, yang paling sering kita maksud adalah Docker. Ketika kita berbicara tentang container Docker, yang kami maksud adalah container Linux. Kita dapat menggunakan sistem Windows dan macOS untuk menjalankan container, namun penting untuk dipahami bahwa dalam kasus ini lapisan tambahan akan muncul. Misalnya, Docker di Mac secara diam-diam menjalankan container di dalam VM Linux yang ringan. Kita akan kembali ke topik ini ketika kita membahas menjalankan emulator Android di dalam container, jadi di sini ada nuansa yang sangat penting yang perlu dibahas lebih detail.
Nilai untuk infrastruktur otomasi
Kami menemukan bahwa containerisasi dan Docker itu keren. Mari kita lihat ini dalam konteks otomatisasi, karena setiap alat atau teknologi perlu memecahkan suatu masalah. Mari kita uraikan masalah nyata otomatisasi pengujian dalam konteks pengujian UI:
- sejumlah besar ketergantungan saat menginstal Selenium dan terutama Appium;
- masalah kompatibilitas antara versi browser, simulator dan driver;
- kurangnya ruang terisolasi untuk browser/simulator, yang sangat penting untuk pengoperasian paralel;
- sulit untuk dikelola dan dipelihara jika Anda perlu menjalankan 10, 50, 100, atau bahkan 1000 browser secara bersamaan.
Namun karena Selenium adalah alat otomatisasi paling populer dan Docker adalah alat containerisasi paling populer, tidak mengherankan jika seseorang mencoba menggabungkan keduanya untuk menciptakan alat yang ampuh untuk memecahkan masalah yang disebutkan di atas. Mari kita pertimbangkan solusi tersebut secara lebih rinci.
Jaringan selenium di buruh pelabuhan
Alat ini adalah yang paling populer di dunia Selenium untuk menjalankan banyak browser di banyak mesin dan mengelolanya dari hub pusat. Untuk memulai, Anda perlu mendaftarkan setidaknya 2 bagian: Hub dan Node. Hub adalah node pusat yang menerima semua permintaan dari pengujian dan mendistribusikannya ke Node yang sesuai. Untuk setiap Node kita dapat mengkonfigurasi konfigurasi tertentu, misalnya dengan menentukan browser yang diinginkan dan versinya. Namun, kita tetap perlu merawat sendiri driver browser yang kompatibel dan menginstalnya pada Node yang diinginkan. Oleh karena itu, Selenium grid tidak digunakan dalam bentuknya yang murni, kecuali ketika kita perlu bekerja dengan browser yang tidak dapat diinstal pada OS Linux. Untuk semua kasus lainnya, solusi yang sangat fleksibel dan benar adalah dengan menggunakan image Docker untuk menjalankan Selenium grid Hub dan Node. Pendekatan ini sangat menyederhanakan manajemen node, karena kita dapat memilih gambar yang kita perlukan dengan versi browser dan driver yang kompatibel yang sudah diinstal.
Meskipun ada ulasan negatif tentang stabilitas, terutama ketika menjalankan Node dalam jumlah besar secara paralel, jaringan Selenium masih menjadi alat paling populer untuk menjalankan pengujian Selenium secara paralel. Penting untuk dicatat bahwa berbagai perbaikan dan modifikasi alat ini terus bermunculan di sumber terbuka, yang mengatasi berbagai hambatan.
Selenoid untuk Web
Alat ini merupakan terobosan dalam dunia Selenium karena dapat langsung digunakan dan telah membuat kehidupan banyak insinyur otomasi menjadi lebih mudah. Pertama-tama, ini bukan modifikasi lain dari jaringan Selenium. Sebaliknya, pengembang membuat versi Selenium Hub yang benar-benar baru di Golang, yang dikombinasikan dengan image Docker ringan untuk berbagai browser, memberikan dorongan pada pengembangan otomatisasi pengujian. Selain itu, dalam kasus Selenium Grid, kita harus menentukan semua browser yang diperlukan dan versinya terlebih dahulu, yang tidak menjadi masalah saat bekerja hanya dengan satu browser. Namun jika menyangkut beberapa browser yang didukung, Selenoid adalah solusi nomor satu berkat fitur 'browser on demand'. Yang kami perlukan hanyalah mengunduh gambar yang diperlukan dari browser terlebih dahulu dan memperbarui file konfigurasi yang berinteraksi dengan Selenoid. Setelah Selenoid menerima permintaan dari pengujian, Selenoid akan secara otomatis meluncurkan container yang diinginkan dengan browser yang diinginkan. Saat pengujian selesai, Selenoid akan menghentikan penampung, sehingga membebaskan sumber daya untuk permintaan di masa mendatang. Pendekatan ini sepenuhnya menghilangkan masalah 'degradasi node' yang sering kita temui di jaringan Selenium.
Namun sayangnya, Selenoid masih belum menjadi obat mujarab. Kami mendapatkan fitur 'browser sesuai permintaan', namun fitur 'sumber daya sesuai permintaan' masih belum tersedia. Untuk menggunakan Selenoid, kita harus menerapkannya pada perangkat keras fisik atau pada VM, artinya kita harus mengetahui terlebih dahulu berapa banyak sumber daya yang perlu dialokasikan. Saya kira ini bukan masalah untuk proyek kecil yang menjalankan 10, 20 atau bahkan 30 browser secara paralel. Tapi bagaimana jika kita membutuhkan 100, 500, 1000 dan lebih? Tidak masuk akal untuk memelihara dan membayar begitu banyak sumber daya sepanjang waktu. Di bagian 5 dan 6 artikel ini, kita akan membahas solusi yang memungkinkan Anda melakukan penskalaan, sehingga mengurangi biaya perusahaan secara signifikan.
Selenoid untuk Android
Setelah kesuksesan Selenoid sebagai alat otomatisasi web, orang-orang menginginkan sesuatu yang serupa untuk Android. Dan itu terjadi - Selenoid dirilis dengan dukungan Android. Dari sudut pandang pengguna tingkat tinggi, prinsip pengoperasiannya mirip dengan otomatisasi web. Satu-satunya perbedaan adalah bahwa alih-alih wadah browser, Selenoid menjalankan wadah emulator Android. Menurut pendapat saya, ini adalah alat gratis paling ampuh untuk menjalankan pengujian Android secara paralel.
Saya sebenarnya tidak ingin membicarakan aspek negatif dari alat ini, karena saya sangat menyukainya. Namun tetap saja, ada kelemahan yang sama yang berlaku pada otomatisasi web dan terkait dengan penskalaan. Selain itu, kita perlu membicarakan satu batasan lagi yang mungkin mengejutkan jika kita menyiapkan alat ini untuk pertama kalinya. Untuk menjalankan image Android, kita memerlukan mesin fisik atau VM dengan dukungan virtualisasi bersarang. Dalam panduan cara kerjanya, saya mendemonstrasikan cara mengaktifkan ini di VM Linux. Namun, jika Anda adalah pengguna macOS dan ingin menerapkan Selenoid secara lokal, pengujian Android tidak dapat dijalankan. Namun Anda selalu dapat menjalankan VM Linux secara lokal dengan konfigurasi 'virtualisasi bersarang' dan menerapkan Selenoid di dalamnya.
Ilustrasi kondisi infrastruktur saat ini
Dalam konteks artikel ini, kami akan menambahkan 2 alat untuk menggambarkan infrastruktur. Ini adalah jaringan Selenium untuk pengujian web dan Selenoid untuk pengujian Android. Dalam tutorial GitHub, saya juga akan menunjukkan cara menggunakan Selenoid untuk menjalankan pengujian web.
Tautan untuk dijelajahi
Alat serupa
- Ada alat containerisasi lainnya, tetapi Docker adalah yang paling populer. Jika Anda ingin mencoba sesuatu yang lain, perlu diingat bahwa alat yang telah kami bahas untuk menjalankan pengujian Selenium secara paralel tidak akan langsung berfungsi.
- Seperti yang sudah dikatakan, ada banyak modifikasi dari Selenium grid, misalnya.
4.CI/CD
Deskripsi singkat tentang teknologi
Praktik integrasi berkelanjutan cukup populer dalam pengembangan dan setara dengan sistem kontrol versi. Meskipun demikian, saya merasa ada kebingungan dalam terminologi. Pada paragraf ini saya ingin menjelaskan 3 modifikasi teknologi ini dari sudut pandang saya. Di internet Anda akan menemukan banyak artikel dengan interpretasi berbeda-beda, dan wajar saja jika pendapat Anda berbeda. Yang paling penting adalah Anda memiliki pemikiran yang sama dengan kolega Anda.
Jadi, ada 3 istilah: CI - Continuous Integration, CD - Continuous Delivery dan lagi CD - Continuous Deployment. (Di bawah ini saya akan menggunakan istilah-istilah ini dalam bahasa Inggris). Setiap modifikasi menambahkan beberapa langkah tambahan ke alur pengembangan Anda. Tapi kata-katanya kontinu (terus menerus) adalah hal yang paling penting. Dalam konteks ini yang kami maksud adalah sesuatu yang terjadi dari awal hingga akhir, tanpa interupsi atau intervensi manual. Mari kita lihat CI & CD dan CD dalam konteks ini.
- Integrasi Berkelanjutan ini adalah langkah awal evolusi. Setelah mengirimkan kode baru ke server, kami berharap menerima umpan balik cepat bahwa perubahan kami baik-baik saja. Biasanya, CI mencakup menjalankan alat analisis kode statis dan pengujian API unit/internal. Hal ini memungkinkan kami memperoleh informasi tentang kode kami dalam beberapa detik/menit.
- Pengiriman terus menerus adalah langkah lebih lanjut di mana kami menjalankan pengujian integrasi/UI. Namun, pada tahap ini kami tidak mendapatkan hasil secepat CI. Pertama, jenis tes ini membutuhkan waktu lebih lama untuk diselesaikan. Kedua, sebelum peluncuran, kita harus menerapkan perubahan kita ke lingkungan pengujian/pementasan. Terlebih lagi, jika kita berbicara tentang pengembangan seluler, maka muncul langkah tambahan untuk membuat aplikasi kita.
- Penerapan Berkelanjutan mengasumsikan bahwa kami secara otomatis merilis perubahan ke produksi jika semua tes penerimaan telah lulus pada tahap sebelumnya. Selain itu, setelah tahap rilis, Anda dapat mengonfigurasi berbagai tahapan, seperti menjalankan pengujian asap pada produksi dan mengumpulkan metrik yang diinginkan. Penerapan Berkelanjutan hanya dapat dilakukan dengan cakupan yang baik melalui pengujian otomatis. Jika ada intervensi manual yang diperlukan, termasuk pengujian, hal ini tidak lagi diperlukan Kontinu (kontinu). Maka kami dapat mengatakan bahwa saluran pipa kami hanya mematuhi praktik Pengiriman Berkelanjutan.
Nilai untuk infrastruktur otomasi
Di bagian ini, saya harus mengklarifikasi bahwa ketika kita berbicara tentang pengujian UI end-to-end, itu berarti kita harus menerapkan perubahan dan layanan terkait ke lingkungan pengujian. Integrasi Berkelanjutan - prosesnya tidak berlaku untuk tugas ini dan kita harus berhati-hati dalam menerapkan setidaknya praktik Pengiriman Berkelanjutan. Penerapan Berkelanjutan juga masuk akal dalam konteks pengujian UI jika kita akan menjalankannya dalam produksi.
Dan sebelum kita melihat ilustrasi perubahan arsitektur, saya ingin menyampaikan beberapa patah kata tentang GitLab CI. Tidak seperti alat CI/CD lainnya, GitLab menyediakan repositori jarak jauh dan banyak fitur tambahan lainnya. Jadi, GitLab lebih dari sekadar CI. Ini mencakup manajemen kode sumber, manajemen Agile, pipeline CI/CD, alat logging, dan pengumpulan metrik yang siap pakai. Arsitektur GitLab terdiri dari Gitlab CI/CD dan GitLab Runner. Berikut penjelasan singkat dari situs resminya:
Gitlab CI/CD adalah aplikasi web dengan API yang menyimpan statusnya dalam database, mengelola proyek/pembangunan, dan menyediakan antarmuka pengguna. GitLab Runner adalah aplikasi yang memproses pembangunan. Ini dapat diterapkan secara terpisah dan berfungsi dengan GitLab CI/CD melalui API. Untuk pengujian yang berjalan, Anda memerlukan instance Gitlab dan Runner.
Ilustrasi kondisi infrastruktur saat ini
Tautan untuk dijelajahi
Alat serupa
- Dan banyak lagi
5. Platform awan
Deskripsi singkat tentang teknologi
Pada bagian ini kita akan membahas tentang tren populer yang disebut 'cloud publik'. Terlepas dari manfaat besar yang diberikan oleh teknologi virtualisasi dan containerisasi yang dijelaskan di atas, kita masih membutuhkan sumber daya komputasi. Perusahaan membeli server yang mahal atau menyewa pusat data, namun dalam hal ini kita perlu membuat perhitungan (terkadang tidak realistis) tentang berapa banyak sumber daya yang kita perlukan, apakah kita akan menggunakannya 24/7 dan untuk tujuan apa. Misalnya, produksi memerlukan server yang berjalan XNUMX/XNUMX, tetapi apakah kita memerlukan sumber daya serupa untuk pengujian di luar jam kerja? Hal ini juga tergantung pada jenis pengujian yang dilakukan. Contohnya adalah tes beban/stres yang kami rencanakan untuk dijalankan di luar jam kerja untuk mendapatkan hasil pada hari berikutnya. Namun yang pasti ketersediaan server XNUMX/XNUMX tidak diperlukan untuk pengujian otomatis end-to-end dan terutama untuk lingkungan pengujian manual. Untuk situasi seperti ini, sebaiknya dapatkan sumber daya sebanyak yang diperlukan sesuai permintaan, gunakan sumber daya tersebut, dan berhenti membayar ketika sumber daya tersebut tidak diperlukan lagi. Selain itu, akan sangat bagus untuk menerimanya secara instan dengan melakukan beberapa klik mouse atau menjalankan beberapa skrip. Inilah kegunaan cloud publik. Mari kita lihat definisinya:
βCloud publik didefinisikan sebagai layanan komputasi yang ditawarkan oleh penyedia pihak ketiga melalui Internet publik, sehingga tersedia bagi siapa saja yang ingin menggunakan atau membelinya. Mereka mungkin gratis atau dijual sesuai permintaan, sehingga pelanggan hanya membayar per penggunaan untuk siklus CPU, penyimpanan, atau bandwidth yang mereka konsumsi."
Ada anggapan bahwa public cloud itu mahal. Namun ide utama mereka adalah mengurangi biaya perusahaan. Seperti disebutkan sebelumnya, cloud publik memungkinkan Anda mendapatkan sumber daya sesuai permintaan dan hanya membayar sesuai waktu Anda menggunakannya. Selain itu, terkadang kita lupa bahwa karyawan menerima gaji, dan spesialis juga merupakan sumber daya yang mahal. Perlu diingat bahwa cloud publik membuat dukungan infrastruktur menjadi lebih mudah, sehingga memungkinkan para insinyur untuk fokus pada tugas-tugas yang lebih penting.
Nilai untuk infrastruktur otomasi
Sumber daya spesifik apa yang kita perlukan untuk pengujian UI menyeluruh? Pada dasarnya ini adalah mesin atau cluster virtual (kita akan membicarakan Kubernetes di bagian selanjutnya) untuk menjalankan browser dan emulator. Semakin banyak browser dan emulator yang ingin kita jalankan secara bersamaan, semakin banyak CPU dan memori yang dibutuhkan dan semakin banyak uang yang harus kita keluarkan untuk itu. Oleh karena itu, cloud publik dalam konteks otomatisasi pengujian memungkinkan kita menjalankan sejumlah besar (100, 200, 1000...) browser/emulator sesuai permintaan, mendapatkan hasil pengujian secepat mungkin dan berhenti membayar untuk sumber daya yang sangat boros. kekuatan.
Penyedia cloud paling populer adalah Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Panduan cara kerjanya memberikan contoh cara menggunakan GCP, namun secara umum apa pun yang Anda gunakan untuk tugas otomatisasi tidak menjadi masalah. Semuanya menyediakan fungsi yang kurang lebih sama. Biasanya, untuk memilih penyedia, manajemen berfokus pada keseluruhan infrastruktur dan kebutuhan bisnis perusahaan, yang berada di luar cakupan artikel ini. Bagi para insinyur otomasi, akan lebih menarik untuk membandingkan penggunaan penyedia cloud dengan penggunaan platform cloud khusus untuk tujuan pengujian, seperti Sauce Labs, BrowserStack, BitBar, dan sebagainya. Jadi mari kita lakukan juga! Menurut pendapat saya, Sauce Labs adalah tempat pengujian cloud yang paling terkenal, itulah sebabnya saya menggunakannya sebagai perbandingan.
GCP vs Sauce Labs untuk tujuan otomatisasi:
Bayangkan kita perlu menjalankan 8 pengujian web dan 8 pengujian Android secara bersamaan. Untuk ini kita akan menggunakan GCP dan menjalankan 2 mesin virtual dengan Selenoid. Yang pertama kita akan menaikkan 8 container dengan browser. Yang kedua ada 8 container dengan emulator. Mari kita lihat harganya:
Untuk menjalankan satu container dengan Chrome, kita membutuhkan n1-standar-1 mobil. Dalam kasus Android, hal itu akan terjadi n1-standar-4 untuk satu emulator. Faktanya, cara yang lebih fleksibel dan lebih murah adalah dengan menetapkan nilai pengguna tertentu untuk CPU/Memori, tetapi saat ini hal ini tidak penting untuk dibandingkan dengan Sauce Labs.
Dan berikut tarif penggunaan Sauce Labs:
Saya yakin Anda telah memperhatikan perbedaannya, tetapi saya tetap akan memberikan tabel perhitungan untuk tugas kita:
Sumber daya yang dibutuhkan
Bulanan
Jam kerja(8 - 8)
Jam kerja+Dapat didahului
GCP untuk Web
n1-standar-1 x 8 = n1-standar-8
$194.18
23 hari * 12 jam * 0.38 = $104.88
23 hari * 12 jam * 0.08 = $22.08
Lab Saus untuk Web
Tes paralel Virtual Cloud8
$1.559
-
-
GCP untuk Android
n1-standar-4 x 8: n1-standar-16
$776.72
23 hari * 12 jam * 1.52 = $419.52
23 hari * 12 jam * 0.32 = $88.32
Lab Saus untuk Android
Tes paralel Perangkat Cloud 8 yang sebenarnya
$1.999
-
-
Seperti yang Anda lihat, perbedaan biaya sangat besar, terutama jika Anda menjalankan pengujian hanya selama masa kerja dua belas jam. Namun Anda dapat menghemat biaya lebih jauh lagi jika menggunakan mesin yang dapat diakhiri. Apa itu?
VM yang dapat diakhiri adalah sebuah instance yang dapat Anda buat dan jalankan dengan harga yang jauh lebih rendah dibandingkan instance normal. Namun, Compute Engine mungkin menghentikan (mendahului) instance ini jika memerlukan akses ke resource tersebut untuk tugas lain. Instance yang dapat diakhiri merupakan kelebihan kapasitas Compute Engine, sehingga ketersediaannya bervariasi sesuai penggunaan.
Jika aplikasi Anda toleran terhadap kesalahan dan tahan terhadap kemungkinan preemptible instance, maka preemptible instance dapat mengurangi biaya Compute Engine Anda secara signifikan. Misalnya, pekerjaan pemrosesan batch dapat dijalankan pada instans yang dapat diakhiri. Jika beberapa dari instance tersebut berhenti selama pemrosesan, pekerjaan akan melambat namun tidak berhenti sepenuhnya. Instans yang dapat diakhiri menyelesaikan tugas pemrosesan batch Anda tanpa memberikan beban kerja tambahan pada instans yang ada dan tanpa mengharuskan Anda membayar harga penuh untuk instans normal tambahan.
Dan ini masih belum berakhir! Kenyataannya, saya yakin tidak ada yang menjalankan tes selama 12 jam tanpa istirahat. Dan jika demikian, maka Anda dapat memulai dan menghentikan mesin virtual secara otomatis saat tidak diperlukan. Waktu penggunaan sebenarnya dapat dikurangi menjadi 6 jam per hari. Kemudian pembayaran dalam konteks tugas kita akan turun menjadi $11 per bulan untuk 8 browser. Bukankah ini luar biasa? Namun dengan mesin yang dapat digantikan, kita harus berhati-hati dan siap menghadapi gangguan dan ketidakstabilan, meskipun situasi ini dapat diatasi dan ditangani dalam perangkat lunak. Itu sangat berharga!
Namun saya sama sekali tidak mengatakan 'jangan pernah menggunakan cloud test farm'. Mereka memiliki sejumlah keunggulan. Pertama-tama, ini bukan hanya mesin virtual, tetapi solusi otomatisasi pengujian lengkap dengan serangkaian fungsi yang siap pakai: akses jarak jauh, log, tangkapan layar, perekaman video, berbagai browser, dan perangkat seluler fisik. Dalam banyak situasi, ini bisa menjadi alternatif cantik yang penting. Platform pengujian sangat berguna untuk otomatisasi IOS, ketika cloud publik hanya dapat menawarkan sistem Linux/Windows. Namun kita akan membicarakan iOS di artikel berikut. Saya sarankan untuk selalu melihat situasi dan memulai dari tugas: dalam beberapa kasus lebih murah dan efisien menggunakan cloud publik, dan dalam kasus lain, platform pengujian pasti sepadan dengan uang yang dikeluarkan.
Ilustrasi kondisi infrastruktur saat ini
Tautan untuk dijelajahi
Alat serupa:
6. Orkestrasi
Deskripsi singkat tentang teknologi
Saya punya kabar baik β kita hampir sampai di akhir artikel! Saat ini, infrastruktur otomasi kami terdiri dari pengujian web dan Android, yang kami jalankan melalui GitLab CI secara paralel, menggunakan alat yang mendukung Docker: Selenium grid dan Selenoid. Selain itu, kami menggunakan mesin virtual yang dibuat melalui GCP untuk menghosting container dengan browser dan emulator. Untuk mengurangi biaya, kami memulai mesin virtual ini hanya berdasarkan permintaan dan menghentikannya saat pengujian tidak dilakukan. Apakah ada hal lain yang dapat meningkatkan infrastruktur kita? Jawabannya iya! Temui Kubernetes (K8)!
Pertama, mari kita lihat bagaimana kata orkestrasi, cluster, dan Kubernetes saling terkait satu sama lain. Pada tingkat tinggi, orkestrasi adalah sistem yang menyebarkan dan mengelola aplikasi. Untuk otomatisasi pengujian, aplikasi dalam container tersebut adalah Selenium grid dan Selenoid. Docker dan K8 saling melengkapi. Yang pertama digunakan untuk penerapan aplikasi, yang kedua untuk orkestrasi. Pada gilirannya, K8s adalah sebuah cluster. Tugas cluster adalah menggunakan VM sebagai Node, yang memungkinkan Anda menginstal berbagai fungsi, program, dan layanan dalam satu server (cluster). Jika salah satu Node gagal, Node lain akan mengambil alih, sehingga memastikan pengoperasian aplikasi kita tidak terganggu. Selain itu, K8s memiliki fungsionalitas penting terkait penskalaan, berkat itu kami secara otomatis memperoleh jumlah sumber daya optimal berdasarkan beban dan batasan yang ditetapkan.
Sebenarnya, menerapkan Kubernetes secara manual dari awal bukanlah tugas yang mudah. Saya akan meninggalkan link ke panduan cara terkenal "Kubernetes The Hard Way" dan jika Anda tertarik, Anda dapat mempraktikkannya. Namun untungnya, ada metode dan alat alternatif. Cara termudah adalah dengan menggunakan Google Kubernetes Engine (GKE) di GCP, yang memungkinkan Anda mendapatkan cluster siap pakai dalam beberapa klik. Saya merekomendasikan penggunaan pendekatan ini untuk mulai belajar, karena ini akan memungkinkan Anda untuk fokus mempelajari cara menggunakan K8 untuk tugas Anda daripada mempelajari bagaimana komponen internal harus diintegrasikan bersama.
Nilai untuk infrastruktur otomasi
Mari kita lihat beberapa fitur penting yang disediakan K8:
- penerapan aplikasi: menggunakan cluster multi-node, bukan VM;
- penskalaan dinamis: mengurangi biaya sumber daya yang hanya digunakan berdasarkan permintaan;
- penyembuhan diri: pemulihan otomatis pod (sebagai akibatnya kontainer juga dipulihkan);
- peluncuran pembaruan dan pengembalian perubahan tanpa waktu henti: memperbarui alat, browser, dan emulator tidak mengganggu pekerjaan pengguna saat ini
Namun K8 masih belum menjadi solusi terbaik. Untuk memahami semua kelebihan dan keterbatasan dalam konteks alat yang kami pertimbangkan (Selenium grid, Selenoid), kami akan membahas secara singkat struktur K8. Cluster berisi dua jenis Node: Node Master dan Node Pekerja. Master Node bertanggung jawab atas keputusan manajemen, penerapan, dan penjadwalan. Node pekerja adalah tempat aplikasi dijalankan. Node juga berisi lingkungan runtime container. Dalam kasus kami, ini adalah Docker, yang bertanggung jawab atas operasi terkait container. Namun ada juga solusi alternatif, misalnya. Penting untuk dipahami bahwa penskalaan atau penyembuhan mandiri tidak berlaku langsung pada container. Hal ini diterapkan dengan menambah/mengurangi jumlah pod, yang pada gilirannya berisi kontainer (biasanya satu kontainer per pod, namun bergantung pada tugasnya mungkin ada lebih banyak). Hirarki tingkat tinggi terdiri dari node pekerja, di dalamnya terdapat pod, di dalamnya terdapat container yang dimunculkan.
Fitur penskalaan adalah kuncinya dan dapat diterapkan pada kedua node dalam kumpulan node cluster dan pod dalam sebuah node. Ada 2 jenis penskalaan yang berlaku untuk node dan pod. Tipe pertama adalah horizontal - penskalaan terjadi dengan menambah jumlah node/pod. Tipe ini lebih disukai. Oleh karena itu, tipe kedua adalah vertikal. Penskalaan dilakukan dengan memperbesar ukuran node/pod, bukan jumlahnya.
Sekarang mari kita lihat alat kami dalam konteks istilah di atas.
Jaringan selenium
Seperti disebutkan sebelumnya, Selenium grid adalah alat yang sangat populer, dan tidak mengherankan jika alat ini telah dimasukkan ke dalam container. Oleh karena itu, tidak mengherankan jika jaringan Selenium dapat diterapkan di K8. Contoh cara melakukan ini dapat ditemukan di repositori resmi K8s. Seperti biasa, saya melampirkan link di akhir bagian. Selain itu, panduan cara menunjukkan cara melakukan ini di Terraform. Terdapat juga petunjuk tentang cara menskalakan jumlah pod yang berisi container browser. Namun fungsi penskalaan otomatis dalam konteks K8 masih belum sepenuhnya jelas. Ketika saya mulai belajar, saya tidak menemukan panduan atau rekomendasi praktis. Setelah beberapa penelitian dan eksperimen dengan dukungan tim DevOps, kami memilih pendekatan meningkatkan container dengan browser yang diperlukan di dalam satu pod, yang terletak di dalam satu node pekerja. Metode ini memungkinkan kita untuk menerapkan strategi penskalaan node secara horizontal dengan meningkatkan jumlahnya. Saya berharap hal ini akan berubah di masa depan dan kita akan melihat lebih banyak deskripsi tentang pendekatan yang lebih baik dan solusi yang siap pakai, terutama setelah rilis Selenium grid 4 dengan arsitektur internal yang berubah.
selenoid:
Penerapan selenoid di K8 saat ini merupakan kekecewaan terbesar. Mereka tidak kompatibel. Secara teori, kita dapat memunculkan container Selenoid di dalam pod, tetapi saat Selenoid mulai meluncurkan container dengan browser, container tersebut akan tetap berada di dalam pod yang sama. Hal ini membuat penskalaan menjadi tidak mungkin dan, sebagai hasilnya, kerja Selenoid di dalam cluster tidak akan berbeda dengan kerja di dalam mesin virtual. Akhir dari cerita.
bulan:
Mengetahui hambatan ini saat bekerja dengan Selenoid, para pengembang merilis alat yang lebih canggih yang disebut Moon. Alat ini awalnya dirancang untuk bekerja dengan Kubernetes dan, sebagai hasilnya, fitur penskalaan otomatis dapat dan harus digunakan. Selain itu, saya akan mengatakan bahwa saat ini memang demikian satu-satunya sebuah alat di dunia Selenium, yang memiliki dukungan cluster K8 asli (tidak lagi tersedia, lihat alat berikutnya ). Fitur utama Moon yang menyediakan dukungan ini adalah:
Benar-benar tanpa kewarganegaraan. Selenoid menyimpan informasi memori tentang sesi browser yang sedang berjalan. Jika karena alasan tertentu prosesnya terhenti β maka semua sesi yang berjalan akan hilang. Sebaliknya, Moon tidak memiliki status internal dan dapat direplikasi di seluruh pusat data. Sesi browser tetap aktif meskipun satu atau lebih replika tidak berfungsi.
Jadi, Moon adalah solusi yang bagus, tapi ada satu masalah: ini tidak gratis. Harganya tergantung pada jumlah sesi. Anda hanya dapat menjalankan 0-4 sesi secara gratis, yang tidak terlalu berguna. Namun, mulai sesi kelima, Anda harus membayar $5 untuk setiap sesinya. Situasinya mungkin berbeda dari satu perusahaan ke perusahaan lain, tetapi dalam kasus kami, menggunakan Moon tidak ada gunanya. Seperti yang saya jelaskan di atas, kita dapat menjalankan VM dengan Selenium Grid sesuai permintaan atau menambah jumlah Node di cluster. Untuk kira-kira satu pipeline, kami meluncurkan 500 browser dan menghentikan semua sumber daya setelah pengujian selesai. Jika kami menggunakan Moon, kami harus membayar tambahan 500 x 5 = $2500 per bulan, tidak peduli seberapa sering kami menjalankan pengujian. Sekali lagi, saya tidak mengatakan jangan gunakan Moon. Untuk tugas Anda, ini bisa menjadi solusi yang sangat diperlukan, misalnya, jika Anda memiliki banyak proyek/tim di organisasi Anda dan Anda memerlukan cluster umum yang besar untuk semua orang. Seperti biasa, saya meninggalkan tautan di akhir dan merekomendasikan melakukan semua perhitungan yang diperlukan dalam konteks tugas Anda.
Callisto: (Perhatian! Ini tidak ada dalam artikel asli dan hanya terdapat dalam terjemahan bahasa Rusia)
Seperti yang saya katakan, Selenium adalah alat yang sangat populer, dan bidang TI berkembang sangat pesat. Saat saya sedang mengerjakan terjemahan, alat baru yang menjanjikan bernama Callisto muncul di web (halo Cypress dan pembunuh Selenium lainnya). Ia bekerja secara asli dengan K8 dan memungkinkan Anda menjalankan container Selenoid di pod, didistribusikan ke seluruh Node. Semuanya langsung berfungsi, termasuk penskalaan otomatis. Fantastis, tetapi perlu diuji. Saya telah berhasil menerapkan alat ini dan menjalankan beberapa eksperimen. Namun masih terlalu dini untuk mengambil kesimpulan, setelah mendapat hasil dari jarak jauh, mungkin saya akan melakukan review di artikel selanjutnya. Untuk saat ini saya hanya meninggalkan tautan untuk penelitian independen.
Ilustrasi kondisi infrastruktur saat ini
Tautan untuk dijelajahi
Alat serupa
7. Infrastruktur sebagai Kode (IaC)
Deskripsi singkat tentang teknologi
Dan sekarang kita sampai pada bagian terakhir. Biasanya, teknologi ini dan tugas terkait bukan merupakan tanggung jawab insinyur otomasi. Dan ada alasannya. Pertama, di banyak organisasi, masalah infrastruktur berada di bawah kendali departemen DevOps dan tim pengembangan tidak terlalu peduli tentang apa yang membuat pipeline berfungsi dan bagaimana segala sesuatu yang berhubungan dengannya perlu didukung. Kedua, jujur ββsaja, praktik Infrastruktur sebagai Kode (IaC) masih belum diterapkan di banyak perusahaan. Namun hal ini sudah pasti menjadi tren yang populer dan penting untuk mencoba terlibat dalam proses, pendekatan, dan alat yang terkait dengannya. Atau setidaknya tetap up to date.
Mari kita mulai dengan motivasi menggunakan pendekatan ini. Kita telah membahas bahwa untuk menjalankan pengujian di GitlabCI, kita memerlukan minimal sumber daya untuk menjalankan Gitlab Runner. Dan untuk menjalankan container dengan browser/emulator, kita perlu memesan VM atau cluster. Selain sumber daya pengujian, kami memerlukan sejumlah besar kapasitas untuk mendukung pengembangan, staging, lingkungan produksi, yang juga mencakup database, jadwal otomatis, konfigurasi jaringan, penyeimbang beban, hak pengguna, dan sebagainya. Persoalan utamanya adalah upaya yang diperlukan untuk mendukung itu semua. Ada beberapa cara untuk melakukan perubahan dan meluncurkan pembaruan. Misalnya, dalam konteks GCP, kita dapat menggunakan konsol UI di browser dan melakukan semua tindakan dengan mengklik tombol. Alternatifnya adalah menggunakan panggilan API untuk berinteraksi dengan entitas cloud, atau menggunakan utilitas baris perintah gcloud untuk melakukan manipulasi yang diinginkan. Namun dengan banyaknya entitas dan elemen infrastruktur yang berbeda, menjadi sulit atau bahkan tidak mungkin untuk melakukan semua operasi secara manual. Selain itu, semua tindakan manual ini tidak dapat dikendalikan. Kami tidak dapat mengirimkannya untuk ditinjau sebelum dieksekusi, menggunakan sistem kontrol versi, dan dengan cepat membatalkan perubahan yang menyebabkan insiden tersebut. Untuk mengatasi masalah tersebut, para insinyur membuat dan membuat skrip bash/shell otomatis, yang tidak jauh lebih baik dari metode sebelumnya, karena tidak mudah untuk dibaca, dipahami, dipelihara, dan dimodifikasi dengan cepat dalam gaya prosedural.
Dalam artikel dan panduan cara ini, saya menggunakan 2 alat yang terkait dengan praktik IaC. Ini adalah Terraform dan Ansible. Beberapa orang percaya bahwa tidak masuk akal untuk menggunakannya secara bersamaan, karena fungsinya serupa dan dapat dipertukarkan. Namun faktanya pada awalnya mereka diberi tugas yang sangat berbeda. Dan fakta bahwa alat-alat ini harus saling melengkapi dikonfirmasi pada presentasi bersama oleh pengembang yang mewakili HashiCorp dan RedHat. Perbedaan konseptualnya adalah Terraform adalah alat penyediaan untuk mengelola server itu sendiri. Sedangkan Ansible adalah alat manajemen konfigurasi yang bertugas menginstal, mengkonfigurasi, dan mengelola perangkat lunak di server tersebut.
Ciri pembeda utama lainnya dari alat ini adalah gaya pengkodeannya. Berbeda dengan bash dan Ansible, Terraform menggunakan gaya deklaratif berdasarkan deskripsi status akhir yang diinginkan untuk dicapai sebagai hasil eksekusi. Misalnya, jika kita akan membuat 10 VM dan menerapkan perubahannya melalui Terraform, maka kita akan mendapatkan 10 VM. Jika kita menjalankan skrip lagi, tidak akan terjadi apa-apa karena kita sudah memiliki 10 VM, dan Terraform mengetahui hal ini karena ia menyimpan status infrastruktur saat ini dalam file status. Namun Ansible menggunakan pendekatan prosedural dan jika diminta membuat 10 VM, maka pada peluncuran pertama kita akan mendapatkan 10 VM, mirip dengan Terraform. Tapi setelah restart kita sudah memiliki 20 VM. Inilah perbedaan penting. Dalam gaya prosedural, kami tidak menyimpan keadaan saat ini dan hanya menjelaskan urutan langkah-langkah yang harus dilakukan. Tentu saja, kita dapat menangani situasi yang berbeda, menambahkan beberapa pemeriksaan terhadap keberadaan sumber daya dan keadaan saat ini, namun tidak ada gunanya membuang-buang waktu dan berusaha mengendalikan logika ini. Selain itu, hal ini meningkatkan risiko melakukan kesalahan.
Meringkas semua hal di atas, kita dapat menyimpulkan bahwa Terraform dan notasi deklaratif adalah alat yang lebih cocok untuk penyediaan server. Namun lebih baik mendelegasikan pekerjaan manajemen konfigurasi ke Ansible. Mari kita lihat kasus penggunaan dalam konteks otomatisasi.
Nilai untuk infrastruktur otomasi
Satu-satunya hal penting untuk dipahami di sini adalah bahwa infrastruktur otomasi pengujian harus dianggap sebagai bagian dari keseluruhan infrastruktur perusahaan. Ini berarti bahwa semua praktik IaC harus diterapkan secara global pada sumber daya seluruh organisasi. Siapa yang bertanggung jawab atas hal ini bergantung pada proses Anda. Tim DevOps lebih berpengalaman dalam masalah ini, mereka melihat gambaran keseluruhan tentang apa yang terjadi. Namun, insinyur QA lebih terlibat dalam proses otomatisasi bangunan dan struktur saluran pipa, yang memungkinkan mereka melihat dengan lebih baik semua perubahan yang diperlukan dan peluang perbaikan. Pilihan terbaik adalah bekerja sama, bertukar pengetahuan dan ide untuk mencapai hasil yang diharapkan.
Berikut beberapa contoh penggunaan Terraform dan Ansible dalam konteks otomatisasi pengujian dan alat yang telah kita bahas sebelumnya:
1. Jelaskan karakteristik dan parameter yang diperlukan dari VM dan cluster menggunakan Terraform.
2. Menggunakan Ansible, instal alat yang diperlukan untuk pengujian: buruh pelabuhan, Selenoid, Selenium Grid dan unduh versi browser/emulator yang diperlukan.
3. Dengan menggunakan Terraform, jelaskan karakteristik VM tempat GitLab Runner akan diluncurkan.
4. Instal GitLab Runner dan alat pendukung yang diperlukan menggunakan Ansible, atur pengaturan dan konfigurasi.
Ilustrasi kondisi infrastruktur saat ini
Tautan untuk dijelajahi:
Alat serupa
Mari kita simpulkan!
Langkah
Teknologi
Tools
Nilai untuk infrastruktur otomasi
1
Lari lokal
Node.js, Selenium, Appium
- Alat paling populer untuk web dan seluler
- Mendukung banyak bahasa dan platform (termasuk Node.js)
2
Sistem kontrol versi
pergi
- Manfaat serupa dengan kode pengembangan
3
Kontainerisasi
Docker, jaringan Selenium, Selenoid (Web, Android)
- Menjalankan tes secara paralel
- Lingkungan terisolasi
- Peningkatan versi yang sederhana dan fleksibel
- Menghentikan sumber daya yang tidak digunakan secara dinamis
- Mudah diatur
4
CI/CD
Gitlab CI
- Menguji bagian dari pipa
- Umpan Balik Cepat
- Visibilitas untuk seluruh perusahaan/tim
5
Platform cloud
Google Cloud Platform
- Sumber daya sesuai permintaan (kami hanya membayar bila diperlukan)
- Mudah dikelola dan diperbarui
- Visibilitas dan kontrol semua sumber daya
6
Orkestrasi
Kubernetes
Dalam konteks container dengan browser/emulator di dalam pod:
- Penskalaan/penskalaan otomatis
- Penyembuhan diri sendiri
- Pembaruan dan pengembalian tanpa gangguan
7
Infrastruktur sebagai kode (IaC)
Terraform, Mungkin
- Manfaat serupa dengan pembangunan infrastruktur
- Semua manfaat pembuatan versi kode
- Mudah untuk melakukan perubahan dan pemeliharaan
- Sepenuhnya otomatis
Diagram peta pikiran: evolusi infrastruktur
langkah1: Lokal
langkah2: VCS
langkah3: Kontainerisasi
langkah4: CI/CD
langkah5: Platform Cloud
langkah6:Orkestrasi
langkah7: IaC
Apa selanjutnya?
Jadi, ini adalah akhir artikelnya. Namun sebagai kesimpulan, saya ingin membuat beberapa perjanjian dengan Anda.
Dari sisimu
Seperti yang saya katakan di awal, saya ingin artikel ini dapat memberikan manfaat praktis dan membantu Anda menerapkan pengetahuan yang diperoleh dalam pekerjaan nyata. saya menambahkan lagi.
Namun bahkan setelah itu, jangan berhenti, berlatih, pelajari tautan dan buku yang relevan, cari tahu cara kerjanya di perusahaan Anda, temukan tempat yang dapat ditingkatkan dan ambil bagian di dalamnya. Semoga beruntung!
Dari sisi saya
Dari judulnya terlihat bahwa ini hanyalah bagian pertama. Meski ternyata cukup besar, topik-topik penting masih belum tercakup di sini. Pada bagian kedua, saya berencana untuk melihat infrastruktur otomasi dalam konteks IOS. Karena pembatasan Apple dalam menjalankan simulator iOS hanya pada sistem macOS, jangkauan solusi kami menyempit. Misalnya, kami tidak dapat menggunakan Docker untuk menjalankan simulator atau cloud publik untuk menjalankan mesin virtual. Namun bukan berarti tidak ada alternatif lain. Saya akan mencoba memberi Anda informasi terkini tentang solusi canggih dan alat modern!
Selain itu, saya belum menyebutkan topik yang cukup besar terkait pemantauan. Di Bagian 3, saya akan melihat alat pemantauan infrastruktur paling populer serta data dan metrik apa yang perlu dipertimbangkan.
Dan akhirnya. Di masa depan, saya berencana untuk merilis kursus video tentang membangun infrastruktur pengujian dan alat-alat populer. Saat ini, terdapat cukup banyak kursus dan ceramah tentang DevOps di Internet, namun semua materi disajikan dalam konteks pengembangan, bukan otomatisasi pengujian. Mengenai masalah ini, saya sangat membutuhkan masukan tentang apakah kursus semacam itu akan menarik dan berharga bagi komunitas penguji dan insinyur otomasi. Terima kasih sebelumnya!
Sumber: www.habr.com