Bagean 1: Web/Android
komentar: artikel iki minangka terjemahan menyang Rusia saka artikel asli Nanging, kabeh ilustrasi, pranala, kuotasi lan istilah disimpen ing basa asli supaya ora distorsi makna nalika diterjemahake menyang basa Rusia. Muga-muga sampeyan seneng sinau!
Saiki, spesialisasi DevOps minangka salah sawijining sing paling dikarepake ing industri IT. Yen sampeyan mbukak situs telusuran proyek sing populer lan nyaring miturut gaji, sampeyan bakal weruh proyek sing gegandhengan karo DevOps ana ing ndhuwur dhaptar. Nanging, penting kanggo ngerti manawa iki utamane nuduhake posisi 'Senior', sing nuduhake manawa calon kasebut duwe katrampilan, kawruh babagan teknologi lan alat sing dhuwur. Iki uga nduweni tanggung jawab sing dhuwur sing ana gandhengane karo operasi produksi sing ora diganggu. Nanging, kita wiwit lali apa DevOps. Kaping pisanan, ora ana wong utawa departemen tartamtu. Yen kita nggoleki definisi istilah iki, kita bakal nemokake akeh tembung sing apik lan bener, kayata metodologi, praktik, filsafat budaya, klompok konsep, lan liya-liyane.
Spesialisasiku yaiku insinyur otomatisasi tes (insinyur otomatisasi QA), nanging aku percaya yen ora mung ana gandhengane karo nulis tes otomatis utawa ngembangake arsitektur kerangka tes. Ing 2020, kawruh babagan infrastruktur otomatisasi uga penting. Iki ngidini sampeyan ngatur proses otomatisasi dhewe, saka nganakake tes nganti menehi asil kanggo kabeh pemangku kepentingan sing cocog karo tujuan sampeyan. Akibaté, katrampilan DevOps kudu ditindakake kanggo proyek iki. Lan kabeh iki apik, nanging, sayangé, ana masalah (spoiler: artikel iki nyoba kanggo menakake masalah iki). Intine yaiku DevOps angel. Lan iki jelas, amarga perusahaan ora bakal mbayar akeh kanggo perkara sing gampang ditindakake ... Ing donya DevOps, ana akeh alat, istilah, lan praktik sing kudu dikuasai. Iki angel banget ing wiwitan karir lan gumantung saka pengalaman teknis sing akumulasi.
Source:
Ing kene kita bakal ngrampungake bagean pambuka lan fokus ing tujuan artikel iki.
Artikel iki babagan apa?
Ing artikel iki, aku bakal nuduhake pengalaman mbangun infrastruktur otomatisasi tes. Ana akeh sumber informasi ing Internet babagan macem-macem alat lan cara nggunakake, nanging aku pengin ndeleng kanthi murni ing konteks otomatisasi. Aku percaya manawa akeh insinyur otomatis sing ngerti kahanan kasebut nalika ora ana wong liya kajaba sampeyan nindakake tes sing dikembangake utawa peduli babagan njaga. Akibaté, tes dadi ketinggalan jaman lan sampeyan kudu nglampahi wektu kanggo nganyari. Maneh, ing wiwitan karir, iki bisa dadi tugas sing angel: kanthi wicaksana mutusake alat sing kudu mbantu ngilangi masalah sing diwenehake, carane milih, ngatur lan njaga. Sawetara penguji njaluk bantuan DevOps (manungsa) lan, jujur, pendekatan iki bisa digunakake. Ing sawetara kasus, iki bisa dadi siji-sijine pilihan amarga kita ora duwe visibilitas menyang kabeh dependensi. Nanging kaya sing dingerteni, DevOps pancen sibuk banget, amarga kudu mikir babagan infrastruktur, penyebaran, pemantauan, layanan mikro lan tugas liyane sing padha gumantung saka organisasi / tim. Kaya biasane, otomatisasi ora dadi prioritas. Ing kasus kaya mengkono, kita kudu ngupayakake kabeh sing bisa ditindakake saka wiwitan nganti pungkasan. Iki bakal nyuda dependensi, nyepetake alur kerja, nambah katrampilan lan ngidini kita ndeleng gambaran sing luwih gedhe babagan kedadeyan kasebut.
Artikel kasebut nampilake alat sing paling populer lan populer lan nuduhake cara nggunakake piranti kasebut kanggo mbangun infrastruktur otomatisasi langkah demi langkah. Saben kelompok diwakili piranti sing wis diuji liwat pengalaman pribadi. Nanging iki ora ateges sampeyan kudu nggunakake sing padha. Piranti dhewe ora penting, katon lan dadi lungse. Tugas teknik kita yaiku ngerti prinsip dhasar: kenapa kita butuh klompok alat iki lan masalah kerja apa sing bisa diatasi kanthi bantuan. Mulane ing pungkasan saben bagean aku ninggalake pranala menyang alat sing padha sing bisa digunakake ing organisasi sampeyan.
Apa sing ora ana ing artikel iki
Aku mbaleni maneh manawa artikel kasebut dudu babagan alat tartamtu, mula ora bakal ana sisipan kode saka dokumentasi lan deskripsi prentah tartamtu. Nanging ing pungkasan saben bagean aku ninggalake pranala kanggo sinau rinci.
Iki ditindakake amarga:
- materi iki gampang banget ditemokake ing macem-macem sumber (dokumentasi, buku, kursus video);
- yen kita miwiti luwih jero, kita kudu nulis 10, 20, 30 bagean artikel iki (nalika rencana 2-3);
- Aku mung ora pengin mbuwang wektu amarga sampeyan bisa uga pengin nggunakake alat liyane kanggo nggayuh tujuan sing padha.
Praktek
Aku pancene pengin materi iki migunani kanggo saben maca, lan ora mung maca lan lali. Ing sinau apa wae, praktik minangka komponen sing penting banget. Kanggo iki aku wis nyiapake. Ana uga peer nunggu sampeyan kanggo mesthekake yen sampeyan ora mindlessly nyalin baris saka printah sing kaleksanan.
Rencana
Langkah
Teknologi
Tools
1
Run lokal (siapake tes demo web / android lan jalanake sacara lokal)
Node.js, Selenium, Appium
2
Sistem kontrol versi
Git
3
Kontainerisasi
Docker, Selenium grid, Selenoid (Web, Android)
4
CI/CD
Gitlab CI
5
Platform cloud
Google Cloud Platform
6
Orchestrasi
Kubernetes
7
Infrastruktur minangka kode (IaC)
Terraform, Ansible
Struktur saben bagean
Supaya narasi tetep cetha, saben bagean diterangake miturut garis ing ngisor iki:
- gambaran singkat babagan teknologi,
- Nilai kanggo infrastruktur otomatisasi,
- ilustrasi kondisi infrastruktur saiki,
- link kanggo sinau,
- piranti sing padha.
1. Run tes lokal
gambaran Brief saka teknologi
Iki mung minangka langkah persiapan kanggo mbukak tes demo sacara lokal lan verifikasi manawa dheweke lulus. Ing bagean praktis, Node.js digunakake, nanging basa pamrograman lan platform uga ora penting lan sampeyan bisa nggunakake sing digunakake ing perusahaan sampeyan.
Nanging, minangka alat otomatisasi, aku nyaranake nggunakake Selenium WebDriver kanggo platform web lan Appium kanggo platform Android, amarga ing langkah-langkah sabanjure kita bakal nggunakake gambar Docker sing cocog kanggo nggarap alat kasebut. Kajaba iku, nuduhake syarat kerja, alat kasebut minangka sing paling dikarepake ing pasar.
Kaya sing sampeyan ngerteni, kita mung nganggep tes web lan Android. Sayange, iOS minangka crita sing beda banget (matur nuwun Apple). Aku rencana kanggo nampilake solusi lan praktik sing ana gandhengane karo IOS ing bagean sing bakal teka.
Nilai kanggo infrastruktur otomatisasi
Saka perspektif infrastruktur, mlaku sacara lokal ora menehi nilai. Sampeyan mung mriksa yen tes mbukak ing mesin lokal ing browser lan simulator lokal. Nanging ing kasus apa wae, iki minangka titik wiwitan sing dibutuhake.
Ilustrasi kahanan infrastruktur saiki
Link kanggo njelajah
Piranti sing padha
- basa pemrograman apa wae sing disenengi bebarengan karo tes Selenium / Appium;
- sembarang tes;
- sembarang test runner.
2. Sistem kontrol versi (Git)
gambaran Brief saka teknologi
Ora bakal dadi wahyu gedhe kanggo sapa wae yen aku ujar manawa kontrol versi minangka bagean pangembangan sing penting banget, ing tim lan individu. Adhedhasar macem-macem sumber, bisa dingerteni manawa Git minangka wakil sing paling populer. Sistem kontrol versi nyedhiyakake akeh keuntungan, kayata enggo bareng kode, nyimpen versi, mulihake menyang cabang sadurunge, ngawasi riwayat proyek, lan gawe serep. Kita ora bakal ngrembug saben titik kanthi rinci, amarga aku yakin manawa sampeyan wis kenal banget lan digunakake ing pakaryan saben dinane. Nanging yen dumadakan ora, banjur aku nyaranake ngaso maca artikel iki lan ngisi longkangan iki sanalika bisa.
Nilai kanggo infrastruktur otomatisasi
Lan ing kene sampeyan bisa takon pitakonan sing cukup: "Napa dheweke ngandhani babagan Git? Kabeh wong ngerti iki lan digunakake kanggo kode pangembangan lan kode tes otomatis. Sampeyan bakal bener, nanging ing artikel iki kita ngomong babagan infrastruktur lan bagean iki minangka pratinjau kanggo bagean 7: "Infrastruktur minangka Kode (IaC)". Kanggo kita, iki tegese kabeh infrastruktur, kalebu testing, diterangake ing wangun kode, supaya kita uga bisa nggunakake sistem versi kanggo iku lan entuk keuntungan padha kanggo pembangunan lan kode otomatisasi.
Kita bakal nliti IaC kanthi luwih rinci ing Langkah 7, nanging saiki sampeyan bisa miwiti nggunakake Git sacara lokal kanthi nggawe repositori lokal. Gambar gedhe bakal ditambahi nalika kita nambah repositori remot menyang infrastruktur.
Ilustrasi kahanan infrastruktur saiki
Link kanggo njelajah
Piranti sing padha
3. Kontainerisasi (Docker)
gambaran Brief saka teknologi
Kanggo nduduhake carane containerization wis ngganti aturan game, ayo bali ing sawetara dekade. Nalika iku, wong tuku lan nggunakake mesin server kanggo mbukak aplikasi. Nanging ing umume kasus, sumber daya wiwitan sing dibutuhake ora dingerteni sadurunge. Akibaté, perusahaan ngginakaken dhuwit kanggo tuku larang, server kuat, nanging sawetara saka kapasitas iki ora rampung digunakke.
Tahap evolusi sabanjure yaiku mesin virtual (VM), sing ngrampungake masalah mbuwang dhuwit kanggo sumber daya sing ora digunakake. Teknologi iki ndadekake bisa mbukak aplikasi kanthi mandiri ing server sing padha, nyedhiyakake papan sing terisolasi. Nanging, sayangé, sembarang teknologi duwe drawbacks. Mlaku VM mbutuhake sistem operasi lengkap, kang nganggo CPU, RAM, panyimpenan lan, gumantung ing OS, biaya lisensi kudu dijupuk menyang akun. Faktor iki mengaruhi kacepetan loading lan nggawe portabilitas angel.
Lan saiki kita teka menyang containerization. Sawise maneh, teknologi iki ngrampungake masalah sadurunge, amarga kontaner ora nggunakake OS lengkap, sing mbebasake sumber daya sing akeh lan menehi solusi sing cepet lan fleksibel kanggo portabilitas.
Mesthi, teknologi containerization ora anyar lan pisanan dikenalake ing pungkasan taun 70-an. Ing jaman semana, akeh riset, pangembangan, lan upaya sing ditindakake. Nanging Docker sing adaptasi teknologi iki lan gampang diakses kanggo masal. Saiki, nalika kita ngomong babagan kontaner, umume kita tegese Docker. Nalika kita ngomong babagan wadah Docker, tegese wadah Linux. Kita bisa nggunakake sistem Windows lan macOS kanggo mbukak wadhah, nanging penting kanggo ngerti yen ing kasus iki lapisan tambahan katon. Contone, Docker ing Mac mbukak wadhah kanthi meneng ing VM Linux sing entheng. Kita bakal bali menyang topik iki nalika kita ngrembug nglakokake emulator Android ing kontaner, mula ana nuansa penting sing kudu dibahas kanthi luwih rinci.
Nilai kanggo infrastruktur otomatisasi
Kita nemokake manawa containerization lan Docker keren. Ayo goleki iki ing konteks otomatisasi, amarga saben alat utawa teknologi kudu ngrampungake masalah. Ayo kita njelasake masalah sing jelas babagan otomatisasi tes ing konteks tes UI:
- akeh dependensi nalika nginstal Selenium lan utamane Appium;
- masalah kompatibilitas antarane versi browser, simulator lan driver;
- lack saka papan terisolasi kanggo browser / simulator, kang utamané kritis kanggo mlaku podo;
- angel kanggo ngatur lan njaga yen sampeyan kudu mbukak 10, 50, 100 utawa malah 1000 browser ing wektu sing padha.
Nanging amarga Selenium minangka alat otomatisasi sing paling populer lan Docker minangka alat kontanerisasi sing paling populer, mula ora kaget yen ana wong sing nyoba nggabungake supaya bisa nggawe alat sing kuat kanggo ngatasi masalah sing kasebut ing ndhuwur. Ayo nimbang solusi kasebut kanthi luwih rinci.
Selenium kothak ing docker
Alat iki paling populer ing donya Selenium kanggo mbukak macem-macem browser ing macem-macem mesin lan ngatur saka hub tengah. Kanggo miwiti, sampeyan kudu ndhaptar paling sethithik 2 bagean: Hub lan Node. Hub minangka simpul tengah sing nampa kabeh panjalukan saka tes lan disebarake menyang Node sing cocog. Kanggo saben Node, kita bisa ngatur konfigurasi tartamtu, contone, kanthi nemtokake browser sing dikarepake lan versi. Nanging, kita isih kudu ngurus driver browser sing kompatibel lan nginstal ing Node sing dikarepake. Mulane, kothak Selenium ora digunakake ing wangun murni, kajaba nalika kita kudu nggarap browser sing ora bisa diinstal ing Linux OS. Kanggo kabeh kasus liyane, solusi sing fleksibel lan bener yaiku nggunakake gambar Docker kanggo mbukak Selenium grid Hub lan Nodes. Pendekatan iki nyederhanakake manajemen simpul, amarga kita bisa milih gambar sing dibutuhake karo versi browser lan driver sing kompatibel sing wis diinstal.
Senadyan review negatif babagan stabilitas, utamané nalika mbukak nomer akeh Node ing podo karo, Selenium kothak isih alat paling populer kanggo mbukak tes Selenium ing podo karo. Wigati dicathet yen macem-macem dandan lan modifikasi alat iki terus-terusan muncul ing open-source, sing nglawan macem-macem bottlenecks.
Selenoid kanggo Web
Alat iki minangka terobosan ing jagad Selenium amarga kerjane langsung metu saka kothak lan wis nggawe urip akeh insinyur otomatisasi luwih gampang. Kaping pisanan, iki dudu modifikasi kothak Selenium liyane. Nanging, pangembang nggawe versi Selenium Hub sing anyar ing Golang, sing digabungake karo gambar Docker sing entheng kanggo macem-macem browser, menehi dorongan kanggo pangembangan otomatisasi tes. Kajaba iku, ing kasus Selenium Grid, kita kudu nemtokake kabeh browser sing dibutuhake lan versi sing luwih dhisik, sing ora dadi masalah nalika nggarap mung siji browser. Nanging nalika nerangake macem-macem browser sing didhukung, Selenoid minangka solusi nomer siji amarga fitur 'browser on demand'. Kabeh sing dibutuhake yaiku ndownload gambar sing dibutuhake karo browser sadurunge lan nganyari file konfigurasi sing Selenoid sesambungan. Sawise Selenoid nampa panjalukan saka tes, bakal kanthi otomatis mbukak wadhah sing dikarepake nganggo browser sing dikarepake. Nalika tes rampung, Selenoid bakal pensiun wadhah kasebut, saéngga mbebasake sumber daya kanggo panjaluk ing mangsa ngarep. Pendekatan iki rampung ngilangi masalah kondhang 'degradasi simpul' sing asring kita temoni ing kothak Selenium.
Nanging, sayangé, Selenoid isih dudu peluru perak. Kita entuk fitur 'browser on demand', nanging fitur 'resources on demand' isih durung kasedhiya. Kanggo nggunakake Selenoid, kita kudu masang ing hardware fisik utawa ing VM, kang tegese kita kudu ngerti ing advance carane akeh sumber daya kudu diparengake. Aku guess iki ora masalah kanggo proyek cilik sing mbukak 10, 20 utawa malah 30 browser ing podo karo. Nanging apa yen kita butuh 100, 500, 1000 utawa luwih? Ora ana gunane kanggo njaga lan mbayar sumber daya sing akeh. Ing bagean 5 lan 6 artikel iki, kita bakal ngrembug solusi sing ngidini sampeyan nggawe skala, saengga bisa nyuda biaya perusahaan kanthi signifikan.
Selenoid kanggo Android
Sawise sukses Selenoid minangka alat otomatisasi web, wong pengin sing padha karo Android. Lan kedadeyan - Selenoid dirilis kanthi dhukungan Android. Saka sudut pandang pangguna tingkat dhuwur, prinsip operasi padha karo otomatisasi web. Bentenipun mung sing tinimbang wadhah browser, Selenoid mbukak wadhah emulator Android. Miturut pendapatku, iki minangka alat gratis sing paling kuat kanggo nglakokake tes Android kanthi paralel.
Aku pancene ora kaya kanggo pirembagan bab aspèk negatif saka alat iki, awit aku pancene seneng banget. Nanging isih, ana kekurangan sing padha sing ditrapake kanggo otomatisasi web lan digandhengake karo skala. Saliyane iki, kita kudu ngomong babagan siji watesan liyane sing bisa uga kaget yen kita nyetel alat kasebut kanggo pisanan. Kanggo mbukak gambar Android, kita butuh mesin fisik utawa VM kanthi dhukungan virtualisasi bersarang. Ing pandhuan carane, aku nduduhake carane ngaktifake iki ing VM Linux. Nanging, yen sampeyan pangguna macOS lan pengin nyebarake Selenoid sacara lokal, mula iki ora bisa ditindakake kanggo tes Android. Nanging sampeyan bisa mbukak Linux VM sacara lokal kanthi konfigurasi 'virtualisasi bersarang' lan masang Selenoid ing njero.
Ilustrasi kahanan infrastruktur saiki
Ing konteks artikel iki, kita bakal nambah 2 alat kanggo nggambarake infrastruktur kasebut. Iki minangka kothak Selenium kanggo tes web lan Selenoid kanggo tes Android. Ing tutorial GitHub, aku uga bakal nuduhake sampeyan carane nggunakake Selenoid kanggo mbukak tes web.
Link kanggo njelajah
Piranti sing padha
- Ana alat containerization liyane, nanging Docker paling populer. Yen sampeyan pengin nyoba liya, elinga yen alat sing wis kita bahas kanggo nglakokake tes Selenium kanthi podo karo ora bakal bisa digunakake.
- Kaya sing wis dingerteni, ana akeh modifikasi kothak Selenium, umpamane,.
4. CI/CD
gambaran Brief saka teknologi
Praktek integrasi terus-terusan cukup populer ing pangembangan lan setara karo sistem kontrol versi. Senadyan iki, aku rumangsa ana kebingungan ing terminologi. Ing paragraf iki aku pengin njlèntrèhaké 3 modifikasi teknologi iki saka sudut pandangku. Ing internet sampeyan bakal nemokake akeh artikel kanthi interpretasi sing beda-beda, lan pancen normal yen pendapat sampeyan beda. Sing paling penting yaiku sampeyan ana ing kaca sing padha karo kanca-kanca.
Dadi, ana 3 istilah: CI - Continuous Integration, CD - Continuous Delivery lan maneh CD - Continuous Deployment. (Ing ngisor iki aku bakal nggunakake istilah kasebut ing basa Inggris). Saben modifikasi nambah sawetara langkah tambahan menyang pipa pangembangan sampeyan. Nanging tembung terus (terus-terusan) iku sing paling penting. Ing konteks iki, kita tegese soko sing kedadeyan saka wiwitan nganti rampung, tanpa gangguan utawa intervensi manual. Ayo katon ing CI & CD lan CD ing konteks iki.
- Integrasi terus-terusan iki minangka langkah awal evolusi. Sawise ngirim kode anyar menyang server, kita ngarep-arep nampa umpan balik sing cepet yen owah-owahan kita ok. Biasane, CI nyakup alat analisis kode statis lan tes API unit/internal. Iki ngidini kita entuk informasi babagan kode sajrone sawetara detik/menit.
- Pangiriman sing Terus minangka langkah sing luwih maju ing ngendi kita mbukak tes integrasi / UI. Nanging, ing tahap iki kita ora entuk asil kanthi cepet kaya CI. Kaping pisanan, jinis tes kasebut butuh wektu luwih suwe kanggo rampung. Kapindho, sadurunge diluncurake, kita kudu ngetrapake owah-owahan menyang lingkungan tes / pementasan. Kajaba iku, yen kita ngomong babagan pangembangan seluler, banjur ana langkah tambahan kanggo nggawe aplikasi kita.
- Penyebaran Terus-terusan nganggep manawa kita ngeculake owah-owahan produksi kanthi otomatis yen kabeh tes sing ditampa wis ditindakake ing tahap sadurunge. Kajaba iku, sawise tahap rilis, sampeyan bisa ngatur macem-macem tahapan, kayata tes kumelun ing produksi lan ngumpulake metrik kapentingan. Penyebaran Terus-terusan mung bisa ditindakake kanthi jangkoan sing apik kanthi tes otomatis. Yen intervensi manual dibutuhake, kalebu tes, mula ora ana maneh dadi (terus-terusan). Banjur kita bisa ujar manawa pipa kita mung tundhuk karo praktik Pangiriman Terus-terusan.
Nilai kanggo infrastruktur otomatisasi
Ing bagean iki, aku kudu njlentrehake yen nalika kita ngomong babagan tes UI end-to-end, tegese kita kudu masang owah-owahan lan layanan sing gegandhengan kanggo nyoba lingkungan. Integrasi Terus-terusan - proses kasebut ora ditrapake kanggo tugas iki lan kita kudu ngetrapake paling ora praktik Ngirim Terus-terusan. Penyebaran Terus-terusan uga nggawe pangertèn ing konteks tes UI yen kita bakal mbukak ing produksi.
Lan sadurunge kita ndeleng ilustrasi babagan owah-owahan arsitektur, aku pengin ngomong sawetara tembung babagan GitLab CI. Ora kaya piranti CI/CD liyane, GitLab nyedhiyakake repositori remot lan akeh fitur tambahan liyane. Mangkono, GitLab luwih saka CI. Iki kalebu manajemen kode sumber, manajemen Agile, pipa CI / CD, alat logging lan koleksi metrik metu saka kothak. Arsitektur GitLab kasusun saka Gitlab CI/CD lan GitLab Runner. Mangkene katrangan singkat saka situs web resmi:
Gitlab CI / CD minangka aplikasi web kanthi API sing nyimpen negara ing basis data, ngatur proyek / mbangun lan menehi antarmuka panganggo. GitLab Runner minangka aplikasi sing diproses. Bisa disebarake kanthi kapisah lan bisa digunakake karo GitLab CI/CD liwat API. Kanggo tes sing mlaku sampeyan butuh conto Gitlab lan Runner.
Ilustrasi kahanan infrastruktur saiki
Link kanggo njelajah
Piranti sing padha
- Lan akeh liyane
5. Platform awan
gambaran Brief saka teknologi
Ing bagean iki kita bakal ngomong babagan tren populer sing diarani 'awan umum'. Sanajan entuk manfaat gedhe sing diwenehake dening teknologi virtualisasi lan kontainer ing ndhuwur, kita isih butuh sumber daya komputasi. Perusahaan tuku server sing larang utawa nyewa pusat data, nanging ing kasus iki perlu kanggo nggawe petungan (kadhangkala ora nyata) babagan jumlah sumber daya sing dibutuhake, apa kita bakal nggunakake 24/7 lan kanggo tujuan apa. Contone, produksi mbutuhake server sing mlaku XNUMX/XNUMX, nanging apa kita butuh sumber daya sing padha kanggo tes ing njaba jam kerja? Iku uga gumantung saka jinis tes sing ditindakake. Conto bakal tes beban / stres sing bakal ditindakake sajrone jam ora kerja supaya entuk asil ing dina sabanjure. Nanging mesthi kasedhiyan server XNUMX/XNUMX ora dibutuhake kanggo tes otomatis end-to-end lan utamane ora kanggo lingkungan testing manual. Kanggo kahanan kaya ngono, luwih becik entuk akeh sumber daya sing dibutuhake, gunakake, lan mandheg mbayar yen ora dibutuhake maneh. Kajaba iku, luwih becik nampa kanthi cepet kanthi nggawe sawetara klik mouse utawa mbukak sawetara skrip. Iki digunakake kanggo awan umum. Ayo ndeleng definisi:
"Awan umum ditetepake minangka layanan komputasi sing ditawakake panyedhiya pihak katelu liwat Internet umum, supaya kasedhiya kanggo sapa wae sing pengin nggunakake utawa tuku. Bisa uga gratis utawa didol on-demand, ngidini para pelanggan mung mbayar saben panggunaan kanggo siklus CPU, panyimpenan, utawa bandwidth sing dikonsumsi.
Ana panemu yen awan umum larang. Nanging ide utama yaiku nyuda biaya perusahaan. Kaya sing wis kasebut sadurunge, awan umum ngidini sampeyan entuk sumber daya sing dikarepake lan mung mbayar wektu sampeyan nggunakake. Uga, kadhangkala kita lali yen karyawan nampa gaji, lan spesialis uga sumber larang. Sampeyan kudu eling yen awan umum nggawe dhukungan infrastruktur luwih gampang, sing ngidini para insinyur fokus ing tugas sing luwih penting.
Nilai kanggo infrastruktur otomatisasi
Sumber daya spesifik apa sing dibutuhake kanggo tes UI end-to-end? Sejatine iki mesin virtual utawa kluster (kita bakal pirembagan bab Kubernetes ing bagean sabanjuré) kanggo mbukak browser lan emulator. Sing liyane browser lan emulators kita arep kanggo mbukak bebarengan, liyane CPU lan memori dibutuhake lan liyane dhuwit kita kudu mbayar kanggo. Mangkono, awan umum ing konteks otomatisasi tes ngidini kita mbukak akeh browser / emulator sing akeh (100, 200, 1000 ...) sing dikarepake, entuk asil tes kanthi cepet lan mandheg mbayar biaya intensif sumber daya kasebut. daya.
Panyedhiya awan sing paling populer yaiku Amazon Web Services (AWS), Microsoft Azure, Google Cloud Platform (GCP). Pandhuan carane menehi conto carane nggunakake GCP, nanging umume ora masalah apa sing sampeyan gunakake kanggo tugas otomatisasi. Kabeh padha nyedhiyakake fungsi sing padha. Biasane, kanggo milih panyedhiya, manajemen fokus marang prasarana lan syarat bisnis sakabèhé perusahaan, sing ora ana ing ruang lingkup artikel iki. Kanggo insinyur otomatisasi, bakal luwih menarik kanggo mbandhingake panggunaan panyedhiya awan karo panggunaan platform awan khusus kanggo tujuan testing, kayata Sauce Labs, BrowserStack, BitBar, lan liya-liyane. Dadi ayo uga! Miturut pendapatku, Sauce Labs minangka peternakan uji coba awan sing paling misuwur, mula aku digunakake kanggo mbandhingake.
GCP vs Sauce Labs kanggo tujuan otomatisasi:
Bayangake yen kita kudu nindakake 8 tes web lan 8 tes Android bebarengan. Iki kita bakal nggunakake GCP lan mbukak 2 mesin virtual karo Selenoid. Ing kawitan kita bakal mundhakaken 8 wadhah karo browser. Ing kaloro ana 8 wadhah karo emulator. Ayo ndeleng rega:
Kanggo mbukak siji wadhah karo Chrome, kita kudu n1-standar-1 mobil. Ing cilik saka Android bakal n1-standar-4 kanggo siji emulator. Nyatane, cara sing luwih fleksibel lan luwih murah yaiku nyetel nilai pangguna tartamtu kanggo CPU / Memori, nanging saiki iki ora penting kanggo dibandhingake karo Lab Sauce.
Lan ing ngisor iki tarif kanggo nggunakake Lab Saus:
Aku yakin sampeyan wis ngerteni prabédan kasebut, nanging aku isih bakal menehi tabel pitungan kanggo tugas kita:
Sumber daya sing dibutuhake
Wulan
Jam kerja(8 am - 8 pm)
Jam kerja+ Preemptible
GCP kanggo Web
n1-standar-1 x 8 = n1-standar-8
$194.18
23 dina * 12h * 0.38 = $ 104.88
23 dina * 12h * 0.08 = $ 22.08
Labs saus kanggo Web
Tes paralel Virtual Cloud8
$1.559
-
-
GCP kanggo Android
n1-standar-4 x 8: n1-standar-16
$776.72
23 dina * 12h * 1.52 = $ 419.52
23 dina * 12h * 0.32 = $ 88.32
Sauce Labs kanggo Android
Piranti nyata Cloud 8 tes podo
$1.999
-
-
Nalika sampeyan bisa ndeleng, prabédan ing biaya ageng, utamané yen sampeyan mbukak tes mung sak rolas jam kerja. Nanging sampeyan bisa nyuda biaya luwih akeh yen sampeyan nggunakake mesin preemptible. Opo kuwi?
VM preemptible minangka conto sing sampeyan bisa nggawe lan mbukak kanthi rega sing luwih dhuwur tinimbang kedadeyan normal. Nanging, Compute Engine bisa mungkasi (preempt) kedadeyan kasebut yen mbutuhake akses menyang sumber daya kasebut kanggo tugas liyane. Kahanan sing bisa ditindakake yaiku kapasitas Compute Engine sing berlebihan, saengga kasedhiyan beda-beda gumantung karo panggunaan.
Yen app sampeyan tahan fault lan bisa nahan preemptions contone, banjur conto preemptible bisa nyuda biaya Compute Engine sampeyan kanthi signifikan. Contone, proyek pangolahan batch bisa ditindakake kanthi preemptible. Yen sawetara kedadeyan kasebut mandheg sajrone proses, proyek kasebut alon-alon nanging ora mandheg. Kasus preemptible ngrampungake tugas pangolahan batch tanpa nempatake beban kerja tambahan ing kedadeyan sing wis ana lan tanpa mbutuhake sampeyan mbayar rega lengkap kanggo kedadeyan normal tambahan.
Lan isih durung rampung! Ing kasunyatan, aku yakin ora ana sing nganakake tes sajrone 12 jam tanpa istirahat. Lan yen mangkono, sampeyan bisa kanthi otomatis miwiti lan mungkasi mesin virtual nalika ora dibutuhake. Wektu panggunaan nyata bisa dikurangi dadi 6 jam saben dina. Banjur pembayaran ing konteks tugas kita bakal mudhun dadi $11 saben sasi kanggo 8 browser. Apa ora iki apik banget? Nanging karo mesin preemptible kita kudu ati-ati lan disiapake kanggo gangguan lan kahanan kang ora tetep, sanajan kahanan iki bisa kasedhiya lan ditangani ing piranti lunak. Iku worth iku!
Nanging ora ateges aku ujar 'aja nggunakake peternakan uji awan'. Padha duwe sawetara kaluwihan. Kaping pisanan, iki ora mung mesin virtual, nanging solusi otomatisasi tes lengkap kanthi seperangkat fungsi metu saka kothak: akses remot, log, gambar, rekaman video, macem-macem browser lan piranti seluler fisik. Ing pirang-pirang kahanan, iki bisa dadi alternatif sing apik banget. Platform tes utamane migunani kanggo otomatisasi IOS, nalika awan umum mung bisa menehi sistem Linux/Windows. Nanging kita bakal ngomong babagan iOS ing artikel ing ngisor iki. Aku nyaranake tansah ndeleng kahanan lan miwiti saka tugas: ing sawetara kasus iku luwih murah lan luwih efisien kanggo nggunakake awan umum, lan ing liyane platform test mesthi worth dhuwit ngginakaken.
Ilustrasi kahanan infrastruktur saiki
Link kanggo njelajah
Alat sing padha:
6. Orkestrasi
gambaran Brief saka teknologi
Aku duwe kabar apik - kita meh ing pungkasan artikel! Saiki, infrastruktur otomasi kita kalebu tes web lan Android, sing ditindakake liwat GitLab CI kanthi paralel, nggunakake alat sing aktif Docker: Selenium grid lan Selenoid. Kajaba iku, kita nggunakake mesin virtual sing digawe liwat GCP kanggo dadi tuan rumah wadah nganggo browser lan emulator. Kanggo nyuda biaya, kita miwiti mesin virtual kasebut mung yen dikarepake lan mandheg nalika tes ora ditindakake. Apa ana liyane sing bisa nambah infrastruktur kita? Jawabane ya! Ketemu Kubernetes (K8s)!
Pisanan, ayo dideleng kepiye hubungane tembung orkestrasi, kluster, lan Kubernetes. Ing tingkat dhuwur, orkestrasi minangka sistem sing nyebarake lan ngatur aplikasi. Kanggo otomatisasi tes, aplikasi wadah kasebut yaiku kothak Selenium lan Selenoid. Docker lan K8s nglengkapi saben liyane. Sing pisanan digunakake kanggo panyebaran aplikasi, sing nomer loro kanggo orkestrasi. Sabanjure, K8s minangka kluster. Tugas kluster yaiku nggunakake VM minangka Node, sing ngidini sampeyan nginstal macem-macem fungsi, program lan layanan ing siji server (cluster). Yen salah siji saka Node gagal, Node liyane bakal njupuk, sing njamin operasi tanpa gangguan saka aplikasi kita. Kajaba iku, K8s nduweni fungsi penting sing gegandhengan karo skala, kanthi otomatis entuk sumber daya sing paling optimal adhedhasar beban lan watesan sing disetel.
Sejatine, nyebarake Kubernetes kanthi manual saka awal dudu tugas sing sepele. Aku bakal ninggalake link kanggo misuwur carane-nuntun "Kubernetes The Hard Way" lan yen sampeyan kasengsem, sampeyan bisa laku. Nanging, untunge, ana cara lan alat alternatif. Cara paling gampang yaiku nggunakake Google Kubernetes Engine (GKE) ing GCP, sing bakal ngidini sampeyan entuk kluster sing wis siap ing sawetara klik. Aku nyaranake nggunakake pendekatan iki kanggo miwiti sinau, amarga bakal ngidini sampeyan fokus ing sinau carane nggunakake K8 kanggo tugas tinimbang sinau carane komponen internal kudu Integrasi karo saben liyane.
Nilai kanggo infrastruktur otomatisasi
Ayo goleki sawetara fitur penting sing diwenehake K8s:
- penyebaran aplikasi: nggunakake kluster multi-node tinimbang VM;
- skala dinamis: nyuda biaya sumber daya sing mung digunakake ing dikarepake;
- marasake awakmu dhewe: Recovery otomatis saka pods (minangka asil kang wadhah uga dibalèkaké);
- nganyari nganyari lan mbalek maneh owah-owahan tanpa downtime: nganyari alat, browser lan emulator ora ngganggu karya pangguna saiki
Nanging K8s isih dudu peluru perak. Kanggo mangerteni kabeh kaluwihan lan watesan ing konteks alat sing kita pikirake (Selenium grid, Selenoid), kita bakal ngrembug babagan struktur K8 kanthi ringkes. Kluster ngemot rong jinis Node: Node Master lan Node Pekerja. Master Nodes tanggung jawab kanggo manajemen, panyebaran lan keputusan jadwal. Node pekerja minangka papan kanggo mbukak aplikasi. Node uga ngemot lingkungan runtime wadhah. Ing kasus kita, iki Docker, sing tanggung jawab kanggo operasi sing gegandhengan karo wadhah. Nanging ana uga solusi alternatif, contone. Penting kanggo ngerti manawa skala utawa marasake awak dhewe ora ditrapake langsung ing wadhah. Iki dileksanakake kanthi nambah / nyuda jumlah polong, sing uga ngemot wadhah (biasane siji wadhah saben polong, nanging gumantung saka tugas bisa uga luwih akeh). Hierarki tingkat dhuwur kasusun saka simpul pekerja, ing njero ana polong, ing njero wadhah diunggahake.
Fitur skala minangka kunci lan bisa ditrapake kanggo loro simpul ing simpul-kolam kluster lan pod ing simpul. Ana 2 jinis skala sing ditrapake kanggo simpul lan pod. Jinis pisanan horisontal - scaling dumadi kanthi nambah jumlah node/pods. Jinis iki luwih disenengi. Jinis kapindho, miturut, vertikal. Scaling ditindakake kanthi nambah ukuran simpul / polong, dudu jumlahe.
Saiki ayo goleki alat kita ing konteks istilah ing ndhuwur.
Selenium kothak
Kaya sing wis kasebut sadurunge, kothak Selenium minangka alat sing populer banget, lan ora kaget yen wis disimpen. Mulane, ora kaget yen kothak Selenium bisa disebarake ing K8s. Conto carane nindakake iki bisa ditemokake ing repositori K8s resmi. Kaya biasane, aku masang pranala ing mburi bagean. Kajaba iku, pandhuan cara nuduhake carane nindakake iki ing Terraform. Ana uga pandhuan babagan cara ngukur jumlah pod sing ngemot wadhah browser. Nanging fungsi njongko otomatis ing konteks K8s isih ora tugas rampung ketok. Nalika miwiti sinau, aku ora nemu tuntunan utawa rekomendasi praktis. Sawise sawetara pasinaon lan eksperimen kanthi dhukungan saka tim DevOps, kita milih pendekatan kanggo ngunggahake wadhah kanthi browser sing dibutuhake ing siji pod, sing ana ing siji simpul pekerja. Cara iki ngidini kita nggunakake strategi skala horisontal simpul kanthi nambah jumlahe. Muga-muga iki bakal owah ing mangsa ngarep lan kita bakal weruh luwih akeh deskripsi babagan pendekatan sing luwih apik lan solusi sing wis siap, utamane sawise ngeculake Selenium grid 4 kanthi arsitektur internal sing diganti.
Selenoid:
Penyebaran Selenoid ing K8 saiki dadi kuciwane paling gedhe. Padha ora kompatibel. Ing teori, kita bisa ngunggahake wadhah Selenoid ing polong, nanging nalika Selenoid wiwit ngluncurake wadhah nganggo browser, dheweke isih ana ing polong sing padha. Iki ndadekake skala mokal lan, minangka asil, karya Selenoid ing kluster ora beda karo karya ing mesin virtual. Pungkasane crita.
Moon:
Ngerti bottleneck iki nalika nggarap Selenoid, para pangembang ngeculake alat sing luwih kuat sing diarani Moon. Alat iki wiwitane dirancang kanggo nggarap Kubernetes lan, minangka asil, fitur autoscaling bisa lan kudu digunakake. Kajaba iku, aku bakal ujar manawa saiki tunggal alat ing donya Selenium, sing duwe dhukungan kluster asli K8s metu saka kothak (ora kasedhiya maneh, ndeleng alat sabanjuré ). Fitur utama Moon sing nyedhiyakake dhukungan iki yaiku:
Rampung stateless. Selenoid nyimpen informasi memori babagan sesi browser sing lagi mlaku. Yen sakperangan alesan prosese nabrak - banjur kabeh sesi sing mlaku bakal ilang. Bulan ora duwe kahanan internal lan bisa ditiru ing pusat data. Sesi browser tetep urip sanajan siji utawa luwih replika mudhun.
Dadi, Bulan minangka solusi sing apik, nanging ana siji masalah: ora gratis. Rega gumantung saka jumlah sesi. Sampeyan mung bisa mbukak 0-4 sesi kanthi gratis, sing ora migunani banget. Nanging, wiwit saka sesi kaping lima, sampeyan kudu mbayar $5 kanggo saben. Kahanan bisa beda-beda saka perusahaan menyang perusahaan, nanging ing kasus kita, nggunakake Bulan ora ana gunane. Nalika aku diterangake ing ndhuwur, kita bisa mbukak VM karo Selenium Grid ing dikarepake utawa nambah nomer Node ing kluster. Kanggo kira-kira siji pipa, kita mbukak 500 browser lan mungkasi kabeh sumber daya sawise tes rampung. Yen kita nggunakake Bulan, kita kudu mbayar tambahan 500 x 5 = $2500 saben sasi, ora preduli sepira kerepe kita nganakake tes. Maneh, Aku ora ngandika ora nggunakake Bulan. Kanggo tugas sampeyan, iki bisa dadi solusi sing penting, umpamane, yen sampeyan duwe akeh proyek / tim ing organisasi sampeyan lan sampeyan butuh klompok umum sing gedhe kanggo kabeh wong. Kaya biasane, aku ninggalake link ing pungkasan lan nyaranake nindakake kabeh petungan sing dibutuhake ing konteks tugas sampeyan.
Callisto: (manungsa waé! Iki ora ana ing artikel asli lan mung ana ing terjemahan Rusia)
Kaya sing dakkandhakake, Selenium minangka alat sing populer, lan lapangan IT berkembang kanthi cepet. Nalika aku lagi nggarap terjemahan, alat anyar sing diarani Callisto muncul ing web (halo Cypress lan pembunuh Selenium liyane). Kerjane native karo K8s lan ngijini sampeyan kanggo mbukak kontaner Selenoid ing pods, mbagekke tengen Nodes. Kabeh bisa langsung metu saka kothak, kalebu autoscaling. Fantastic, nanging kudu dites. Aku wis ngatur kanggo masang alat iki lan mbukak sawetara nyobi. Nanging isih awal banget kanggo nggawe kesimpulan, sawise nampa asil saka jarak sing adoh, mbok menawa aku bakal nggawe review ing artikel sabanjure. Saiki aku mung ninggalake pranala kanggo riset independen.
Ilustrasi kahanan infrastruktur saiki
Link kanggo njelajah
Piranti sing padha
7. Infrastruktur minangka Kode (IaC)
gambaran Brief saka teknologi
Lan saiki kita teka ing bagean pungkasan. Biasane, teknologi iki lan tugas sing gegandhengan dudu tanggung jawab insinyur otomatisasi. Lan ana alesan kanggo iki. Kaping pisanan, ing pirang-pirang organisasi, masalah infrastruktur ana ing kontrol departemen DevOps lan tim pangembangan ora preduli babagan apa sing nggawe saluran pipa lan kepiye kabeh sing ana gandhengane kudu didhukung. Kapindho, jujur, praktik Infrastruktur minangka Kode (IaC) isih durung diadopsi ing pirang-pirang perusahaan. Nanging mesthine wis dadi tren sing populer lan penting kanggo nyoba melu proses, pendekatan lan alat sing ana gandhengane. Utawa paling ora tetep gaul.
Ayo dadi miwiti karo motivasi kanggo nggunakake pendekatan iki. Kita wis ngrembug manawa kanggo nganakake tes ing GitlabCI, kita butuh sumber daya minimal kanggo mbukak Gitlab Runner. Lan kanggo mbukak wadhah karo browser / emulator, kita kudu leladen VM utawa kluster. Saliyane kanggo nguji sumber daya, kita butuh kapasitas sing akeh kanggo ndhukung pangembangan, pementasan, lingkungan produksi, sing uga kalebu database, jadwal otomatis, konfigurasi jaringan, penyeimbang beban, hak pangguna, lan liya-liyane. Masalah utama yaiku upaya sing dibutuhake kanggo ndhukung kabeh. Ana sawetara cara kanggo nggawe pangowahan lan nganyari nganyari. Contone, ing konteks GCP, kita bisa nggunakake konsol UI ing browser lan nindakake kabeh tumindak kanthi ngeklik tombol. Alternatif yaiku nggunakake panggilan API kanggo sesambungan karo entitas awan, utawa nggunakake utilitas baris perintah gcloud kanggo nindakake manipulasi sing dikarepake. Nanging kanthi jumlah entitas lan unsur infrastruktur sing beda-beda, dadi angel utawa ora bisa nindakake kabeh operasi kanthi manual. Kajaba iku, kabeh tumindak manual iki ora bisa dikendhaleni. Kita ora bisa ngirim kanggo ditinjau sadurunge eksekusi, nggunakake sistem kontrol versi, lan cepet muter maneh owah-owahan sing nyebabake kedadeyan kasebut. Kanggo ngatasi masalah kasebut, insinyur nggawe lan nggawe skrip bash / shell otomatis, sing ora luwih apik tinimbang cara sadurunge, amarga ora gampang maca, ngerti, njaga lan ngowahi kanthi gaya prosedural.
Ing artikel iki lan carane nuntun, aku nggunakake 2 alat sing ana gandhengane karo praktik IaC. Iki minangka Terraform lan Ansible. Sawetara wong percaya yen ora ana gunane kanggo nggunakake ing wektu sing padha, amarga fungsine padha lan bisa diijolake. Nanging kasunyatan sing pisanan padha diwenehi tugas temen beda. Lan kasunyatan manawa alat kasebut kudu saling nglengkapi dikonfirmasi ing presentasi gabungan dening pangembang sing makili HashiCorp lan RedHat. Bentenane konseptual yaiku Terraform minangka alat panyedhiya kanggo ngatur server dhewe. Nalika Ansible minangka alat manajemen konfigurasi sing tugase kanggo nginstal, ngatur lan ngatur piranti lunak ing server kasebut.
Fitur liyane sing mbedakake alat kasebut yaiku gaya coding. Ora kaya bash lan Ansible, Terraform nggunakake gaya deklaratif adhedhasar katrangan babagan negara pungkasan sing dikarepake bakal digayuh minangka asil eksekusi. Contone, yen kita arep nggawe 10 VM lan ngetrapake owah-owahan liwat Terraform, mula kita bakal entuk 10 VM. Yen kita mbukak script maneh, ora bakal kelakon amarga kita wis duwe 10 VM, lan Terraform ngerti babagan iki amarga nyimpen kahanan saiki infrastruktur ing file negara. Nanging Ansible nggunakake pendekatan prosedural lan, yen sampeyan njaluk nggawe 10 VM, banjur ing peluncuran pisanan kita bakal entuk 10 VM, padha karo Terraform. Nanging sawise miwiti maneh, kita bakal duwe 20 VM. Iki prabédan penting. Ing gaya prosedural, kita ora nyimpen kahanan saiki lan mung nggambarake urutan langkah sing kudu ditindakake. Mesthi, kita bisa nangani macem-macem kahanan, nambah sawetara mriksa kanggo orane sumber daya lan negara saiki, nanging ora ana gunane kanggo mbuang wektu lan gaweyan kanggo ngontrol logika iki. Kajaba iku, iki nambah risiko nggawe kesalahan.
Ngringkes kabeh ing ndhuwur, kita bisa nyimpulake yen Terraform lan notasi deklaratif minangka alat sing luwih cocok kanggo nyedhiyakake server. Nanging luwih apik kanggo utusan karya manajemen konfigurasi menyang Ansible. Kanthi cara kasebut, ayo goleki kasus panggunaan ing konteks otomatisasi.
Nilai kanggo infrastruktur otomatisasi
Siji-sijine sing kudu dingerteni ing kene yaiku infrastruktur otomasi tes kudu dianggep minangka bagean saka kabeh infrastruktur perusahaan. Iki tegese kabeh praktik IaC kudu ditrapake sacara global kanggo sumber daya kabeh organisasi. Sapa sing tanggung jawab iki gumantung marang proses sampeyan. Tim DevOps luwih berpengalaman babagan masalah kasebut, dheweke ndeleng kabeh gambar babagan kedadeyan kasebut. Nanging, insinyur QA luwih melu proses otomatisasi bangunan lan struktur pipa, sing ngidini dheweke bisa ndeleng kabeh owah-owahan sing dibutuhake lan kesempatan kanggo perbaikan. Pilihan sing paling apik yaiku kerja bareng, ijol-ijolan kawruh lan ide kanggo entuk asil sing dikarepake.
Ing ngisor iki sawetara conto nggunakake Terraform lan Ansible ing konteks otomatisasi tes lan alat sing wis dibahas sadurunge:
1. Njlèntrèhaké ciri lan paramèter perlu VMs lan kluster nggunakake Terraform.
2. Nggunakake Ansible, nginstal alat sing dibutuhake kanggo testing: docker, Selenoid, Selenium Grid lan download versi browser / emulator sing dibutuhake.
3. Nggunakake Terraform, njlèntrèhaké karakteristik VM ing ngendi GitLab Runner bakal diluncurake.
4. Instal GitLab Runner lan alat sing dibutuhake nggunakake Ansible, nyetel setelan lan konfigurasi.
Ilustrasi kahanan infrastruktur saiki
Link kanggo njelajah:
Piranti sing padha
Ayo padha ngringkes!
Langkah
Teknologi
Tools
Nilai kanggo infrastruktur otomatisasi
1
Lokal mlaku
Node.js, Selenium, Appium
- Piranti sing paling populer kanggo web lan seluler
- Ndhukung akeh basa lan platform (kalebu Node.js)
2
Sistem kontrol versi
Git
- Keuntungan sing padha karo kode pangembangan
3
Kontainerisasi
Docker, Selenium grid, Selenoid (Web, Android)
- Mlaku tes ing podo karo
- Lingkungan terisolasi
- Prasaja, upgrade versi fleksibel
- Mungkasi sumber daya sing ora digunakake kanthi dinamis
- Gampang disiyapake
4
CI/CD
Gitlab CI
- Tes bagean saka pipa
- Umpan Balik Cepet
- Visibilitas kanggo kabeh perusahaan / tim
5
Platform cloud
Google Cloud Platform
- Sumber daya sing dikarepake (kita mbayar mung yen dibutuhake)
- Gampang kanggo ngatur lan nganyari
- Visibilitas lan kontrol kabeh sumber daya
6
Orchestrasi
Kubernetes
Ing konteks wadhah kanthi browser / emulator ing pods:
- Scaling / skala otomatis
- Marasake awakmu dhewe
- Nganyari lan muter maneh tanpa gangguan
7
Infrastruktur minangka kode (IaC)
Terraform, Ansible
- Keuntungan sing padha karo infrastruktur pembangunan
- Kabeh keuntungan saka versi kode
- Gampang kanggo ngganti lan njaga
- Kanthi otomatis
Diagram peta pikiran: evolusi infrastruktur
langkah 1: Lokal
langkah 2: VCS
langkah 3: Containerization
langkah 4: CI / CD
step5: Cloud Platforms
langkah 6: Orkestrasi
langkah 7: IaC
Apa sabanjuré?
Dadi, iki pungkasan artikel. Nanging ing kesimpulan, aku pengin nggawe sawetara perjanjian karo sampeyan.
Saka sisih sampeyan
Kaya sing dicritakake ing wiwitan, aku pengin artikel kasebut migunani lan mbantu sampeyan ngetrapake kawruh sing dipikolehi ing karya nyata. Aku nambah maneh.
Nanging sanajan sawise iku, aja mandheg, latihan, sinau pranala lan buku sing relevan, temokake cara kerjane ing perusahaan sampeyan, golek papan sing bisa ditingkatake lan melu. Sugeng enjang!
Saka sisihku
Saka judhul sampeyan bisa ndeleng manawa iki mung bagean pisanan. Sanajan kasunyatane cukup gedhe, topik penting isih durung dibahas ing kene. Ing bagean kapindho, aku arep ndeleng infrastruktur otomatisasi ing konteks IOS. Amarga watesan Apple kanggo mbukak simulator iOS mung ing sistem macOS, sawetara solusi kita sempit. Contone, kita ora bisa nggunakake Docker kanggo mbukak simulator utawa awan umum kanggo mbukak mesin virtual. Nanging iki ora ateges ora ana alternatif liyane. Aku bakal nyoba supaya sampeyan tetep anyar karo solusi canggih lan alat modern!
Uga, aku durung nyebutake topik sing cukup gedhe sing ana gandhengane karo pemantauan. Ing Bagean 3, aku bakal ndeleng alat pemantauan infrastruktur sing paling populer lan data lan metrik apa sing kudu ditimbang.
Lan pungkasane. Ing mangsa ngarep, aku arep ngluncurake kursus video babagan mbangun infrastruktur tes lan alat sing populer. Saiki, ana sawetara kursus lan ceramah ing DevOps ing Internet, nanging kabeh materi ditampilake ing konteks pangembangan, dudu tes otomatisasi. Ing masalah iki, aku pancene butuh umpan balik babagan apa kursus kasebut bakal menarik lan migunani kanggo komunitas penguji lan insinyur otomatis. Matur nuwun sadurunge!
Source: www.habr.com