Get best of the week

Alat DevOps tidak hanya untuk DevOps. Proses membangun infrastruktur otomatisasi uji dari awal

Bagian 1: Web / Android


Catatan : artikel ini adalah terjemahan ke bahasa Rusia dari artikel asli  “Alat DevOps tidak hanya untuk DevOps. Membangun infrastruktur otomatisasi uji dari awal. " Namun, semua ilustrasi, tautan, kutipan, dan istilah disimpan dalam bahasa asli untuk menghindari distorsi makna ketika diterjemahkan ke dalam bahasa Rusia. Saya berharap Anda mendapat pelajaran yang menyenangkan!



Saat ini, spesialisasi DevOps adalah salah satu yang paling populer di industri TI. Jika Anda membuka situs pencarian kerja populer dan menetapkan filter gaji, Anda akan melihat bahwa pekerjaan yang terkait dengan DevOps ada di bagian atas daftar. Namun, penting untuk dipahami bahwa ini terutama merujuk pada posisi 'Senior', yang menyiratkan bahwa kandidat memiliki tingkat keterampilan, pengetahuan teknologi, dan alat yang tinggi. Itu juga datang dengan tingkat tanggung jawab yang tinggi terkait dengan kelancaran operasi produksi. Namun, kami mulai melupakan apa itu DevOps. Awalnya, itu bukan orang atau departemen tertentu. Jika kita mencari definisi dari istilah ini, kita akan menemukan banyak kata benda yang indah dan benar, seperti metodologi, praktik, filosofi budaya, sekelompok konsep dan sebagainya.

Spesialisasi saya adalah insinyur otomatisasi QA, tetapi saya percaya bahwa itu tidak hanya terkait dengan penulisan tes otomatis atau mengembangkan arsitektur untuk kerangka uji. Pada tahun 2020, pengetahuan tentang infrastruktur otomasi juga diperlukan. Ini memungkinkan Anda untuk mengatur sendiri proses otomasi, mulai dari peluncuran tes hingga penyediaan hasil untuk semua pihak yang berkepentingan sesuai dengan tujuan. Akibatnya, keterampilan DevOps adalah suatu keharusan untuk pekerjaan ini. Dan semua ini bagus, tetapi, sayangnya, ada masalah ( spoiler: artikel ini berupaya menyederhanakan masalah ini) Itu terletak pada kenyataan bahwa DevOps rumit. Dan ini jelas, karena perusahaan tidak akan membayar banyak untuk apa yang mudah dilakukan ... Di dunia DevOps ada sejumlah besar alat, istilah, praktik yang perlu dikuasai. Ini sangat sulit pada awal karir dan tergantung pada akumulasi pengalaman teknis.


Sumber: http://maximelanciauxbi.blogspot.com/2017/04/devops-tools.html

Di sini, kami mungkin akan melengkapi dengan bagian pengantar dan fokus pada tujuan artikel ini. 

Tentang apa artikel ini


Pada artikel ini saya akan membagikan pengalaman saya dalam membangun infrastruktur otomasi pengujian. Di Internet Anda dapat menemukan banyak sumber informasi tentang berbagai alat dan cara menggunakannya, tetapi saya ingin mempertimbangkannya secara eksklusif dalam konteks otomatisasi. Saya percaya bahwa banyak insinyur otomasi terbiasa dengan situasi di mana tidak ada yang menjalankan tes yang dikembangkan, kecuali untuk diri sendiri, dan tidak peduli dengan dukungan mereka. Akibatnya, tes menjadi usang dan Anda harus menghabiskan waktu untuk memperbaruinya. Sekali lagi, pada awal karier, ini bisa menjadi tugas yang cukup sulit: untuk memutuskan dengan tepat alat mana yang harus membantu menyelesaikan masalah ini, bagaimana memilih, mengkonfigurasi, dan memeliharanya. Beberapa penguji meminta bantuan dari DevOps (orang) dan, sejujurnya, pendekatan ini berhasil.Dalam banyak kasus, ini mungkin satu-satunya pilihan, karena kami tidak memiliki visibilitas semua dependensi. Tetapi, seperti kita ketahui, DevOps adalah orang yang sangat sibuk, karena mereka harus memikirkan infrastruktur seluruh perusahaan, penyebaran, pemantauan, layanan mikro, dan tugas serupa lainnya tergantung pada organisasi / tim. Seperti yang biasanya terjadi, otomatisasi bukanlah prioritas. Dalam hal ini, kita harus berusaha melakukan yang terbaik dari awal hingga akhir. Ini akan mengurangi kecanduan, mempercepat alur kerja, meningkatkan keterampilan kita dan memungkinkan kita untuk melihat gambaran yang lebih luas tentang apa yang terjadi.layanan microser dan tugas serupa lainnya tergantung pada organisasi / tim. Seperti yang biasanya terjadi, otomatisasi bukanlah prioritas. Dalam hal ini, kita harus berusaha melakukan yang terbaik dari awal hingga akhir. Ini akan mengurangi kecanduan, mempercepat alur kerja, meningkatkan keterampilan kita dan memungkinkan kita untuk melihat gambaran yang lebih luas tentang apa yang terjadi.layanan microser dan tugas serupa lainnya tergantung pada organisasi / tim. Seperti yang biasanya terjadi, otomatisasi bukanlah prioritas. Dalam hal ini, kita harus berusaha melakukan yang terbaik dari awal hingga akhir. Ini akan mengurangi kecanduan, mempercepat alur kerja, meningkatkan keterampilan kita dan memungkinkan kita untuk melihat gambaran yang lebih luas tentang apa yang terjadi.

Artikel ini menyajikan alat yang paling populer dan populer dan menunjukkan cara menggunakannya untuk pembangunan infrastruktur otomasi langkah demi langkah. Setiap kelompok diwakili oleh alat yang telah diuji pada pengalaman pribadi. Tetapi ini tidak berarti bahwa Anda harus menggunakan yang sama. Alat itu sendiri tidak penting, mereka muncul dan menjadi usang. Tugas rekayasa kami adalah memahami prinsip-prinsip dasar: mengapa kita membutuhkan kelompok alat ini dan tugas kerja apa yang dapat kita selesaikan dengan bantuan mereka. Karenanya, pada akhir setiap bagian, saya meninggalkan tautan ke alat serupa yang dapat digunakan di organisasi Anda.

Apa yang tidak ada dalam artikel ini


Sekali lagi, artikel ini bukan tentang alat khusus, jadi tidak akan ada penyisipan kode dari dokumentasi dan deskripsi perintah tertentu. Tetapi pada akhir setiap bagian saya meninggalkan tautan untuk studi terperinci.

