Bahagian 1: Web/Android
Nota: artikel ini adalah terjemahan ke bahasa Rusia dari artikel asal Walau bagaimanapun, semua ilustrasi, pautan, petikan dan istilah dikekalkan dalam bahasa asal untuk mengelakkan penyelewengan makna apabila diterjemahkan ke dalam bahasa Rusia. Saya doakan anda selamat belajar!
Pada masa ini, kepakaran DevOps adalah salah satu yang paling diminati dalam industri IT. Jika anda membuka tapak carian pekerjaan yang popular dan menapis mengikut gaji, anda akan melihat bahawa pekerjaan berkaitan DevOps berada di bahagian atas senarai. Walau bagaimanapun, adalah penting untuk memahami bahawa ini terutamanya merujuk kepada jawatan 'Senior', yang membayangkan bahawa calon mempunyai tahap kemahiran, pengetahuan teknologi dan alatan yang tinggi. Ini juga disertakan dengan tanggungjawab yang tinggi yang berkaitan dengan operasi pengeluaran yang tidak terganggu. Walau bagaimanapun, kami mula melupakan apa itu DevOps. Pada mulanya, ia bukan mana-mana orang atau jabatan tertentu. Jika kita mencari definisi istilah ini, kita akan mendapati banyak kata nama yang indah dan betul, seperti metodologi, amalan, falsafah budaya, kumpulan konsep, dan sebagainya.
Pengkhususan saya ialah jurutera automasi ujian (jurutera automasi QA), tetapi saya percaya bahawa ia tidak seharusnya dikaitkan hanya dengan menulis ujian auto atau membangunkan seni bina rangka kerja ujian. Pada tahun 2020, pengetahuan tentang infrastruktur automasi juga penting. Ini membolehkan anda mengatur sendiri proses automasi, daripada menjalankan ujian kepada memberikan keputusan kepada semua pihak berkepentingan selaras dengan matlamat anda. Akibatnya, kemahiran DevOps adalah satu kemestian untuk menyelesaikan kerja. Dan semua ini bagus, tetapi, malangnya, ada masalah (spoiler: artikel ini cuba untuk memudahkan masalah ini). Intinya ialah DevOps sukar. Dan ini jelas, kerana syarikat tidak akan membayar banyak untuk sesuatu yang mudah dilakukan... Dalam dunia DevOps, terdapat sejumlah besar alat, terma dan amalan yang perlu dikuasai. Ini amat sukar pada permulaan kerjaya dan bergantung pada pengalaman teknikal terkumpul.
Sumber:
Di sini kita mungkin akan selesai dengan bahagian pengenalan dan memberi tumpuan kepada tujuan artikel ini.
Artikel ini tentang apa?
Dalam artikel ini, saya akan berkongsi pengalaman saya membina infrastruktur automasi ujian. Terdapat banyak sumber maklumat di Internet tentang pelbagai alat dan cara menggunakannya, tetapi saya ingin melihatnya semata-mata dalam konteks automasi. Saya percaya bahawa ramai jurutera automasi sudah biasa dengan situasi apabila tiada sesiapa kecuali anda menjalankan ujian yang dibangunkan atau mengambil berat tentang mengekalkannya. Akibatnya, ujian menjadi ketinggalan zaman dan anda perlu meluangkan masa untuk mengemas kininya. Sekali lagi, pada permulaan kerjaya, ini boleh menjadi tugas yang agak sukar: dengan bijak memutuskan alat yang akan membantu menghapuskan masalah tertentu, cara memilih, mengkonfigurasi dan mengekalkannya. Sesetengah penguji berpaling kepada DevOps (manusia) untuk mendapatkan bantuan dan, sejujurnya, pendekatan ini berkesan. Dalam kebanyakan kes, ini mungkin satu-satunya pilihan kerana kami tidak mempunyai keterlihatan ke dalam semua kebergantungan. Tetapi seperti yang kita ketahui, DevOps adalah lelaki yang sangat sibuk, kerana mereka perlu memikirkan tentang keseluruhan infrastruktur syarikat, penempatan, pemantauan, perkhidmatan mikro dan tugas lain yang serupa bergantung pada organisasi/pasukan. Seperti biasa, automasi bukanlah keutamaan. Dalam kes sedemikian, kita mesti cuba melakukan segala yang mungkin di pihak kita dari awal hingga akhir. Ini akan mengurangkan kebergantungan, mempercepatkan aliran kerja, meningkatkan kemahiran kami dan membolehkan kami melihat gambaran yang lebih besar tentang apa yang berlaku.
Artikel ini membentangkan alatan yang paling popular dan popular serta menunjukkan cara menggunakannya untuk membina infrastruktur automasi langkah demi langkah. Setiap kumpulan diwakili oleh alatan yang telah diuji melalui pengalaman peribadi. Tetapi itu tidak bermakna anda perlu menggunakan perkara yang sama. Alat itu sendiri tidak penting, mereka muncul dan menjadi usang. Tugas kejuruteraan kami adalah untuk memahami prinsip asas: mengapa kami memerlukan kumpulan alat ini dan masalah kerja yang boleh kami selesaikan dengan bantuan mereka. Itulah sebabnya pada penghujung setiap bahagian saya meninggalkan pautan ke alat serupa yang mungkin digunakan dalam organisasi anda.
Apa yang tiada dalam artikel ini
Saya ulangi sekali lagi bahawa artikel itu bukan mengenai alat khusus, jadi tidak akan ada sisipan kod daripada dokumentasi dan penerangan arahan tertentu. Tetapi pada akhir setiap bahagian saya meninggalkan pautan untuk kajian terperinci.
Ini dilakukan kerana:
- bahan ini sangat mudah dicari dalam pelbagai sumber (dokumentasi, buku, kursus video);
- jika kita mula pergi lebih dalam, kita perlu menulis 10, 20, 30 bahagian artikel ini (sementara rancangannya adalah 2-3);
- Saya hanya tidak mahu membuang masa anda kerana anda mungkin mahu menggunakan alat lain untuk mencapai matlamat yang sama.
Amalan
Saya sangat ingin bahan ini berguna kepada setiap pembaca, dan bukan hanya dibaca dan dilupakan. Dalam mana-mana kajian, amalan adalah komponen yang sangat penting. Untuk ini saya sediakan. Terdapat juga kerja rumah menunggu anda untuk memastikan bahawa anda tidak menyalin baris arahan yang anda laksanakan secara tidak sengaja.
Plane
Langkah
Teknologi
Alatan
1
Larian tempatan (sediakan ujian demo web / android dan jalankannya secara tempatan)
Node.js, Selenium, Appium
2
Sistem kawalan versi
Git
3
Kontena
Docker, Grid Selenium, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Platform awan
Platform Awan Google
6
Orkestra
Kubernetes
7
Infrastruktur sebagai kod (IaC)
Terraform, Ansible
Struktur setiap bahagian
Untuk memastikan naratif jelas, setiap bahagian diterangkan mengikut garis besar berikut:
- penerangan ringkas tentang teknologi,
- nilai untuk infrastruktur automasi,
- ilustrasi keadaan semasa infrastruktur,
- pautan untuk belajar,
- alatan yang serupa.
1. Jalankan ujian secara tempatan
Penerangan ringkas tentang teknologi
Ini hanyalah langkah persediaan untuk menjalankan ujian demo secara tempatan dan mengesahkan bahawa ujian tersebut lulus. Dalam bahagian praktikal, Node.js digunakan, tetapi bahasa pengaturcaraan dan platform juga tidak penting dan anda boleh menggunakan yang digunakan dalam syarikat anda.
Walau bagaimanapun, sebagai alat automasi, saya mengesyorkan menggunakan Selenium WebDriver untuk platform web dan Appium untuk platform Android, masing-masing, kerana dalam langkah seterusnya kami akan menggunakan imej Docker yang disesuaikan untuk berfungsi secara khusus dengan alatan ini. Lebih-lebih lagi, merujuk kepada keperluan pekerjaan, alat ini adalah yang paling mendapat permintaan di pasaran.
Seperti yang anda mungkin perasan, kami hanya mempertimbangkan ujian web dan Android. Malangnya, iOS adalah cerita yang sama sekali berbeza (terima kasih Apple). Saya merancang untuk mempamerkan penyelesaian dan amalan berkaitan IOS di bahagian yang akan datang.
Nilai untuk infrastruktur automasi
Dari perspektif infrastruktur, berjalan secara tempatan tidak memberikan sebarang nilai. Anda hanya menyemak sama ada ujian dijalankan pada mesin tempatan dalam penyemak imbas dan simulator tempatan. Tetapi dalam apa jua keadaan, ini adalah titik permulaan yang perlu.
Ilustrasi keadaan infrastruktur semasa
Pautan untuk meneroka
Alat yang serupa
- mana-mana bahasa pengaturcaraan yang anda suka bersama dengan ujian Selenium/Appium;
- sebarang ujian;
- mana-mana pelari ujian.
2. Sistem kawalan versi (Git)
Penerangan ringkas tentang teknologi
Ia tidak akan menjadi pendedahan yang besar kepada sesiapa sahaja jika saya mengatakan bahawa kawalan versi adalah bahagian pembangunan yang sangat penting, dalam satu pasukan dan secara individu. Berdasarkan pelbagai sumber, adalah selamat untuk mengatakan bahawa Git adalah wakil yang paling popular. Sistem kawalan versi menyediakan banyak faedah, seperti perkongsian kod, menyimpan versi, memulihkan ke cawangan sebelumnya, memantau sejarah projek dan sandaran. Kami tidak akan membincangkan setiap perkara secara terperinci, kerana saya pasti anda sudah biasa dengannya dan menggunakannya dalam kerja harian anda. Tetapi jika tiba-tiba tidak, maka saya mengesyorkan berhenti membaca artikel ini dan mengisi jurang ini secepat mungkin.
Nilai untuk infrastruktur automasi
Dan di sini anda boleh bertanya soalan yang munasabah: "Mengapa dia memberitahu kami tentang Git? Semua orang tahu ini dan menggunakannya untuk kod pembangunan dan untuk kod ujian automatik." Anda betul-betul betul, tetapi dalam artikel ini kita bercakap tentang infrastruktur dan bahagian ini bertindak sebagai pratonton untuk bahagian 7: "Infrastruktur sebagai Kod (IaC)". Bagi kami, ini bermakna keseluruhan infrastruktur, termasuk ujian, diterangkan dalam bentuk kod, jadi kami juga boleh menggunakan sistem versi padanya dan mendapat faedah yang sama seperti untuk pembangunan dan kod automasi.
Kami akan melihat IaC dengan lebih terperinci dalam Langkah 7, tetapi sekarang anda boleh mula menggunakan Git secara tempatan dengan mencipta repositori tempatan. Gambaran besar akan diperluaskan apabila kami menambah repositori jauh ke infrastruktur.
Ilustrasi keadaan infrastruktur semasa
Pautan untuk meneroka
Alat yang serupa
3. Kontena (Docker)
Penerangan ringkas tentang teknologi
Untuk menunjukkan cara kontena telah mengubah peraturan permainan, mari kita kembali ke masa lalu beberapa dekad. Pada masa itu, orang ramai membeli dan menggunakan mesin pelayan untuk menjalankan aplikasi. Tetapi dalam kebanyakan kes, sumber permulaan yang diperlukan tidak diketahui terlebih dahulu. Akibatnya, syarikat membelanjakan wang untuk pembelian pelayan yang mahal dan berkuasa, tetapi sebahagian daripada kapasiti ini tidak digunakan sepenuhnya.
Peringkat seterusnya evolusi ialah mesin maya (VM), yang menyelesaikan masalah pembaziran wang untuk sumber yang tidak digunakan. Teknologi ini memungkinkan untuk menjalankan aplikasi secara bebas antara satu sama lain dalam pelayan yang sama, memperuntukkan ruang terpencil sepenuhnya. Tetapi, malangnya, mana-mana teknologi mempunyai kelemahannya. Menjalankan VM memerlukan sistem pengendalian penuh, yang menggunakan CPU, RAM, storan dan, bergantung pada OS, kos lesen perlu diambil kira. Faktor ini mempengaruhi kelajuan pemuatan dan menyukarkan mudah alih.
Dan sekarang kita datang ke kontena. Sekali lagi, teknologi ini menyelesaikan masalah sebelumnya, kerana bekas tidak menggunakan OS penuh, yang membebaskan sejumlah besar sumber dan menyediakan penyelesaian yang cepat dan fleksibel untuk mudah alih.
Sudah tentu, teknologi kontena bukanlah sesuatu yang baharu dan mula diperkenalkan pada lewat 70-an. Pada zaman itu, banyak penyelidikan, perkembangan, dan percubaan telah dijalankan. Tetapi Docker yang menyesuaikan teknologi ini dan menjadikannya mudah diakses oleh orang ramai. Pada masa kini, apabila kita bercakap tentang kontena, dalam kebanyakan kes yang kita maksudkan Docker. Apabila kita bercakap tentang bekas Docker, kami maksudkan bekas Linux. Kami boleh menggunakan sistem Windows dan macOS untuk menjalankan bekas, tetapi adalah penting untuk memahami bahawa dalam kes ini lapisan tambahan muncul. Contohnya, Docker pada Mac menjalankan kontena secara senyap di dalam VM Linux yang ringan. Kami akan kembali kepada topik ini apabila kita membincangkan menjalankan emulator Android di dalam bekas, jadi di sini terdapat nuansa yang sangat penting yang perlu dibincangkan dengan lebih terperinci.
Nilai untuk infrastruktur automasi
Kami mendapati bahawa kontena dan Docker adalah hebat. Mari kita lihat ini dalam konteks automasi, kerana setiap alat atau teknologi perlu menyelesaikan masalah. Mari kita gariskan masalah yang jelas bagi automasi ujian dalam konteks ujian UI:
- sejumlah besar kebergantungan apabila memasang Selenium dan terutamanya Appium;
- masalah keserasian antara versi penyemak imbas, simulator dan pemacu;
- kekurangan ruang terpencil untuk penyemak imbas/simulator, yang amat kritikal untuk larian selari;
- sukar untuk diurus dan diselenggara jika anda perlu menjalankan 10, 50, 100 atau bahkan 1000 pelayar pada masa yang sama.
Tetapi memandangkan Selenium ialah alat automasi yang paling popular dan Docker ialah alat kontena yang paling popular, tidaklah mengejutkan bahawa seseorang telah cuba menggabungkannya untuk mencipta alat yang berkuasa untuk menyelesaikan masalah yang dinyatakan di atas. Mari kita pertimbangkan penyelesaian sedemikian dengan lebih terperinci.
Grid selenium dalam docker
Alat ini adalah yang paling popular di dunia Selenium untuk menjalankan berbilang pelayar pada berbilang mesin dan mengurusnya dari hab pusat. Untuk bermula, anda perlu mendaftar sekurang-kurangnya 2 bahagian: Hub dan Nod. Hub ialah nod pusat yang menerima semua permintaan daripada ujian dan mengedarkannya kepada Nod yang sesuai. Untuk setiap Nod kita boleh mengkonfigurasi konfigurasi tertentu, contohnya, dengan menentukan pelayar yang dikehendaki dan versinya. Walau bagaimanapun, kami masih perlu menjaga sendiri pemacu penyemak imbas yang serasi dan memasangnya pada Nod yang dikehendaki. Atas sebab ini, grid Selenium tidak digunakan dalam bentuk tulennya, kecuali apabila kita perlu bekerja dengan penyemak imbas yang tidak boleh dipasang pada OS Linux. Untuk semua kes lain, penyelesaian yang sangat fleksibel dan betul ialah menggunakan imej Docker untuk menjalankan Hab dan Nod grid Selenium. Pendekatan ini sangat memudahkan pengurusan nod, kerana kami boleh memilih imej yang kami perlukan dengan versi penyemak imbas dan pemacu yang serasi yang telah dipasang.
Walaupun ulasan negatif tentang kestabilan, terutamanya apabila menjalankan sejumlah besar Nod secara selari, grid Selenium masih merupakan alat yang paling popular untuk menjalankan ujian Selenium secara selari. Adalah penting untuk ambil perhatian bahawa pelbagai penambahbaikan dan pengubahsuaian alat ini sentiasa muncul dalam sumber terbuka, yang memerangi pelbagai kesesakan.
Selenoid untuk Web
Alat ini merupakan satu kejayaan dalam dunia Selenium kerana ia berfungsi secara luar biasa dan telah menjadikan kehidupan ramai jurutera automasi lebih mudah. Pertama sekali, ini bukan satu lagi pengubahsuaian grid Selenium. Sebaliknya, pembangun mencipta versi baru Selenium Hub di Golang, yang digabungkan dengan imej Docker ringan untuk pelbagai pelayar, memberi dorongan kepada pembangunan automasi ujian. Selain itu, dalam kes Selenium Grid, kita mesti menentukan semua penyemak imbas yang diperlukan dan versinya terlebih dahulu, yang tidak menjadi masalah apabila bekerja dengan hanya satu penyemak imbas. Tetapi apabila ia datang kepada berbilang pelayar yang disokong, Selenoid adalah penyelesaian nombor satu terima kasih kepada ciri 'pelayar atas permintaan'nya. Apa yang diperlukan daripada kami ialah memuat turun imej yang diperlukan dengan penyemak imbas terlebih dahulu dan mengemas kini fail konfigurasi yang Selenoid berinteraksi. Selepas Selenoid menerima permintaan daripada ujian, ia akan melancarkan bekas yang dikehendaki secara automatik dengan penyemak imbas yang dikehendaki. Apabila ujian selesai, Selenoid akan menghentikan bekas itu, dengan itu membebaskan sumber untuk permintaan masa hadapan. Pendekatan ini menghapuskan sepenuhnya masalah 'degradasi nod' yang terkenal yang sering kita hadapi dalam grid Selenium.
Tetapi, sayangnya, Selenoid masih bukan peluru perak. Kami mendapat ciri 'pelayar atas permintaan', tetapi ciri 'sumber atas permintaan' masih tidak tersedia. Untuk menggunakan Selenoid, kita mesti menggunakannya pada perkakasan fizikal atau pada VM, yang bermaksud kita mesti mengetahui terlebih dahulu berapa banyak sumber yang perlu diperuntukkan. Saya rasa ini bukan masalah untuk projek kecil yang menjalankan 10, 20 atau 30 pelayar selari. Tetapi bagaimana jika kita memerlukan 100, 500, 1000 dan lebih? Tidak masuk akal untuk mengekalkan dan membayar begitu banyak sumber sepanjang masa. Dalam bahagian 5 dan 6 artikel ini, kami akan membincangkan penyelesaian yang membolehkan anda membuat skala, dengan itu mengurangkan kos syarikat dengan ketara.
Selenoid untuk Android
Selepas kejayaan Selenoid sebagai alat automasi web, orang ramai mahukan sesuatu yang serupa untuk Android. Dan ia berlaku - Selenoid dikeluarkan dengan sokongan Android. Dari sudut pandangan pengguna peringkat tinggi, prinsip operasi adalah serupa dengan automasi web. Satu-satunya perbezaan ialah bukannya bekas penyemak imbas, Selenoid menjalankan bekas emulator Android. Pada pendapat saya, ini adalah alat percuma yang paling berkuasa pada masa ini untuk menjalankan ujian Android secara selari.
Saya benar-benar tidak mahu bercakap tentang aspek negatif alat ini, kerana saya sangat menyukainya. Namun begitu, terdapat kelemahan yang sama yang digunakan pada automasi web dan dikaitkan dengan penskalaan. Di samping itu, kita perlu bercakap tentang satu lagi had yang mungkin mengejutkan jika kita menyediakan alat untuk kali pertama. Untuk menjalankan imej Android, kami memerlukan mesin fizikal atau VM dengan sokongan virtualisasi bersarang. Dalam panduan cara, saya menunjukkan cara mendayakan ini pada VM Linux. Walau bagaimanapun, jika anda seorang pengguna macOS dan ingin menggunakan Selenoid secara tempatan, maka ini tidak akan dapat menjalankan ujian Android. Tetapi anda sentiasa boleh menjalankan Linux VM secara tempatan dengan 'pemayaran bersarang' dikonfigurasikan dan menggunakan Selenoid di dalamnya.
Ilustrasi keadaan infrastruktur semasa
Dalam konteks artikel ini, kami akan menambah 2 alat untuk menggambarkan infrastruktur. Ini ialah grid Selenium untuk ujian web dan ujian Selenoid untuk Android. Dalam tutorial GitHub, saya juga akan menunjukkan kepada anda cara menggunakan Selenoid untuk menjalankan ujian web.
Pautan untuk meneroka
Alat yang serupa
- Terdapat alat kontena lain, tetapi Docker adalah yang paling popular. Jika anda ingin mencuba sesuatu yang lain, perlu diingat bahawa alatan yang telah kami bincangkan untuk menjalankan ujian Selenium secara selari tidak akan berfungsi di luar kotak.
- Seperti yang telah dikatakan, terdapat banyak pengubahsuaian grid Selenium, sebagai contoh,.
4.CI/CD
Penerangan ringkas tentang teknologi
Amalan penyepaduan berterusan agak popular dalam pembangunan dan setanding dengan sistem kawalan versi. Walaupun begitu, saya merasakan terdapat kekeliruan dalam istilah. Dalam perenggan ini saya ingin menerangkan 3 pengubahsuaian teknologi ini dari sudut pandangan saya. Di internet anda akan menemui banyak artikel dengan tafsiran yang berbeza, dan adalah perkara biasa jika pendapat anda berbeza. Perkara yang paling penting ialah anda berada di halaman yang sama dengan rakan sekerja anda.
Jadi, ada 3 istilah: CI - Continuous Integration, CD - Continuous Delivery dan sekali lagi CD - Continuous Deployment. (Di bawah saya akan menggunakan istilah ini dalam bahasa Inggeris). Setiap pengubahsuaian menambah beberapa langkah tambahan pada saluran pembangunan anda. Tetapi perkataan berterusan (berterusan) adalah perkara yang paling penting. Dalam konteks ini, kami maksudkan sesuatu yang berlaku dari awal hingga akhir, tanpa gangguan atau campur tangan manual. Mari kita lihat CI & CD dan CD dalam konteks ini.
- Integrasi berterusan ini adalah langkah awal evolusi. Selepas menyerahkan kod baharu kepada pelayan, kami mengharapkan untuk menerima maklum balas pantas bahawa perubahan kami adalah ok. Biasanya, CI termasuk menjalankan alat analisis kod statik dan ujian API unit/dalaman. Ini membolehkan kami mendapatkan maklumat tentang kod kami dalam masa beberapa saat/minit.
- Penghantaran berterusan ialah langkah yang lebih maju di mana kami menjalankan ujian integrasi/UI. Walau bagaimanapun, pada peringkat ini kami tidak mendapat keputusan secepat dengan CI. Pertama, jenis ujian ini mengambil masa yang lebih lama untuk diselesaikan. Kedua, sebelum melancarkan, kita mesti menggunakan perubahan kita pada persekitaran ujian/pementasan. Lebih-lebih lagi, jika kita bercakap tentang pembangunan mudah alih, maka langkah tambahan muncul untuk membuat binaan aplikasi kami.
- Penggunaan Berterusan mengandaikan bahawa kami secara automatik mengeluarkan perubahan kami kepada pengeluaran jika semua ujian penerimaan telah diluluskan pada peringkat sebelumnya. Di samping itu, selepas peringkat keluaran, anda boleh mengkonfigurasi pelbagai peringkat, seperti menjalankan ujian asap pada pengeluaran dan mengumpul metrik minat. Penggunaan Berterusan hanya boleh dilakukan dengan liputan yang baik melalui ujian automatik. Jika sebarang campur tangan manual diperlukan, termasuk ujian, maka ini tidak lagi berterusan (berterusan). Kemudian kita boleh mengatakan bahawa saluran paip kita hanya mematuhi amalan Penghantaran Berterusan.
Nilai untuk infrastruktur automasi
Dalam bahagian ini, saya harus menjelaskan bahawa apabila kita bercakap tentang ujian UI hujung ke hujung, ini bermakna kita harus menggunakan perubahan dan perkhidmatan yang berkaitan untuk menguji persekitaran. Integrasi Berterusan - proses ini tidak terpakai untuk tugas ini dan kita mesti mengambil berat untuk melaksanakan sekurang-kurangnya amalan Penyampaian Berterusan. Penggunaan Berterusan juga masuk akal dalam konteks ujian UI jika kita akan menjalankannya dalam pengeluaran.
Dan sebelum kita melihat ilustrasi perubahan seni bina, saya ingin mengatakan beberapa perkataan tentang GitLab CI. Tidak seperti alat CI/CD lain, GitLab menyediakan repositori jauh dan banyak ciri tambahan lain. Oleh itu, GitLab lebih daripada CI. Ia termasuk pengurusan kod sumber, pengurusan Agile, saluran paip CI/CD, alatan pengelogan dan pengumpulan metrik di luar kotak. Seni bina GitLab terdiri daripada Gitlab CI/CD dan GitLab Runner. Berikut adalah penerangan ringkas dari laman web rasmi:
Gitlab CI/CD ialah aplikasi web dengan API yang menyimpan keadaannya dalam pangkalan data, mengurus projek/binaan dan menyediakan antara muka pengguna. GitLab Runner ialah aplikasi yang memproses binaan. Ia boleh digunakan secara berasingan dan berfungsi dengan GitLab CI/CD melalui API. Untuk ujian yang dijalankan, anda memerlukan contoh Gitlab dan Runner.
Ilustrasi keadaan infrastruktur semasa
Pautan untuk meneroka
Alat yang serupa
- Dan banyak lagi yang lain
5. Platform awan
Penerangan ringkas tentang teknologi
Dalam bahagian ini kita akan bercakap tentang trend popular yang dipanggil 'awan awam'. Walaupun manfaat besar yang diberikan oleh teknologi maya dan kontena yang diterangkan di atas, kami masih memerlukan sumber pengkomputeran. Syarikat membeli pelayan mahal atau menyewa pusat data, tetapi dalam kes ini adalah perlu untuk membuat pengiraan (kadangkala tidak realistik) berapa banyak sumber yang kita perlukan, sama ada kita akan menggunakannya 24/7 dan untuk tujuan apa. Sebagai contoh, pengeluaran memerlukan pelayan yang berjalan XNUMX/XNUMX, tetapi adakah kita memerlukan sumber yang serupa untuk ujian di luar waktu bekerja? Ia juga bergantung kepada jenis ujian yang dijalankan. Contohnya ialah ujian beban/tekanan yang kami rancang untuk jalankan semasa waktu tidak bekerja untuk mendapatkan keputusan pada hari berikutnya. Tetapi pastinya ketersediaan pelayan XNUMX/XNUMX tidak diperlukan untuk ujian automatik hujung ke hujung dan terutamanya bukan untuk persekitaran ujian manual. Untuk situasi sedemikian, adalah baik untuk mendapatkan seberapa banyak sumber yang diperlukan atas permintaan, menggunakannya dan berhenti membayar apabila ia tidak lagi diperlukan. Lebih-lebih lagi, adalah bagus untuk menerimanya serta-merta dengan membuat beberapa klik tetikus atau menjalankan beberapa skrip. Inilah kegunaan awan awam. Mari kita lihat definisi:
βAwan awam ditakrifkan sebagai perkhidmatan pengkomputeran yang ditawarkan oleh penyedia pihak ketiga melalui Internet awam, menjadikannya tersedia kepada sesiapa sahaja yang ingin menggunakan atau membelinya. Ia mungkin percuma atau dijual atas permintaan, membenarkan pelanggan membayar hanya setiap penggunaan untuk kitaran CPU, storan atau lebar jalur yang mereka gunakan."
Terdapat pendapat bahawa awan awam adalah mahal. Tetapi idea utama mereka adalah untuk mengurangkan kos syarikat. Seperti yang dinyatakan sebelum ini, awan awam membolehkan anda mendapatkan sumber atas permintaan dan membayar hanya untuk masa anda menggunakannya. Juga, kadangkala kita terlupa bahawa pekerja menerima gaji, dan pakar juga merupakan sumber yang mahal. Ia mesti diambil kira bahawa awan awam menjadikan sokongan infrastruktur lebih mudah, yang membolehkan jurutera memberi tumpuan kepada tugas yang lebih penting.
Nilai untuk infrastruktur automasi
Apakah sumber khusus yang kami perlukan untuk ujian UI hujung ke hujung? Pada asasnya ini adalah mesin atau kluster maya (kita akan bercakap tentang Kubernetes dalam bahagian seterusnya) untuk menjalankan pelayar dan emulator. Lebih banyak penyemak imbas dan emulator yang kita mahu jalankan secara serentak, lebih banyak CPU dan memori yang diperlukan dan lebih banyak wang yang perlu kita bayar untuknya. Oleh itu, awan awam dalam konteks automasi ujian membolehkan kami menjalankan sejumlah besar (100, 200, 1000...) penyemak imbas/emulator atas permintaan, mendapatkan keputusan ujian secepat mungkin dan berhenti membayar untuk intensif sumber yang gila itu. kuasa.
Pembekal awan yang paling popular ialah Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Panduan cara untuk menyediakan contoh cara menggunakan GCP, tetapi secara amnya ia tidak kira apa yang anda gunakan untuk tugasan automasi. Kesemuanya menyediakan fungsi yang hampir sama. Biasanya, untuk memilih pembekal, pengurusan memfokuskan pada keseluruhan infrastruktur dan keperluan perniagaan syarikat, yang berada di luar skop artikel ini. Bagi jurutera automasi, adalah lebih menarik untuk membandingkan penggunaan penyedia awan dengan penggunaan platform awan khusus untuk tujuan ujian, seperti Sos Labs, BrowserStack, BitBar dan sebagainya. Jadi mari kita lakukannya juga! Pada pendapat saya, Sauce Labs ialah ladang ujian awan yang paling terkenal, itulah sebabnya saya menggunakannya sebagai perbandingan.
GCP vs Sos Labs untuk tujuan automasi:
Bayangkan kita perlu menjalankan 8 ujian web dan 8 ujian Android secara serentak. Untuk ini, kami akan menggunakan GCP dan menjalankan 2 mesin maya dengan Selenoid. Pada yang pertama kami akan menaikkan 8 bekas dengan pelayar. Pada yang kedua terdapat 8 bekas dengan emulator. Jom tengok harga:
Untuk menjalankan satu bekas dengan Chrome, kita perlukan n1-standard-1 kereta. Dalam kes Android ia akan menjadi n1-standard-4 untuk satu emulator. Sebenarnya, cara yang lebih fleksibel dan lebih murah ialah menetapkan nilai pengguna tertentu untuk CPU/Memori, tetapi pada masa ini ini tidak penting untuk dibandingkan dengan Sos Labs.
Dan berikut ialah tarif untuk menggunakan Sauce Labs:
Saya percaya anda telah melihat perbezaannya, tetapi saya masih akan menyediakan jadual dengan pengiraan untuk tugas kami:
Sumber yang diperlukan
Bulanan
Waktu bekerja(8 pagi - 8 malam)
Waktu bekerja+ Boleh didahulukan
GCP untuk Web
n1-standard-1 x 8 = n1-standard-8
$194.18
23 hari * 12j * 0.38 = $104.88
23 hari * 12j * 0.08 = $22.08
Makmal Sos untuk Web
Ujian selari Cloud8 Maya
$1.559
-
-
GCP untuk Android
n1-standard-4 x 8: n1-standard-16
$776.72
23 hari * 12j * 1.52 = $419.52
23 hari * 12j * 0.32 = $88.32
Sos Labs untuk Android
Ujian selari Awan Peranti Sebenar 8
$1.999
-
-
Seperti yang anda lihat, perbezaan kos adalah besar, terutamanya jika anda menjalankan ujian hanya dalam tempoh dua belas jam bekerja. Tetapi anda boleh mengurangkan kos lebih jauh jika anda menggunakan mesin yang boleh didahulukan. Apa itu?
VM boleh didahulukan ialah tika yang anda boleh buat dan jalankan pada harga yang jauh lebih tinggi daripada kejadian biasa. Walau bagaimanapun, Compute Engine mungkin menamatkan (mendahului) kejadian ini jika memerlukan akses kepada sumber tersebut untuk tugasan lain. Contoh yang boleh didahulukan ialah kapasiti Enjin Kira yang berlebihan, jadi ketersediaannya berbeza mengikut penggunaan.
Jika apl anda bertolak ansur dengan kesalahan dan boleh menahan kemungkinan preempttion, maka contoh preemptible boleh mengurangkan kos Enjin Kira anda dengan ketara. Contohnya, kerja pemprosesan kelompok boleh dijalankan pada kejadian yang boleh didahulukan. Jika sesetengah keadaan tersebut ditamatkan semasa pemprosesan, kerja menjadi perlahan tetapi tidak berhenti sepenuhnya. Kejadian boleh didahulukan menyelesaikan tugas pemprosesan kelompok anda tanpa meletakkan beban kerja tambahan pada kejadian sedia ada anda dan tanpa memerlukan anda membayar harga penuh untuk kejadian biasa tambahan.
Dan ia masih belum berakhir! Pada hakikatnya, saya pasti tiada siapa yang menjalankan ujian selama 12 jam tanpa rehat. Dan jika ya, maka anda boleh memulakan dan menghentikan mesin maya secara automatik apabila ia tidak diperlukan. Masa penggunaan sebenar boleh dikurangkan kepada 6 jam sehari. Kemudian pembayaran dalam konteks tugas kami akan berkurangan kepada $11 sebulan untuk 8 pelayar. Bukankah ini indah? Tetapi dengan mesin yang boleh didahulukan kita mesti berhati-hati dan bersedia untuk gangguan dan ketidakstabilan, walaupun situasi ini boleh disediakan dan dikendalikan dalam perisian. Ia berbaloi!
Tetapi sama sekali saya tidak mengatakan 'jangan sekali-kali menggunakan ladang ujian awan'. Mereka mempunyai beberapa kelebihan. Pertama sekali, ini bukan hanya mesin maya, tetapi penyelesaian automasi ujian sepenuhnya dengan satu set fungsi di luar kotak: akses jauh, log, tangkapan skrin, rakaman video, pelbagai penyemak imbas dan peranti mudah alih fizikal. Dalam banyak situasi, ini boleh menjadi alternatif bergaya yang penting. Platform ujian amat berguna untuk automasi IOS, apabila awan awam hanya boleh menawarkan sistem Linux/Windows. Tetapi kita akan bercakap tentang iOS dalam artikel berikut. Saya cadangkan sentiasa melihat situasi dan bermula dari tugasan: dalam beberapa kes ia adalah lebih murah dan lebih cekap untuk menggunakan awan awam, dan pada yang lain platform ujian pasti bernilai wang yang dibelanjakan.
Ilustrasi keadaan infrastruktur semasa
Pautan untuk meneroka
Alat yang serupa:
6. Orkestrasi
Penerangan ringkas tentang teknologi
Saya ada berita baik β kita hampir di penghujung artikel! Pada masa ini, infrastruktur automasi kami terdiri daripada ujian web dan Android, yang kami jalankan melalui GitLab CI secara selari, menggunakan alat berdaya Docker: Selenium grid dan Selenoid. Selain itu, kami menggunakan mesin maya yang dibuat melalui GCP untuk mengehoskan bekas dengan penyemak imbas dan emulator. Untuk mengurangkan kos, kami memulakan mesin maya ini hanya atas permintaan dan menghentikannya apabila ujian tidak dijalankan. Adakah terdapat perkara lain yang boleh menambah baik infrastruktur kami? Jawapannya ya! Temui Kubernetes (K8s)!
Mula-mula, mari kita lihat bagaimana perkataan orkestrasi, kelompok dan Kubernetes berkaitan antara satu sama lain. Pada tahap yang tinggi, orkestrasi ialah sistem yang menggunakan dan mengurus aplikasi. Untuk automasi ujian, aplikasi kontena tersebut ialah Selenium grid dan Selenoid. Docker dan K8 saling melengkapi. Yang pertama digunakan untuk penggunaan aplikasi, yang kedua untuk orkestrasi. Sebaliknya, K8s ialah kluster. Tugas kluster ialah menggunakan VM sebagai Nod, yang membolehkan anda memasang pelbagai fungsi, program dan perkhidmatan dalam satu pelayan (kluster). Jika mana-mana Nod gagal, Nod lain akan mengambil, yang memastikan operasi aplikasi kami tidak terganggu. Di samping itu, K8 mempunyai fungsi penting yang berkaitan dengan penskalaan, yang mana kami memperoleh jumlah sumber optimum secara automatik berdasarkan beban dan had yang ditetapkan.
Sebenarnya, menggunakan Kubernetes secara manual dari awal bukanlah tugas yang remeh sama sekali. Saya akan meninggalkan pautan ke panduan cara yang terkenal "Kubernetes The Hard Way" dan jika anda berminat, anda boleh mengamalkannya. Tetapi, mujurlah, terdapat kaedah dan alat alternatif. Cara paling mudah ialah menggunakan Enjin Google Kubernetes (GKE) dalam GCP, yang akan membolehkan anda mendapatkan kluster sedia dibuat dalam beberapa klik. Saya mengesyorkan menggunakan pendekatan ini untuk mula belajar, kerana ia akan membolehkan anda menumpukan pada mempelajari cara menggunakan K8 untuk tugasan anda dan bukannya mempelajari cara komponen dalaman harus disepadukan antara satu sama lain.
Nilai untuk infrastruktur automasi
Mari kita lihat beberapa ciri penting yang disediakan oleh K8s:
- penggunaan aplikasi: menggunakan kluster berbilang nod dan bukannya VM;
- penskalaan dinamik: mengurangkan kos sumber yang digunakan hanya atas permintaan;
- penyembuhan diri: pemulihan automatik pod (akibatnya bekas juga dipulihkan);
- pelancaran kemas kini dan pemulangan semula perubahan tanpa masa henti: mengemas kini alatan, penyemak imbas dan emulator tidak mengganggu kerja pengguna semasa
Tetapi K8 masih bukan peluru perak. Untuk memahami semua kelebihan dan batasan dalam konteks alat yang sedang kami pertimbangkan (Selenium grid, Selenoid), kami akan membincangkan secara ringkas struktur K8s. Kluster mengandungi dua jenis Nod: Nod Induk dan Nod Pekerja. Nod Induk bertanggungjawab untuk pengurusan, penempatan dan keputusan penjadualan. Nod pekerja ialah tempat aplikasi dijalankan. Nod juga mengandungi persekitaran masa jalan kontena. Dalam kes kami, ini ialah Docker, yang bertanggungjawab untuk operasi berkaitan kontena. Tetapi terdapat juga penyelesaian alternatif, sebagai contoh. Adalah penting untuk memahami bahawa penskalaan atau penyembuhan diri tidak terpakai secara langsung pada bekas. Ini dilaksanakan dengan menambah/mengurangkan bilangan pod, yang seterusnya mengandungi bekas (biasanya satu bekas bagi setiap pod, tetapi bergantung pada tugas mungkin terdapat lebih banyak). Hierarki peringkat tinggi terdiri daripada nod pekerja, di dalamnya terdapat pod, di dalamnya bekas dinaikkan.
Ciri penskalaan adalah kunci dan boleh digunakan pada kedua-dua nod dalam kumpulan nod-kluster dan pod dalam nod. Terdapat 2 jenis penskalaan yang digunakan pada kedua-dua nod dan pod. Jenis pertama ialah mendatar - penskalaan berlaku dengan menambah bilangan nod/pod. Jenis ini lebih disukai. Jenis kedua adalah, dengan itu, menegak. Penskalaan dilakukan dengan meningkatkan saiz nod/pod, dan bukan bilangannya.
Sekarang mari kita lihat alat kami dalam konteks istilah di atas.
Grid selenium
Seperti yang dinyatakan sebelum ini, grid Selenium adalah alat yang sangat popular, dan tidak menghairankan bahawa ia telah disimpan dalam bekas. Oleh itu, tidak mengejutkan bahawa grid Selenium boleh digunakan dalam K8s. Contoh cara melakukan ini boleh didapati dalam repositori rasmi K8s. Seperti biasa, saya melampirkan pautan di hujung bahagian. Di samping itu, panduan cara untuk menunjukkan cara melakukan ini dalam Terraform. Terdapat juga arahan tentang cara menskalakan bilangan pod yang mengandungi bekas penyemak imbas. Tetapi fungsi penskalaan automatik dalam konteks K8 masih bukan tugas yang jelas. Semasa saya mula belajar, saya tidak menemui sebarang panduan atau cadangan praktikal. Selepas beberapa kajian dan percubaan dengan sokongan pasukan DevOps, kami memilih pendekatan menaikkan bekas dengan penyemak imbas yang diperlukan di dalam satu pod, yang terletak di dalam satu nod pekerja. Kaedah ini membolehkan kami menggunakan strategi penskalaan mendatar nod dengan menambah bilangannya. Saya berharap ini akan berubah pada masa hadapan dan kita akan melihat lebih banyak penerangan tentang pendekatan yang lebih baik dan penyelesaian sedia, terutamanya selepas keluaran Selenium grid 4 dengan seni bina dalaman yang diubah.
Selenoid:
Penggunaan Selenoid dalam K8 pada masa ini merupakan kekecewaan terbesar. Mereka tidak serasi. Secara teorinya, kita boleh menaikkan bekas Selenoid di dalam pod, tetapi apabila Selenoid mula melancarkan bekas dengan penyemak imbas, mereka akan tetap berada di dalam pod yang sama. Ini menjadikan penskalaan mustahil dan, akibatnya, kerja Selenoid di dalam gugusan tidak akan berbeza daripada kerja di dalam mesin maya. Tamat cerita.
Bulan:
Mengetahui kesesakan ini apabila bekerja dengan Selenoid, pembangun mengeluarkan alat yang lebih berkuasa dipanggil Moon. Alat ini pada asalnya direka bentuk untuk berfungsi dengan Kubernetes dan, sebagai hasilnya, ciri penskalaan automatik boleh dan harus digunakan. Lebih-lebih lagi, saya akan mengatakan bahawa pada masa ini ia adalah tunggal alat dalam dunia Selenium, yang mempunyai sokongan kluster K8 asli di luar kotak (tidak lagi tersedia, lihat alat seterusnya ). Ciri utama Moon yang menyediakan sokongan ini ialah:
Tanpa kerakyatan sepenuhnya. Selenoid menyimpan maklumat memori tentang sesi penyemak imbas yang sedang dijalankan. Jika atas sebab tertentu prosesnya ranap β maka semua sesi berjalan hilang. Bulan sebaliknya tidak mempunyai keadaan dalaman dan boleh direplikasi merentas pusat data. Sesi penyemak imbas kekal hidup walaupun satu atau lebih replika terputus.
Jadi, Moon ialah penyelesaian yang hebat, tetapi ada satu masalah: ia bukan percuma. Harga bergantung pada bilangan sesi. Anda hanya boleh menjalankan 0-4 sesi secara percuma, yang tidak begitu berguna. Tetapi, bermula dari sesi kelima, anda perlu membayar $5 untuk setiap satu. Keadaan mungkin berbeza dari syarikat ke syarikat, tetapi dalam kes kami, menggunakan Moon adalah sia-sia. Seperti yang saya terangkan di atas, kita boleh menjalankan VM dengan Selenium Grid atas permintaan atau meningkatkan bilangan Nod dalam kelompok. Untuk lebih kurang satu saluran paip, kami melancarkan 500 penyemak imbas dan menghentikan semua sumber selepas ujian selesai. Jika kami menggunakan Moon, kami perlu membayar tambahan 500 x 5 = $2500 sebulan, tidak kira berapa kerap kami menjalankan ujian. Sekali lagi, saya tidak mengatakan jangan gunakan Moon. Untuk tugasan anda, ini boleh menjadi penyelesaian yang sangat diperlukan, contohnya, jika anda mempunyai banyak projek/pasukan dalam organisasi anda dan anda memerlukan kluster biasa yang besar untuk semua orang. Seperti biasa, saya meninggalkan pautan di penghujung dan mengesyorkan melakukan semua pengiraan yang diperlukan dalam konteks tugas anda.
Callisto: (Perhatian! Ini tiada dalam artikel asal dan hanya terkandung dalam terjemahan Rusia)
Seperti yang saya katakan, Selenium adalah alat yang sangat popular, dan bidang IT berkembang dengan sangat cepat. Semasa saya sedang mengerjakan terjemahan, alat baru yang menjanjikan yang dipanggil Callisto muncul di web (hello Cypress dan pembunuh Selenium yang lain). Ia berfungsi secara asli dengan K8 dan membolehkan anda menjalankan bekas Selenoid dalam pod, diedarkan di seluruh Nod. Semuanya berfungsi di luar kotak, termasuk autoscaling. Hebat, tetapi perlu diuji. Saya telah berjaya menggunakan alat ini dan menjalankan beberapa percubaan. Tetapi masih terlalu awal untuk membuat kesimpulan, selepas menerima keputusan dalam jarak yang jauh, mungkin saya akan membuat semakan dalam artikel akan datang. Buat masa ini saya hanya meninggalkan pautan untuk penyelidikan bebas.
Ilustrasi keadaan infrastruktur semasa
Pautan untuk meneroka
Alat yang serupa
7. Infrastruktur sebagai Kod (IaC)
Penerangan ringkas tentang teknologi
Dan sekarang kita sampai ke bahagian terakhir. Biasanya, teknologi ini dan tugas yang berkaitan bukan tanggungjawab jurutera automasi. Dan ada sebab untuk ini. Pertama, dalam kebanyakan organisasi, isu infrastruktur berada di bawah kawalan jabatan DevOps dan pasukan pembangunan tidak begitu mengambil berat tentang perkara yang membuat saluran paip berfungsi dan bagaimana semua yang berkaitan dengannya perlu disokong. Kedua, sejujurnya, amalan Infrastruktur sebagai Kod (IaC) masih tidak diterima pakai di banyak syarikat. Tetapi ia sudah pasti menjadi trend popular dan adalah penting untuk cuba terlibat dalam proses, pendekatan dan alat yang berkaitan dengannya. Atau sekurang-kurangnya kekal sehingga kini.
Mari kita mulakan dengan motivasi untuk menggunakan pendekatan ini. Kami telah membincangkan bahawa untuk menjalankan ujian dalam GitlabCI, kami memerlukan sekurang-kurangnya sumber untuk menjalankan Gitlab Runner. Dan untuk menjalankan bekas dengan penyemak imbas/emulator, kita perlu menempah VM atau kluster. Selain daripada menguji sumber, kami memerlukan sejumlah besar kapasiti untuk menyokong pembangunan, pementasan, persekitaran pengeluaran, yang juga termasuk pangkalan data, jadual automatik, konfigurasi rangkaian, pengimbang beban, hak pengguna dan sebagainya. Isu utama ialah usaha yang diperlukan untuk menyokong semuanya. Terdapat beberapa cara kita boleh membuat perubahan dan melancarkan kemas kini. Contohnya, dalam konteks GCP, kami boleh menggunakan konsol UI dalam penyemak imbas dan melakukan semua tindakan dengan mengklik butang. Alternatifnya ialah menggunakan panggilan API untuk berinteraksi dengan entiti awan, atau gunakan utiliti baris arahan gcloud untuk melaksanakan manipulasi yang diingini. Tetapi dengan sejumlah besar entiti dan elemen infrastruktur yang berbeza, ia menjadi sukar atau bahkan mustahil untuk melaksanakan semua operasi secara manual. Selain itu, semua tindakan manual ini tidak dapat dikawal. Kami tidak boleh menyerahkannya untuk semakan sebelum pelaksanaan, menggunakan sistem kawalan versi dan dengan cepat melancarkan semula perubahan yang membawa kepada insiden tersebut. Untuk menyelesaikan masalah sedemikian, jurutera mencipta dan mencipta skrip bash/shell automatik, yang tidak jauh lebih baik daripada kaedah sebelumnya, kerana ia tidak begitu mudah untuk dibaca, difahami, diselenggara dan diubah suai dengan cepat dalam gaya prosedur.
Dalam artikel ini dan panduan cara, saya menggunakan 2 alatan yang berkaitan dengan amalan IaC. Ini ialah Terraform dan Ansible. Sesetengah orang percaya bahawa tidak masuk akal untuk menggunakannya pada masa yang sama, kerana fungsinya adalah serupa dan ia boleh ditukar ganti. Tetapi hakikatnya pada mulanya mereka diberi tugas yang sama sekali berbeza. Dan hakikat bahawa alatan ini harus saling melengkapi telah disahkan pada pembentangan bersama oleh pembangun yang mewakili HashiCorp dan RedHat. Perbezaan konsep ialah Terraform ialah alat peruntukan untuk menguruskan pelayan itu sendiri. Manakala Ansible ialah alat pengurusan konfigurasi yang tugasnya adalah untuk memasang, mengkonfigurasi dan mengurus perisian pada pelayan ini.
Satu lagi ciri utama yang membezakan alat ini ialah gaya pengekodan. Tidak seperti bash dan Ansible, Terraform menggunakan gaya perisytiharan berdasarkan perihalan keadaan akhir yang diingini untuk dicapai hasil daripada pelaksanaan. Sebagai contoh, jika kita akan mencipta 10 VM dan menggunakan perubahan melalui Terraform, maka kita akan mendapat 10 VM. Jika kita menjalankan skrip sekali lagi, tiada apa yang akan berlaku kerana kita sudah mempunyai 10 VM, dan Terraform tahu tentang ini kerana ia menyimpan keadaan semasa infrastruktur dalam fail keadaan. Tetapi Ansible menggunakan pendekatan prosedur dan, jika anda memintanya untuk mencipta 10 VM, maka pada pelancaran pertama kami akan mendapat 10 VM, serupa dengan Terraform. Tetapi selepas dimulakan semula, kami sudah mempunyai 20 VM. Inilah perbezaan yang penting. Dalam gaya prosedur, kami tidak menyimpan keadaan semasa dan hanya menerangkan urutan langkah yang mesti dilakukan. Sudah tentu, kita boleh menangani pelbagai situasi, menambah beberapa pemeriksaan untuk kewujudan sumber dan keadaan semasa, tetapi tidak ada gunanya kita membuang masa dan berusaha untuk mengawal logik ini. Di samping itu, ini meningkatkan risiko membuat kesilapan.
Merumuskan semua perkara di atas, kita boleh membuat kesimpulan bahawa Terraform dan notasi deklaratif ialah alat yang lebih sesuai untuk menyediakan pelayan. Tetapi lebih baik untuk mewakilkan kerja pengurusan konfigurasi kepada Ansible. Dengan itu, mari kita lihat kes penggunaan dalam konteks automasi.
Nilai untuk infrastruktur automasi
Satu-satunya perkara penting untuk difahami di sini ialah infrastruktur automasi ujian harus dipertimbangkan sebagai sebahagian daripada keseluruhan infrastruktur syarikat. Ini bermakna semua amalan IaC mesti digunakan secara global kepada sumber keseluruhan organisasi. Siapa yang bertanggungjawab untuk ini bergantung pada proses anda. Pasukan DevOps lebih berpengalaman dalam isu ini, mereka melihat keseluruhan gambaran tentang apa yang berlaku. Walau bagaimanapun, jurutera QA lebih terlibat dalam proses automasi bangunan dan struktur saluran paip, yang membolehkan mereka melihat dengan lebih baik semua perubahan yang diperlukan dan peluang untuk penambahbaikan. Pilihan terbaik ialah bekerjasama, bertukar pengetahuan dan idea untuk mencapai hasil yang diharapkan.
Berikut ialah beberapa contoh penggunaan Terraform dan Ansible dalam konteks automasi ujian dan alatan yang kami bincangkan sebelum ini:
1. Terangkan ciri dan parameter yang diperlukan bagi VM dan kelompok menggunakan Terraform.
2. Menggunakan Ansible, pasang alat yang diperlukan untuk ujian: docker, Selenoid, Selenium Grid dan muat turun versi pelayar/emulator yang diperlukan.
3. Menggunakan Terraform, huraikan ciri-ciri VM di mana GitLab Runner akan dilancarkan.
4. Pasang GitLab Runner dan alatan disertakan yang diperlukan menggunakan Ansible, tetapkan tetapan dan konfigurasi.
Ilustrasi keadaan infrastruktur semasa
Pautan untuk meneroka:
Alat yang serupa
Mari kita ringkaskan!
Langkah
Teknologi
Alatan
Nilai untuk infrastruktur automasi
1
Larian tempatan
Node.js, Selenium, Appium
- Alat yang paling popular untuk web dan mudah alih
- Menyokong banyak bahasa dan platform (termasuk Node.js)
2
Sistem kawalan versi
Git
- Faedah yang serupa dengan kod pembangunan
3
Kontena
Docker, Grid Selenium, Selenoid (Web, Android)
- Menjalankan ujian secara selari
- Persekitaran terpencil
- Peningkatan versi yang mudah dan fleksibel
- Menghentikan sumber yang tidak digunakan secara dinamik
- Mudah disediakan
4
CI/CD
Gitlab CI
- Menguji sebahagian daripada saluran paip
- Maklum Balas Pantas
- Keterlihatan untuk keseluruhan syarikat/pasukan
5
Platform awan
Platform Awan Google
- Sumber atas permintaan (kami membayar hanya apabila diperlukan)
- Mudah diurus dan dikemas kini
- Keterlihatan dan kawalan semua sumber
6
Orkestra
Kubernetes
Dalam konteks bekas dengan penyemak imbas/emulator di dalam pod:
- Penskalaan/penskalaan automatik
- Penyembuhan diri
- Kemas kini dan rollback tanpa gangguan
7
Infrastruktur sebagai kod (IaC)
Terraform, Ansible
- Faedah yang sama dengan infrastruktur pembangunan
- Semua faedah versi kod
- Mudah untuk membuat perubahan dan mengekalkan
- Automatik sepenuhnya
Gambar rajah peta minda: evolusi infrastruktur
langkah1: Tempatan
langkah2: VCS
langkah3: Penyusunan kontena
langkah4: CI/CD
langkah5: Platform Awan
langkah6: Orkestrasi
langkah7: IaC
Apa seterusnya?
Jadi, ini adalah penghujung artikel. Tetapi sebagai kesimpulan, saya ingin mewujudkan beberapa perjanjian dengan anda.
Dari pihak anda
Seperti yang dinyatakan pada permulaan, saya ingin artikel itu berguna dan membantu anda menggunakan pengetahuan yang diperoleh dalam kerja sebenar. saya tambah lagi.
Tetapi walaupun selepas itu, jangan berhenti, berlatih, kaji pautan dan buku yang berkaitan, ketahui cara ia berfungsi dalam syarikat anda, cari tempat yang boleh diperbaiki dan ambil bahagian di dalamnya. Semoga berjaya!
Dari pihak saya
Dari tajuk anda dapat melihat bahawa ini hanya bahagian pertama. Walaupun fakta bahawa ia ternyata agak besar, topik penting masih tidak dibincangkan di sini. Dalam bahagian kedua, saya merancang untuk melihat infrastruktur automasi dalam konteks IOS. Disebabkan oleh sekatan Apple untuk menjalankan simulator iOS hanya pada sistem macOS, rangkaian penyelesaian kami dikecilkan. Sebagai contoh, kami tidak dapat menggunakan Docker untuk menjalankan simulator atau awan awam untuk menjalankan mesin maya. Tetapi ini tidak bermakna tiada alternatif lain. Saya akan cuba memastikan anda mendapat maklumat terkini dengan penyelesaian termaju dan alatan moden!
Juga, saya tidak menyebut topik yang agak besar berkaitan dengan pemantauan. Dalam Bahagian 3, saya akan melihat alat pemantauan infrastruktur yang paling popular dan data serta metrik yang perlu dipertimbangkan.
Dan akhirnya. Pada masa hadapan, saya merancang untuk mengeluarkan kursus video tentang membina infrastruktur ujian dan alatan popular. Pada masa ini, terdapat beberapa kursus dan kuliah tentang DevOps di Internet, tetapi semua bahan dibentangkan dalam konteks pembangunan, bukan automasi ujian. Mengenai isu ini, saya sangat memerlukan maklum balas sama ada kursus sebegitu menarik dan bernilai untuk komuniti penguji dan jurutera automasi. Terima kasih terlebih dahulu!
Sumber: www.habr.com