Ini disebabkan oleh kenyataan bahwa: 

  • bahan ini sangat mudah ditemukan di berbagai sumber (dokumentasi, buku, kursus video);
  • jika kita mulai menggali lebih dalam, kita harus menulis 10, 20, 30 bagian dari artikel ini (sedangkan rencana 2-3);
  • Saya hanya tidak ingin membuang waktu Anda, karena mungkin Anda ingin menggunakan alat lain untuk mencapai tujuan yang sama.

Praktek


Saya ingin materi ini bermanfaat bagi setiap pembaca, dan tidak hanya dibaca dan dilupakan. Dalam studi apa pun, praktik adalah komponen yang sangat penting. Untuk melakukan ini, saya menyiapkan repositori GitHub dengan panduan langkah demi langkah tentang cara melakukan semuanya dari awal . Anda juga akan menunggu pekerjaan rumah untuk memastikan bahwa Anda tidak menyalin sembarang baris perintah yang dieksekusi

Rencana


LangkahTeknologiAlat
1Menjalankan lokal (menyiapkan tes demo web / android dan menjalankannya secara lokal) Node.js, Selenium, Appium
2Sistem kontrol versi Git
3KontainerisasiDocker, Selenium grid, Selenoid (Web, Android)
4CI / CDGitlab ci
5Platform cloudPlatform cloud Google
6OrkestrasiKubernetes
7Infrastruktur sebagai kode (IaC)Dapat bentuk, mungkin

Struktur setiap bagian


Untuk mempertahankan narasi dalam bentuk visual, setiap bagian dijelaskan sebagai berikut:

  • ,
  • ,
  • ,
  • ,
  • .

1.



Ini hanyalah langkah persiapan untuk menjalankan tes demo secara lokal dan untuk memverifikasi bahwa tes berhasil. Pada bagian praktis, Node.js digunakan, tetapi bahasa dan platform pemrograman juga tidak penting dan Anda dapat 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 gambar Docker yang dirancang khusus untuk bekerja secara khusus dengan alat-alat ini. Selain itu, mengacu pada persyaratan dalam lowongan, alat ini paling banyak diminati di pasar.

Seperti yang mungkin Anda perhatikan, kami hanya mempertimbangkan tes web dan Android. Sayangnya, iOS adalah cerita yang sama sekali berbeda (terima kasih kepada Apple). Saya berencana untuk menunjukkan solusi dan praktik yang terkait dengan iOS di bagian berikut.

Nilai untuk infrastruktur otomasi


Dari sudut pandang infrastruktur, peluncuran lokal tidak membawa nilai apa pun. Anda hanya memverifikasi bahwa tes berjalan pada mesin lokal di browser dan simulator lokal. Tetapi bagaimanapun juga, ini adalah titik awal yang perlu.

Ilustrasi kondisi infrastruktur saat ini




Tautan Belajar



Alat serupa


  • bahasa pemrograman apa pun yang Anda sukai bersama dengan Selenium / Appium - tes;
  • tes apa pun;
  • semua pelari ujian.

2. Sistem kontrol versi (Git)


Ringkasan Teknologi


Ini tidak akan menjadi penemuan besar bagi siapa pun jika saya mengatakan bahwa sistem kontrol versi adalah bagian yang sangat penting dari pengembangan baik sebagai tim maupun secara individual. Berdasarkan berbagai sumber, kami dapat dengan yakin mengatakan bahwa Git adalah perwakilan paling populer. Sistem kontrol versi memberikan banyak keuntungan, seperti pertukaran kode, penyimpanan versi, pemulihan ke cabang sebelumnya, pemantauan riwayat proyek, cadangan. Kami tidak akan membahas setiap item secara terperinci, karena saya yakin Anda mengetahui hal ini dan menggunakannya dalam pekerjaan sehari-hari. Tetapi jika tiba-tiba tidak, maka saya sarankan berhenti membaca artikel ini dan mengisi celah 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 tahu dan menggunakan ini untuk kode pengembangan dan kode uji otomatis. " Anda akan benar, tetapi dalam artikel ini kita berbicara tentang infrastruktur dan bagian ini memainkan peran pratinjau untuk bagian 7: "Infrastruktur sebagai kode (IaC)". Bagi kami, ini berarti bahwa seluruh infrastruktur, termasuk yang uji, dijelaskan dalam bentuk kode, sehingga kami juga dapat menerapkan sistem versi untuk itu dan mendapatkan keuntungan yang serupa untuk pengembangan dan kode otomatisasi.

Kami akan melihat IaC lebih terinci di langkah 7, tetapi bahkan sekarang Anda dapat mulai menggunakan Git secara lokal dengan membuat repositori lokal. Gambaran besar akan diperluas ketika kita menambahkan repositori jarak jauh ke infrastruktur.

Ilustrasi kondisi infrastruktur saat ini




Tautan Belajar



Alat serupa



3. Containerisasi (Docker)


Ringkasan Teknologi


Untuk mendemonstrasikan bagaimana containerisasi mengubah aturan permainan, mari kita kembali beberapa dekade. Pada masa itu, orang membeli dan menggunakan mesin server untuk menjalankan aplikasi. Tetapi dalam kebanyakan kasus, sumber daya yang diperlukan untuk diluncurkan tidak diketahui sebelumnya. Akibatnya, perusahaan membelanjakan uang untuk membeli server kuat yang mahal, tetapi beberapa kapasitas ini tidak sepenuhnya digunakan.

Tahap evolusi berikutnya adalah mesin virtual (VM), yang memecahkan masalah pengeluaran 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 kekurangan. Memulai VM membutuhkan sistem operasi lengkap yang menggunakan CPU, RAM, penyimpanan dan, tergantung pada OS, Anda perlu mempertimbangkan biaya lisensi. Faktor-faktor ini mempengaruhi kecepatan unduh dan mempersulit portabilitas.

Jadi kami datang ke wadah. Dan sekali lagi, teknologi ini memecahkan masalah sebelumnya, karena wadah tidak menggunakan OS lengkap, yang memungkinkan Anda untuk membebaskan sejumlah besar sumber daya dan menyediakan solusi cepat dan fleksibel untuk portabilitas.

Tentu saja, teknologi containerisasi bukanlah hal baru dan pertama kali diperkenalkan pada akhir 70-an. Pada masa itu, ada banyak penelitian, landasan, dan upaya. Tetapi Docker yang mengadaptasi teknologi ini dan membuatnya mudah diakses oleh massa. Saat ini, ketika kita berbicara tentang kontainer, dalam banyak kasus yang kita maksud adalah Docker. Ketika kita berbicara tentang kontainer Docker, yang kami maksud adalah kontainer Linux. Kita dapat menggunakan sistem Windows dan macOS untuk menjalankan kontainer, tetapi penting untuk memahami bahwa dalam hal ini lapisan tambahan muncul. Sebagai contoh, Docker pada Mac secara diam-diam meluncurkan wadah di dalam Linux VM yang ringan. Kami akan kembali ke topik ini ketika membahas peluncuran emulator Android di dalam wadah, dan di sinilah nuansa yang sangat penting muncul, yang perlu dianalisis secara lebih rinci.

Nilai untuk infrastruktur otomasi


Kami menemukan bahwa containerization dan Docker keren. Mari kita lihat ini dalam konteks otomatisasi, karena setiap alat atau teknologi harus menyelesaikan masalah. Mari kita tunjukkan masalah yang jelas dari otomatisasi pengujian dalam konteks pengujian UI:

  • sejumlah besar dependensi saat memasang Selenium dan terutama Appium;
  • masalah kompatibilitas antara versi peramban, simulator dan driver;
  • kurangnya ruang terisolasi untuk browser / simulator, yang sangat penting untuk peluncuran paralel;
  • Sulit untuk mengelola dan memelihara jika Anda perlu menjalankan 10, 50, 100 atau bahkan 1000 browser secara bersamaan.

Tetapi karena Selenium adalah alat otomasi yang paling populer, dan Docker adalah alat kemasukan yang paling populer, seharusnya tidak mengherankan bagi siapa pun bahwa seseorang mencoba menggabungkan mereka untuk mendapatkan alat yang kuat untuk memecahkan masalah di atas. Mari kita pertimbangkan solusi semacam itu secara lebih rinci. 

Grid selenium di buruh pelabuhan

Alat ini adalah yang paling populer di dunia Selenium untuk meluncurkan dan mengelola beberapa browser di beberapa mesin dari situs pusat. Untuk memulai, Anda harus mendaftarkan setidaknya 2 bagian: Hub dan Node. Hub adalah situs pusat yang menerima semua permintaan dari pengujian dan mendistribusikannya ke Node yang sesuai. Untuk setiap Node, kita dapat mengonfigurasi konfigurasi tertentu, misalnya, menentukan browser yang diinginkan dan versinya. Namun, kita masih harus menjaga sendiri driver browser yang kompatibel dan menginstalnya pada Nodes yang diperlukan. Untuk alasan ini, kisi Selenium tidak digunakan dalam bentuknya yang murni, kecuali ketika kita perlu bekerja dengan peramban yang tidak dapat diinstal pada OS Linux.Untuk semua kasus lain, menggunakan gambar Docker untuk menjalankan Hub grid Selenium dan Node adalah solusi yang jauh lebih fleksibel dan benar. Pendekatan ini sangat menyederhanakan pengelolaan node, karena kita dapat memilih gambar yang kita butuhkan dengan versi browser dan driver yang sudah diinstal.

Meskipun ada umpan balik negatif pada stabilitas, terutama ketika menjalankan sejumlah besar node secara paralel, Selenium grid masih merupakan alat yang paling populer untuk menjalankan tes Selenium secara paralel. Penting untuk dicatat bahwa dalam open-source berbagai perbaikan dan modifikasi dari alat ini terus-menerus muncul kesulitan dengan berbagai hambatan.

Selenoid untuk web

Alat ini merupakan terobosan di dunia Selenium, karena alat ini bekerja langsung dan membuat kehidupan banyak insinyur otomasi menjadi lebih mudah. Pertama-tama, ini bukan modifikasi lain dari jaringan Selenium. Sebagai gantinya, para pengembang menciptakan versi Selenium Hub yang sepenuhnya baru dalam bahasa Golang, yang, bersama dengan gambar Docker yang ringan untuk berbagai browser, memberikan dorongan untuk pengembangan otomatisasi uji. Selain itu, dalam kasus Selenium Grid, kita harus menentukan semua browser yang diperlukan dan versi mereka di muka, yang tidak menjadi masalah ketika bekerja dengan hanya satu browser. Tetapi ketika datang ke beberapa browser yang didukung, Selenoid adalah solusi nomor satu, berkat fitur 'browser sesuai permintaan'. Semua yang diperlukan dari kami adalah preload gambar yang diperlukan dengan browser dan memperbarui file konfigurasi,dimana Selenoid berinteraksi. Setelah Selenoid menerima permintaan dari tes, ia akan secara otomatis meluncurkan wadah yang tepat dengan browser yang tepat. Ketika tes selesai, Selenoid akan menjatuhkan wadah, sehingga membebaskan sumber daya untuk pertanyaan berikut. Pendekatan ini sepenuhnya menghilangkan masalah 'degradasi simpul' yang terkenal, yang sering kita lihat dalam kisi Selenium.

Namun sayang, Selenoid masih bukan peluru perak. Kami punya fitur browser berdasarkan permintaan, tetapi fitur sumber daya berdasarkan permintaan masih tidak tersedia. Untuk menggunakan Selenoid, kita perlu menggunakannya pada perangkat keras fisik atau VM, yang berarti bahwa kita harus tahu sebelumnya berapa banyak sumber daya yang perlu dialokasikan. Saya percaya ini bukan masalah untuk proyek-proyek kecil yang menjalankan 10, 20, atau bahkan 30 browser secara paralel. Tetapi bagaimana jika kita membutuhkan 100, 500, 1000 dan lebih banyak lagi? Tidak masuk akal untuk memelihara dan membayar begitu banyak sumber daya sepanjang waktu. Di bagian 5 dan 6 artikel ini, kami akan membahas solusi yang memungkinkan Anda untuk meningkatkan skala, sehingga secara signifikan mengurangi biaya perusahaan.

Selenoid untuk Android

Setelah kesuksesan Selenoid sebagai alat untuk otomatisasi web, orang ingin mendapatkan sesuatu yang serupa untuk Android. Dan itu terjadi - Selenoid dirilis dengan dukungan Android. Dari perspektif pengguna tingkat tinggi, prinsip operasi mirip dengan otomatisasi web. Satu-satunya perbedaan adalah bahwa alih-alih wadah dengan browser, Selenoid meluncurkan wadah dengan emulator Android. Menurut pendapat saya, hari ini ini adalah alat gratis paling kuat untuk menjalankan tes Android secara paralel.

Saya benar-benar tidak ingin berbicara tentang aspek negatif dari alat ini, karena saya sangat menyukainya. Tetapi masih ada kelemahan yang sama terkait dengan otomatisasi web terkait dengan penskalaan. Selain itu, kita perlu membicarakan batasan lain, yang mungkin mengejutkan jika kita menyetel instrumen untuk pertama kali. Untuk menjalankan gambar Android, kita membutuhkan mesin fisik atau VM dengan dukungan virtualisasi bersarang. Dalam panduan praktis, saya mendemonstrasikan cara mengaktifkan ini pada VM Linux. Namun, jika Anda adalah pengguna macOS dan ingin menggunakan Selenoid secara lokal, ini tidak akan mungkin untuk menjalankan tes Android. Tetapi Anda selalu dapat memulai Linux VM secara lokal dengan 'nested virtualization' yang dikonfigurasi dan menggunakan Selenoid di dalamnya.

Ilustrasi kondisi infrastruktur saat ini


Dalam konteks artikel ini, kami akan menambahkan 2 alat untuk menggambarkan infrastruktur. Ini adalah kisi Selenium untuk pengujian web dan Selenoid untuk pengujian Android. Dalam manual GitHub, saya juga akan menunjukkan cara menggunakan Selenoid untuk menjalankan tes web. 



Tautan Belajar



Alat serupa


  • Alat kontainerisasi lain ada, tetapi Docker adalah yang paling populer. Jika Anda ingin mencoba sesuatu yang lain, perlu diingat bahwa alat yang kami ulas untuk menjalankan tes Selenium secara paralel tidak akan berfungsi di luar kotak.  
  • Seperti yang telah disebutkan, ada banyak modifikasi kisi Selenium, misalnya, Zalenium .

4. CI / CD


Ringkasan Teknologi


Praktek integrasi berkelanjutan cukup populer dalam pengembangan dan setara dengan sistem kontrol versi. Meskipun demikian, saya merasa ada kebingungan dalam terminologi. Pada bagian ini, saya ingin menjelaskan 3 modifikasi teknologi ini dari sudut pandang saya. Di Internet, Anda dapat menemukan banyak artikel dengan interpretasi berbeda, dan sangat normal jika pendapat Anda berbeda. Yang paling penting adalah Anda berada pada gelombang yang sama dengan rekan kerja Anda.

Jadi, ada 3 istilah: CI - Continuous Integration (CD), CD - Continuous Delivery (CD) dan lagi CD - Continuous Deployment (CD). ( Selanjutnya saya akan menggunakan istilah-istilah ini dalam bahasa Inggris) Setiap modifikasi menambahkan beberapa langkah tambahan ke jalur pengembangan Anda. Tetapi kata terus menerus adalah yang paling penting. Dalam konteks ini, kami mengartikan sesuatu yang terjadi dari awal hingga akhir, tanpa gangguan atau paparan manual. Mari kita lihat CI & CD dan CD dalam konteks ini.

  • Integrasi berkelanjutan adalah langkah awal dalam evolusi. Setelah mengirim kode baru ke server, kami berharap mendapatkan umpan balik cepat bahwa semuanya sesuai dengan perubahan kami. Biasanya, CI mencakup peluncuran alat analisis kode statis dan pengujian API unit / internal. Ini memungkinkan Anda untuk mendapatkan informasi tentang kode kami beberapa detik / menit kemudian.
  • Continuous Delivery , /UI-. , CI. -, . -, test/staging — . , , .
  • Continuous Deployment , (release) production, . release , smoke — production . Continuous Deployment . - , , Continuous (). , Continuous Delivery.


Di bagian ini, saya harus mengklarifikasi bahwa ketika kita berbicara tentang tes UI end-to-end, ini menyiratkan bahwa kita harus menyebarkan perubahan dan layanan terkait ke lingkungan pengujian. Integrasi Berkelanjutan - proses ini tidak berlaku untuk tugas ini dan kami harus berhati-hati untuk menerapkan setidaknya praktik Pengiriman Berkelanjutan. Penerapan Berkelanjutan juga masuk akal dalam konteks pengujian UI jika kami akan menjalankannya pada produksi.

Dan sebelum kita melihat ilustrasi perubahan arsitektur, saya ingin mengatakan beberapa kata tentang GitLab CI. Tidak seperti alat CI / CD lainnya, GitLab menyediakan repositori jarak jauh dan banyak fitur canggih lainnya. Jadi GitLab lebih dari CI. Ini termasuk di luar kendali sumber kotak, manajemen Agile, jalur pipa CI / CD, alat logging, dan koleksi metrik. Arsitektur GitLab terdiri dari Gitlab CI / CD dan GitLab Runner. Saya memberikan deskripsi singkat dari situs resmi:
Gitlab CI / CD adalah aplikasi web dengan API yang menyimpan statusnya dalam database, mengelola proyek / membangun dan menyediakan antarmuka pengguna. GitLab Runner adalah aplikasi yang memproses pembangunan. Ini dapat digunakan secara terpisah dan bekerja dengan GitLab CI / CD melalui API. Untuk tes yang berjalan Anda membutuhkan instance Gitlab dan Runner.








5.



Di bagian ini, kita akan berbicara tentang tren populer yang disebut 'cloud publik'. Terlepas dari manfaat luar biasa yang diberikan oleh teknologi virtualisasi dan kontainerisasi di atas, kita masih membutuhkan sumber daya komputasi. Perusahaan membeli server mahal atau menyewa pusat data, tetapi dalam hal ini perlu untuk membuat perhitungan (kadang-kadang tidak realistis) dari berapa banyak sumber daya yang akan kita butuhkan, apakah kita akan menggunakannya 24/7 dan untuk tujuan apa. Misalnya, produksi memerlukan server yang beroperasi sepanjang waktu, tetapi apakah kita memerlukan sumber daya yang serupa untuk pengujian setelah jam kerja? Itu juga tergantung pada jenis pengujian yang dilakukan. Contohnya adalah tes stres / stres, yang kami rencanakan untuk dijalankan setelah jam kerja untuk mendapatkan hasil pada hari berikutnya. Tapi yang pastiKetersediaan server 24 jam tidak diperlukan untuk pengujian otomatis end-to-end, dan terutama untuk lingkungan pengujian manual. Untuk situasi seperti itu, akan baik untuk menerima sumber daya sebanyak yang dibutuhkan sesuai permintaan, menggunakannya dan berhenti membayar ketika mereka tidak lagi dibutuhkan. Selain itu, akan lebih baik untuk menerimanya secara instan dengan membuat beberapa klik mouse atau dengan menjalankan beberapa skrip. Untuk ini, awan publik digunakan. Mari kita lihat definisi:Untuk ini, awan publik digunakan. Mari kita lihat definisi:Untuk ini, awan publik digunakan. Mari kita lihat definisi:
“Cloud publik didefinisikan sebagai layanan komputasi yang ditawarkan oleh penyedia pihak ketiga melalui Internet publik, menjadikannya tersedia bagi siapa saja yang ingin menggunakan atau membelinya. "Mereka mungkin gratis atau dijual sesuai permintaan, yang memungkinkan pelanggan hanya membayar per penggunaan untuk siklus CPU, penyimpanan, atau bandwidth yang mereka konsumsi."

Ada pendapat bahwa awan publik itu mahal. Tetapi ide utama mereka adalah mengurangi biaya perusahaan. Seperti yang disebutkan sebelumnya, cloud publik memungkinkan Anda untuk mendapatkan sumber daya sesuai permintaan dan membayar hanya untuk saat mereka digunakan. Juga, kadang-kadang kita lupa bahwa karyawan dibayar, dan spesialis juga merupakan sumber daya yang mahal. Perlu diingat bahwa cloud publik sangat memudahkan dukungan infrastruktur, yang memungkinkan para insinyur untuk fokus pada tugas yang lebih penting. 

Nilai untuk infrastruktur otomasi


Sumber daya spesifik apa yang kita butuhkan untuk tes UI end-to-end? Ini terutama mesin virtual atau cluster (kita akan berbicara tentang Kubernetes di bagian selanjutnya) untuk meluncurkan browser dan emulator. Semakin banyak peramban dan emulator yang ingin kita jalankan pada saat yang bersamaan, semakin banyak CPU dan memori yang dibutuhkan dan semakin banyak uang yang harus kita bayar untuk itu. Dengan demikian, cloud publik dalam konteks otomatisasi pengujian memungkinkan kami untuk meluncurkan sejumlah besar (100, 200, 1000 ...) browser / emulator sesuai permintaan, mendapatkan hasil pengujian secepat mungkin dan berhenti membayar untuk kapasitas intensif sumber daya yang gila. 

Penyedia cloud paling populer adalah Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Panduan praktis memberikan contoh penggunaan GCP, tetapi secara umum tidak masalah apa yang akan Anda gunakan untuk tugas otomasi. Semuanya menyediakan fungsionalitas yang kira-kira sama. Biasanya, untuk memilih penyedia, manajemen berfokus pada seluruh infrastruktur dan persyaratan bisnis perusahaan, yang berada di luar cakupan artikel ini. Akan lebih menarik bagi para insinyur otomasi untuk membandingkan penggunaan penyedia cloud menggunakan platform cloud khusus untuk tujuan pengujian seperti Sauce Labs, BrowserStack, BitBar dan sebagainya. Jadi mari kita lakukan hal yang sama! Menurut pendapat saya, Lab Saus adalah peternakan pengujian awan paling terkenal, jadi saya mengambilnya untuk perbandingan. 

Lab GCP vs Saus untuk Otomasi:

Bayangkan bahwa kita perlu menjalankan 8 tes web dan 8 tes Android secara bersamaan. Untuk melakukan ini, kita akan menggunakan GCP dan menjalankan 2 mesin virtual dengan Selenoid. Yang pertama kita akan mengumpulkan 8 kontainer dengan browser. Pada yang kedua - 8 wadah dengan emulator. Mari kita lihat harga:  


Untuk menjalankan satu wadah dengan Chrome, kami membutuhkan mesin n1-standard-1 . Dalam kasus Android, ini akan menjadi n1-standard-4 untuk satu emulator. Sebenarnya, cara yang lebih fleksibel dan lebih murah adalah dengan menetapkan nilai pengguna tertentu untuk CPU / Memori, tetapi saat ini tidak penting untuk dibandingkan dengan Sauce Labs.

Dan berikut adalah tarif untuk menggunakan Lab Saus:


Saya kira Anda sudah memperhatikan perbedaannya, tetapi saya masih akan memberikan tabel dengan perhitungan untuk tugas kami:

Sumber daya yang dibutuhkanMontlyJam kerja (8 pagi - 8 malam)Jam kerja + Preemptible
Gcp untuk webn1-standard-1 x 8 = n1-standard-8$ 194,1823 hari * 12j * 0,38 = 104,88 $ 23 hari * 12j * 0,08 = 22,08 $
Lab Saus untuk WebTes paralel Cloud8 virtual$ 1,559--
GCP untuk Androidn1-standar-4 x 8: n1-standar-16$ 776,7223 hari * 12j * 1,52 = $ 419,52 23 hari * 12j * 0,32 = 88,32 $
Lab Saus untuk AndroidReal Device Cloud 8 tes paralel$ 1,999--

Seperti yang Anda lihat, perbedaan biaya sangat besar, terutama jika Anda menjalankan tes hanya dalam periode dua belas jam kerja. Tetapi Anda dapat mengurangi biaya lebih lanjut dengan menggunakan mesin preemptible. Apa itu?
A preemptible VM is an instance that you can create and run at a muchower price than normal instances. However, Compute Engine might terminate (preempt) these instances if it requires access to those resources for other tasks. Preemptible instances are excess Compute Engine capacity, so their availability varies with usage.

If your apps are fault-tolerant and can withstand possible instance preemptions, then preemptible instances can reduce your Compute Engine costs significantly. For example, batch processing jobs can run on preemptible instances. If some of those instances terminate during processing, the job slows but does not completely stop. Preemptible instances complete your batch processing tasks without placing additional workload on your existing instances and without requiring you to pay full price for additional normal instances.

Dan ini masih belum berakhir! Faktanya, saya yakin tidak ada yang menjalankan tes selama 12 jam tanpa istirahat. Dan jika demikian, maka Anda dapat secara otomatis memulai dan menghentikan mesin virtual ketika mereka tidak diperlukan. Waktu penggunaan aktual dapat turun hingga 6 jam per hari. Maka pembayaran dalam konteks tugas kita akan berkurang sebanyak $ 11 per bulan untuk 8 browser. Bukankah itu sempurna? Tetapi dengan mesin preemptible, kita harus berhati-hati dan siap untuk gangguan dan operasi yang tidak stabil, meskipun situasi ini dapat disediakan dan diproses secara programatis. Itu sangat berharga!

Tetapi tidak berarti saya mengatakan 'tidak pernah menggunakan pertanian pengujian cloud'. Mereka memiliki beberapa keunggulan. Pertama-tama, ini bukan hanya mesin virtual, tetapi solusi lengkap untuk menguji otomatisasi dengan serangkaian fungsi di luar kotak: akses jarak jauh, log, tangkapan layar, perekaman video, berbagai browser dan perangkat seluler fisik. Dalam banyak situasi, ini bisa menjadi alternatif yang sangat baik. Terutama platform uji berguna untuk otomatisasi IOS ketika cloud publik hanya dapat menawarkan sistem Linux / Windows. Tetapi pembicaraan tentang iOS akan ada di artikel mendatang. Saya sarankan untuk selalu melihat situasi dan mulai dari tugas: di beberapa lebih murah dan lebih efisien untuk menggunakan cloud publik, dan di beberapa platform uji pasti sepadan dengan uang yang dikeluarkan.

Ilustrasi kondisi infrastruktur saat ini




Tautan Belajar



Alat serupa:



6. Orkestrasi


Ringkasan Teknologi


Saya punya kabar baik - kita hampir mencapai akhir artikel! Saat ini, infrastruktur otomasi kami terdiri dari pengujian web dan Android, yang kami jalankan melalui GitLab CI secara paralel, menggunakan alat dengan dukungan Docker: Selenium grid dan Selenoid. Selain itu, kami menggunakan mesin virtual yang dibuat melalui GCP untuk mengangkat kontainer dengan browser dan emulator di dalamnya. Untuk mengurangi biaya, kami memulai mesin virtual ini hanya berdasarkan permintaan dan berhenti saat pengujian tidak dilakukan. Adakah hal lain yang dapat meningkatkan infrastruktur kita? Jawabannya iya! Temui Kubernetes (K8s)!

Untuk memulai, pertimbangkan bagaimana kata orkestrasi, klaster, dan Kubernet saling berhubungan. Pada tingkat tinggi, orkestrasi adalah sistem yang menyebarkan dan mengelola aplikasi. Untuk mengotomatisasi pengujian, aplikasi kemas tersebut adalah Selenium grid dan Selenoid. Docker dan K8 saling melengkapi. Yang pertama digunakan untuk menyebarkan aplikasi, yang kedua untuk orkestrasi. Pada gilirannya, K8 adalah sebuah cluster. Tugas cluster adalah menggunakan VMs sebagai Nodes, yang memungkinkan Anda untuk menginstal berbagai fungsi, program, dan layanan dalam satu server (cluster). Jika salah satu Node crash, maka Node lain akan mengambil, yang memastikan aplikasi kita berjalan dengan lancar. Selain itu, K8 memiliki fungsi penting yang terkait dengan penskalaan,berkat itu kami secara otomatis mendapatkan jumlah sumber daya yang optimal, berdasarkan beban dan batasan yang ditetapkan.

Sebenarnya, menggunakan Kubernet secara manual dari awal adalah tugas yang sepenuhnya tidak sepele. Saya akan meninggalkan tautan ke Kubernetes The Hard Way, panduan praktis yang terkenal, dan jika Anda tertarik, Anda dapat berlatih. Tapi, untungnya, ada cara dan alat alternatif. Yang termudah dari mereka adalah menggunakan Google Kubernetes Engine (GKE) di GCP, yang akan memungkinkan Anda untuk mendapatkan cluster yang sudah jadi setelah beberapa klik. Untuk memulai studi, saya sarankan Anda menggunakan pendekatan ini, karena akan memungkinkan Anda untuk fokus belajar cara menggunakan K8 untuk tugas Anda, daripada mengeksplorasi bagaimana komponen internal harus diintegrasikan. 

Nilai untuk infrastruktur otomasi


Pertimbangkan beberapa fitur penting yang disediakan K8:

  • : multi-nodes , VMs;
  • : , ;
  • (Self-healing): pods ( );
  • : ,

Tapi K8 masih bukan peluru perak. Untuk memahami semua kelebihan dan keterbatasan dalam konteks alat yang kami pertimbangkan (Selenium grid, Selenoid), kami secara singkat membahas struktur K8. Cluster berisi dua jenis Nodes: Master Nodes dan Workers Nodes. Master Nodes bertanggung jawab untuk mengelola, menyebarkan, dan menjadwalkan keputusan. Node pekerja adalah tempat aplikasi berjalan. Node juga berisi lingkungan peluncuran wadah. Dalam kasus kami, ini adalah Docker, yang bertanggung jawab untuk operasi yang terkait dengan kontainer. Tetapi ada solusi alternatif seperti containerd. Penting untuk dipahami bahwa penskalaan atau penyembuhan diri tidak berlaku untuk wadah secara langsung. Hal ini dilakukan dengan menambahkan / mengurangi jumlah polong, yang pada gilirannya berisi kontainer (biasanya satu kontainer per pod, tetapi mungkin ada lebih banyak tergantung pada tugas). Hirarki tingkat tinggi adalah simpul pekerja, di dalamnya terdapat polong, di dalam mana kontainer dinaikkan.

Fungsi penskalaan adalah kunci dan dapat diterapkan baik ke node di dalam kumpulan node-pool, dan untuk pod di dalam node. Ada 2 jenis penskalaan yang berlaku untuk node dan pod. Jenis pertama - penskalaan horizontal terjadi karena peningkatan jumlah node / polong. Jenis ini lebih disukai. Jenis kedua, masing-masing, adalah vertikal. Penskalaan dilakukan dengan meningkatkan ukuran node / polong, bukan jumlahnya.

Sekarang pertimbangkan alat kami dalam konteks istilah di atas.

Kisi selenium

Seperti yang disebutkan sebelumnya, Selenium grid adalah alat yang sangat populer, dan itu tidak mengherankan bahwa itu kemas. Oleh karena itu, tidak mengherankan bahwa jaringan Selenium dapat digunakan di K8s. Contoh cara melakukan ini dapat ditemukan di repositori resmi K8. Seperti biasa, saya melampirkan tautan di bagian akhir. Selain itu, panduan praktis menunjukkan bagaimana melakukan ini dalam seri Terraform. Ada juga instruksi tentang cara menskala jumlah polong yang berisi kontainer dengan browser. Tetapi fitur penskalaan otomatis dalam konteks K8s masih belum jelas. Ketika saya mulai belajar, saya tidak menemukan panduan atau rekomendasi praktis.Setelah beberapa penelitian dan percobaan dengan dukungan tim DevOps, kami memilih pendekatan meningkatkan wadah dengan browser yang diinginkan di dalam satu pod, yang terletak di dalam satu node pekerja. Metode ini memungkinkan kita untuk menerapkan strategi penskalaan horizontal node dengan meningkatkan jumlahnya. Saya berharap bahwa di masa depan situasinya akan berubah, dan kita akan melihat semakin banyak deskripsi tentang pendekatan terbaik dan solusi turnkey, terutama setelah rilis Selenium grid 4 dengan arsitektur internal yang dimodifikasi.terutama setelah rilis Selenium grid 4 dengan arsitektur internal yang didesain ulang.terutama setelah rilis Selenium grid 4 dengan arsitektur internal yang didesain ulang.

Selenoid :

Saat ini, menyebarkan Selenoid di K8 adalah kekecewaan terbesar. Mereka tidak kompatibel. Secara teoritis, kita bisa menaikkan wadah Selenoid di dalam pod, tetapi ketika Selenoid mulai meluncurkan kontainer dengan browser, mereka akan tetap berada di dalam pod yang sama. Ini membuat penskalaan menjadi tidak mungkin dan, sebagai hasilnya, pekerjaan Selenoid di dalam cluster tidak akan berbeda dari pekerjaan di dalam mesin virtual. Akhir dari cerita.

Bulan :

Mengetahui hambatan ini saat bekerja dengan Selenoid, para pengembang merilis alat yang lebih kuat yang disebut Moon. Alat ini awalnya dirancang untuk bekerja dengan Kubernetes dan, sebagai hasilnya, Anda dapat dan harus menggunakan fungsi skala otomatis. Selain itu, saya akan mengatakan bahwa saat ini adalah satu - satunyaalat di dunia Selenium, yang di luar kotak memiliki dukungan kluster 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 macet - maka semua sesi yang berjalan hilang. Bulan sebaliknya tidak memiliki keadaan internal dan dapat direplikasi di seluruh pusat data. Sesi browser tetap hidup bahkan jika satu atau lebih replika turun.
Jadi, Moon adalah solusi hebat, tetapi dengan satu masalah, itu tidak gratis. Harga tergantung pada jumlah sesi. Hanya 0-4 sesi yang dapat diluncurkan secara gratis, yang tidak terlalu berguna. Tapi, mulai dari sesi kelima, Anda harus membayar $ 5 untuk masing-masing. Situasinya mungkin berbeda dari perusahaan ke perusahaan, tetapi dalam kasus kami, menggunakan Moon tidak ada gunanya. Seperti yang saya jelaskan di atas, kita dapat memulai VMs dengan Selenium Grid sesuai permintaan atau menambah jumlah Node dalam cluster. Untuk sekitar satu saluran pipa, kami meluncurkan 500 browser dan menghentikan semua sumber daya setelah tes selesai. Jika kami menggunakan Moon, kami harus membayar ekstra 500 x 5 = $ 2500 per bulan dan tidak masalah seberapa sering kami menjalankan tes. Dan lagi, saya tidak mengatakan "jangan gunakan Bulan." Untuk tugas Anda, ini bisa menjadi solusi yang sangat diperlukan, misalnya,jika Anda memiliki banyak proyek / tim di organisasi Anda dan Anda memerlukan kelompok umum yang besar untuk semua orang. Seperti biasa, saya meninggalkan tautan di bagian akhir dan merekomendasikan untuk membuat semua perhitungan yang diperlukan dalam konteks tugas Anda.

Callisto : ( Perhatian! Ini bukan di artikel asli dan hanya ada dalam terjemahan Rusia )

Seperti yang saya katakan, Selenium adalah alat yang sangat populer, dan industri TI berkembang sangat cepat. Ketika saya sedang mengerjakan terjemahan, alat Callisto baru yang menjanjikan muncul di jaringan (halo Cypress dan pembunuh Selenium lainnya). Ini bekerja secara asli dengan K8 dan memungkinkan Anda untuk menjalankan wadah Selenoid di pod, didistribusikan oleh Nodes. Semuanya berfungsi dengan baik, termasuk autoscaling. Fiksi, tetapi perlu untuk menguji. Saya sudah berhasil menggunakan alat ini dan melakukan beberapa percobaan. Tetapi masih terlalu dini untuk menarik kesimpulan, setelah menerima hasilnya dari jarak jauh, mungkin saya akan mengulas di artikel berikut. Sejauh ini saya hanya menyisakan tautan untuk penelitian independen.  







7. (IaC)



Jadi kami sampai di bagian terakhir. Biasanya, teknologi ini dan tugas terkait tidak termasuk dalam bidang tanggung jawab insinyur otomasi. Dan ada alasan untuk ini. Pertama, di banyak organisasi, masalah infrastruktur berada di bawah kendali departemen DevOps dan tim pengembangan tidak terlalu peduli dengan apa yang bekerja dengan pipeline dan bagaimana mendukung segala sesuatu yang berkaitan dengannya. Kedua, mari kita jujur, praktik "Infrastruktur sebagai Kode (IaC)" masih belum diterapkan di banyak perusahaan. Tapi itu pasti telah menjadi tren yang populer, dan penting untuk mencoba terlibat dalam proses, pendekatan, dan alat terkait. Atau setidaknya mengikuti perkembangan.

Mari kita mulai dengan motivasi untuk menggunakan pendekatan ini. Kami telah membahas bahwa untuk menjalankan tes di GitlabCI, kami membutuhkan setidaknya sumber daya untuk menjalankan Gitlab Runner. Dan untuk menjalankan kontainer dengan browser / emulator, kita perlu memesan VM atau cluster. Selain menguji sumber daya, kami membutuhkan sejumlah besar kapasitas untuk mendukung lingkungan pengembangan, pementasan, produksi, yang juga mencakup basis data, jadwal otomatis, konfigurasi jaringan, penyeimbang beban, hak pengguna, dan sebagainya. Masalah utama adalah upaya yang diperlukan untuk mendukung semua ini. Ada beberapa cara di mana kita dapat membuat perubahan dan meluncurkan pembaruan. Misalnya, dalam konteks GCP, kita dapat menggunakan konsol UI di browser dan melakukan semua tindakan dengan mengklik tombol.Cara alternatif adalah menggunakan panggilan API untuk berinteraksi dengan entitas cloud atau menggunakan utilitas baris perintah gcloud untuk melakukan manipulasi yang diperlukan. Tetapi dengan sejumlah besar 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 mengirim mereka untuk ditinjau sebelum dieksekusi, menggunakan sistem kontrol versi dan dengan cepat memutar kembali pengeditan yang menyebabkan insiden tersebut. Untuk mengatasi masalah tersebut, para insinyur menciptakan dan membuat skrip bash / shell otomatis, yang tidak jauh lebih baik dari metode sebelumnya, karena mereka tidak begitu mudah dibaca, dipahami, dipelihara, dan dimodifikasi dalam gaya prosedural.

Dalam artikel ini dan caranya, saya menggunakan 2 alat yang berhubungan dengan praktik IaC. Ini adalah Terraform dan Ansible. Beberapa percaya bahwa tidak masuk akal untuk menggunakannya secara bersamaan, karena fungsinya mirip dan dapat dipertukarkan. Tetapi kenyataannya adalah bahwa pada awalnya mereka dihadapkan dengan tugas yang sama sekali berbeda. Dan fakta bahwa alat-alat ini harus saling melengkapi dikonfirmasi pada presentasi bersama oleh pengembang yang mewakili HashiCorp dan RedHat. Perbedaan konseptual adalah bahwa Terraform adalah alat penyediaan untuk mengelola server sendiri. Sedangkan Ansible adalah alat manajemen konfigurasi yang tugasnya untuk menginstal, mengkonfigurasi dan mengelola perangkat lunak pada server ini.

Fitur lain yang membedakan kunci dari alat-alat ini adalah gaya penulisan kode. Tidak seperti bash dan Ansible, Terraform menggunakan gaya deklaratif berdasarkan deskripsi keadaan akhir yang diinginkan, yang harus dicapai sebagai hasil dari eksekusi. Misalnya, jika kita akan membuat 10 VM dan menerapkan perubahan melalui Terraform, maka kita mendapatkan 10 VM. Jika Anda menerapkan skrip lagi, tidak ada yang akan terjadi, karena kami sudah memiliki 10 VM, dan Terraform mengetahuinya, karena ia menyimpan keadaan infrastruktur saat ini dalam file status. Tetapi Ansible menggunakan pendekatan prosedural dan, jika Anda memintanya untuk membuat 10 VM, maka pada jalankan pertama kami mendapatkan 10 VM, sama dengan Terraform. Tetapi setelah restart, kita sudah memiliki 20 VM. Ini perbedaan penting.Dalam gaya prosedural, kami tidak menyimpan keadaan saat ini dan hanya menggambarkan urutan langkah-langkah yang harus diselesaikan. Tentu saja, kita dapat menangani berbagai situasi, menambahkan beberapa pemeriksaan untuk keberadaan sumber daya dan keadaan saat ini, tetapi tidak ada gunanya membuang waktu kita dan melakukan upaya untuk mengendalikan logika ini. Selain itu, ini meningkatkan risiko membuat kesalahan. 

Meringkas semua hal di atas, kita dapat menyimpulkan bahwa untuk server penyediaan, Terraform dan notasi deklaratif adalah alat yang lebih cocok. Tetapi pekerjaan manajemen konfigurasi lebih baik didelegasikan ke Ansible. Setelah mengatasinya, mari kita lihat contoh penggunaan dalam konteks otomatisasi.

Nilai untuk infrastruktur otomasi


Penting untuk dipahami hanya bahwa infrastruktur otomatisasi pengujian harus dipertimbangkan sebagai bagian dari seluruh infrastruktur perusahaan. Ini berarti bahwa semua praktik IaC harus diterapkan secara global ke sumber daya seluruh organisasi. Siapa yang bertanggung jawab untuk ini tergantung pada proses Anda. Tim DevOps lebih berpengalaman dalam hal ini, mereka melihat seluruh gambaran tentang apa yang terjadi. Namun, insinyur QA lebih terlibat dalam proses otomatisasi bangunan dan struktur pipa, yang memungkinkan mereka untuk melihat dengan lebih baik semua perubahan yang diperlukan dan peluang untuk peningkatan. Pilihan terbaik adalah bekerja bersama, berbagi pengetahuan dan ide untuk mencapai hasil yang diharapkan. 

Berikut adalah beberapa contoh penggunaan Terraform dan Ansible dalam konteks pengujian otomasi dan alat-alat yang telah kita diskusikan sebelumnya:

1. Jelaskan melalui Terraform karakteristik dan parameter yang diperlukan dari VM dan kluster.

2. Instal dengan Ansible alat yang diperlukan untuk pengujian: buruh pelabuhan, Selenoid, Selenium Grid dan unduh versi browser / emulator yang diperlukan.

3. Jelaskan melalui Terraform karakteristik VM tempat GitLab Runner akan diluncurkan.

4. Instal dengan Ansible GitLab Runner dan alat terkait yang diperlukan, atur pengaturan dan konfigurasi.

Ilustrasi kondisi infrastruktur saat ini



Tautan studi:



Alat serupa




Untuk meringkas!


LangkahTeknologiAlatNilai untuk infrastruktur otomasi
1Local runningNode.js, Selenium, Appium
  • web mobile
  • ( Node.js)

2Version control systems Git

3ContainerisationDocker, Selenium grid, Selenoid (Web, Android)
  • ,

4CI / CDGitlab CI
  • /

5Cloud platformsGoogle Cloud Platform
  • ( )

6OrchestrationKubernetes/ pods:
  • /

7Infrastruktur sebagai kode (IaC)Dapat bentuk, mungkin
  • Manfaat serupa dengan infrastruktur pembangunan
  • Semua manfaat dari versi kode
  • Mudah melakukan perubahan dan pemeliharaan
  • Otomatis sepenuhnya



Diagram mind map: evolusi infrastruktur


step1: Lokal


step2: vcs


step3: Kontainerisasi 


langkah4: CI / CD 


step5: Platform Cloud


Langkah 6: orkestrasi


langkah7: IaC


Apa berikutnya?


Jadi ini adalah akhir dari artikel ini. Tapi sebagai kesimpulan, saya ingin membuat beberapa perjanjian dengan Anda.

Di pihak Anda
Seperti yang dikatakan di awal, saya ingin artikel ini praktis digunakan dan membantu Anda menerapkan pengetahuan yang diperoleh dalam pekerjaan nyata. Saya menambahkan lagi tautan ke panduan praktis .

Tetapi bahkan setelah itu, jangan berhenti, berlatih, pelajari tautan dan buku yang relevan, cari tahu cara kerjanya di perusahaan Anda, temukan tempat-tempat yang dapat ditingkatkan dan ambil bagian di dalamnya. Semoga berhasil

Dari sisi saya

Dari judulnya jelas bahwa ini hanya bagian pertama. Terlepas dari kenyataan bahwa itu ternyata cukup besar, topik penting masih belum diungkapkan di sini. Pada bagian kedua, saya berencana untuk mempertimbangkan infrastruktur otomasi dalam konteks iOS. Karena keterbatasan Apple tentang menjalankan simulasi iOS hanya pada sistem macOS, solusi kami telah dipersempit. Misalnya, kami tidak dapat menggunakan Docker untuk menjalankan simulator atau cloud publik untuk menjalankan mesin virtual. Tetapi ini tidak berarti bahwa tidak ada alternatif lain. Saya akan mencoba untuk membuat Anda tetap up to date dengan solusi canggih dan alat modern!

Juga, saya tidak menyebutkan topik yang cukup besar terkait pemantauan. Di Bagian 3, saya akan mempertimbangkan alat paling populer untuk memantau infrastruktur, 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 ada cukup banyak kursus dan kuliah tentang DevOps di Internet, tetapi semua materi disajikan dalam konteks pengembangan, tetapi tidak menguji otomatisasi. Dalam hal ini, saya benar-benar membutuhkan umpan balik jika kursus ini akan menarik dan berharga bagi komunitas penguji dan insinyur otomasi. Terima kasih sebelumnya!

More articles:


All Articles