Kiwari, kalolobaan produk parangkat lunak dikembangkeun dina tim. Kaayaan pikeun ngembangkeun tim suksés bisa digambarkeun dina bentuk diagram basajan.

Sakali anjeun parantos nyerat kode anjeun, anjeun kedah mastikeun:

1. Gawé.
2. Éta henteu ngarobih nanaon, kalebet kodeu anu ditulis ku kolega anjeun.

Lamun duanana kaayaan anu patepung, mangka anjeun dina jalur ka kasuksésan. Pikeun gampang pariksa kaayaan ieu teu nyimpang tina jalur nguntungkeun, kami datang nepi ka Integrasi Kontinyu.

CI mangrupikeun alur kerja dimana anjeun ngahijikeun kode anjeun kana kode produk sadayana sabisa-bisa. Na anjeun teu ngan ngahijikeun, tapi ogé terus pariksa yen sagalana berpungsi. Kusabab anjeun kedah parios pisan sareng sering, éta patut mikir ngeunaan automation. Anjeun tiasa pariksa sadayana sacara manual, tapi anjeun henteu kedah, sareng ieu sababna.

• Dear jalma. Sajam gawé programer mana wae leuwih mahal ti sajam gawe server mana wae.
• Jalma nyieun kasalahan. Ku alatan éta, kaayaan tiasa timbul nalika tés dijalankeun dina cabang anu salah atanapi komitmen anu salah disusun pikeun panguji.
• Jalma geus puguh. Ti waktos ka waktos, nalika abdi rengse hiji tugas, timbul pikiran: "Naon aya pikeun pariksa? Kuring nulis dua baris - sagalana jalan! Jigana sababaraha anjeun ogé kadang boga pikiran kitu. Tapi anjeun kedah salawasna pariksa.

Kumaha Pamaduan Kontinyu dilaksanakeun sarta dimekarkeun dina tim ngembangkeun mobile Avito, kumaha maranéhna indit ti 0 nepi ka 450 ngawangun per poé, sarta yén ngawangun mesin ngumpul 200 jam sapoé, nyebutkeun Nikolai Nesterov (nnesterov) nyaéta pamilon dina sagala parobahan évolusionér tina CI/CD aplikasi Android.

Carita didasarkeun kana conto paréntah Android, tapi kalolobaan pendekatan ogé tiasa dianggo dina ios.

Baheula, hiji jalma digawé di tim Avito Android. Dumasar watesan, anjeunna henteu peryogi nanaon tina Integrasi Kontinyu: teu aya anu ngahijikeun.

Tapi aplikasi na tumuwuh, beuki loba tugas anyar muncul, sarta tim tumuwuh sasuai. Di sawatara titik, éta waktuna pikeun leuwih formal ngadegkeun prosés integrasi kode. Diputuskeun pikeun ngagunakeun aliran Git.

Konsep aliran Git dipikanyaho: proyék ngagaduhan hiji cabang pamekaran umum, sareng pikeun unggal fitur énggal, pamekar motong cabang anu misah, komitmen ka dinya, nyorong, sareng nalika aranjeunna hoyong ngahijikeun kodena kana cabang ngembangkeun, buka a pamundut tarik. Pikeun ngabagi pangaweruh sareng ngabahas pendekatan, kami ngenalkeun ulasan kode, nyaéta, kolega kedah parios sareng mastikeun kodeu masing-masing.

Cék

Ningali kode ku panon anjeun tiis, tapi teu cukup. Ku alatan éta, cék otomatis keur diwanohkeun.

• Anu mimiti, urang pariksa Majelis ARK.
• Hiji pisan tés Junit.
• Urang mertimbangkeun sinyalna kode, saprak urang ngajalankeun tés.

Pikeun ngartos kumaha cék ieu kedah dijalankeun, hayu urang tingali prosés pamekaran di Avito.

Ieu bisa digambarkeun schematically kawas kieu:

• A pamekar nulis kode dina laptop na. Anjeun tiasa ngajalankeun cék integrasi di dieu - boh ku commit hook, atanapi ngan saukur ngajalankeun cék di latar tukang.
• Saatos pamekar parantos nyorong kodeu, anjeunna muka pamundut tarik. Supados kode na tiasa dilebetkeun kana cabang ngembangkeun, anjeun kedah ngaliwat ulasan kode sareng ngumpulkeun jumlah konfirmasi anu diperyogikeun. Anjeun tiasa ngaktipkeun cék sareng ngawangun di dieu: dugi ka sadayana gedong suksés, pamundut tarik teu tiasa dihijikeun.
• Saatos pamenta tarikan dihijikeun sareng kodeu kalebet dina ngembangkeun, anjeun tiasa milih waktos anu pikaresepeun: contona, wengi, nalika sadaya server gratis, sareng ngajalankeun saloba cék anu anjeun pikahoyong.

Teu aya anu resep ngajalankeun scan dina laptopna. Nalika pamekar parantos réngsé fitur, anjeunna hoyong gancang nyorong sareng muka pamundut tarik. Upami dina waktos ayeuna sababaraha cék panjang diluncurkeun, ieu sanés ngan ukur pikaresepeun, tapi ogé ngalambatkeun pangwangunan: nalika laptop mariksa hiji hal, mustahil tiasa dianggo sacara normal.

Urang bener resep ngajalankeun cék peuting, sabab aya loba waktu jeung server, anjeun tiasa roam sabudeureun. Tapi, hanjakalna, nalika kodeu fitur janten ngembangkeun, pamekar ngagaduhan motivasi anu langkung handap pikeun ngalereskeun kasalahan anu kapanggih ku CI. Kuring périodik bray sorangan pamikiran nalika kuring nempo sagala kasalahan kapanggih dina laporan isuk-isuk yén kuring bakal ngalereskeun aranjeunna someday engké, sabab ayeuna aya tugas anyar cool di Jira yén kuring ngan hayang ngamimitian ngalakukeun.

Lamun cék meungpeuk hiji pamundut narik, lajeng aya cukup motivasi, sabab nepi ka ngawangun ngahurungkeun héjo, kode moal meunang kana ngamekarkeun, nu hartina tugas moal réngsé.

Hasilna, urang milih strategi handap: urang ngajalankeun set maksimum mungkin tina cék peuting, sarta ngajalankeun paling kritis aranjeunna sarta, paling importantly, nu panggancangna dina pamundut tarikan. Tapi kami henteu lirén di dinya-sajajar, kami ngaoptimalkeun laju cék pikeun mindahkeun éta tina mode wengi pikeun narik cék pamundut.

Dina waktos éta, sadaya wangunan urang réngsé rada gancang, jadi urang ngan kaasup wangunan ARK, tés Junit jeung itungan sinyalna kode salaku blocker pikeun pamundut tarikan. Urang dihurungkeun, dipikirkeun, sareng ngantunkeun sinyalna kode sabab urang ngira yén urang henteu peryogi éta.

Butuh waktu dua poé pikeun sakabéhna nyetél CI dasar (hereinafter estimasi waktu nyaeta perkiraan, diperlukeun pikeun skala).

Saatos éta, urang mimiti mikir deui - naha urang mariksa leres? Urang ngajalankeun ngawangun on requests tarikan leres?

Urang mimitian ngawangun dina komitmen panungtungan sahiji cabang ti mana pamundut tarikan dibuka. Tapi tés komitmen ieu ngan ukur tiasa nunjukkeun yén kode anu ditulis ku pamekar tiasa dianggo. Tapi aranjeunna henteu ngabuktikeun yén anjeunna henteu ngalanggar nanaon. Nyatana, anjeun kedah pariksa kaayaan cabang ngembangkeun saatos fitur dihijikeun kana éta.

Jang ngalampahkeun ieu, urang nulis skrip bash basajan premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Di dieu sagala parobihan panganyarna tina pamekaran ngan saukur ditarik sareng dihijikeun kana cabang anu ayeuna. Urang ditambahkeun skrip premerge.sh salaku hambalan kahiji dina sakabéh ngawangun sarta mimiti pariksa kahayang urang hayang, nyaeta integrasi.

Butuh tilu dinten pikeun ngalokalkeun masalah, milarian solusi, sareng nyerat naskah ieu.

Aplikasi dimekarkeun, beuki loba tugas mucunghul, tim tumuwuh, sarta premerge.sh kadang mimiti hayu urang handap. Ngembangkeun ngagaduhan parobihan anu bertentangan anu ngarobih ngawangun.

Hiji conto kumaha ieu kajadian:

Dua pamekar sakaligus ngamimitian ngerjakeun fitur A sareng B. Pamekar fitur A mendakan fitur anu henteu dianggo dina proyék. answer() jeung, kawas budak pramuka alus, ngaluarkeun eta. Dina waktos anu sami, pamekar fitur B nambihan telepon énggal kana fungsi ieu dina cabangna.

Pamekar rengse karya maranéhanana sarta muka pamundut tarikan dina waktos anu sareng. Pangwangunan diluncurkeun, premerge.sh pariksa duanana pamenta tarik ngeunaan kaayaan pangembangan pang anyarna - sadayana cek héjo. Saatos éta, pamundut tarik fitur A dihijikeun, pamundut tarik fitur B dihijikeun ... Boom! Ngembangkeun ngarecah sabab kode ngamekarkeun ngandung panggero ka fungsi non-existent.

Nalika éta henteu badé ngembangkeun, éta musibah lokal. Sakabeh tim teu bisa ngumpulkeun nanaon jeung ngirimkeunana pikeun nguji.

Ieu jadi kajadian nu kuring paling sering dipake dina tugas infrastruktur: analytics, jaringan, database. Nyaéta, kuring anu nyerat éta fungsi sareng kelas anu dianggo ku pamekar anu sanés. Kusabab ieu, kuring sering pisan dina kaayaan anu sami. Kuring malah kungsi gambar ieu nongkrong bari.

Kusabab ieu henteu cocog sareng kami, kami mimiti ngajalajah pilihan kumaha cara nyegah ieu.

Kumaha teu megatkeun ngamekarkeun

pilihan kahiji: ngawangun deui sagala requests tarikan nalika ngamutahirkeun ngamekarkeun. Upami, dina conto urang, pamenta tarikan sareng fitur A mangrupikeun anu munggaran dilebetkeun kana pamekaran, pamenta tarikan fitur B bakal diwangun deui, sareng, sasuai, cék bakal gagal kusabab kasalahan kompilasi.

Ngartos sabaraha lila ieu bakal nyandak, mertimbangkeun conto dua PRs. Urang muka dua PRs: dua ngawangun, dua ngajalankeun cék. Saatos PR munggaran dihijikeun kana ngembangkeun, anu kadua kedah diwangun deui. Dina total, dua PRs merlukeun tilu ngajalankeun cék: 2 + 1 = 3.

Sacara prinsip, éta henteu kunanaon. Tapi urang nempo statistik, sarta kaayaan has di tim kami éta 10 PRs kabuka, lajeng jumlah cék téh jumlah progression: 10 + 9 + ... + 1 = 55. Hartina, pikeun nampa 10. PRs, anjeun kedah ngawangun deui 55 kali. Sareng ieu dina kaayaan anu idéal, nalika sadaya cék pas pertama kalina, nalika teu aya anu muka pamundut tarik tambahan nalika belasan ieu diolah.

Bayangkeun diri anjeun salaku pamekar anu kedah janten anu pangheulana ngaklik tombol "ngahiji", sabab upami tatangga ngalakukeun ieu, maka anjeun kedah ngantosan dugi ka sadaya gedong ngalangkungan deui ... Henteu, éta moal jalan. , éta serius bakal ngalambatkeun pangwangunan.

Cara kadua mungkin: ngumpulkeun requests tarikan sanggeus review kode. Nyaéta, anjeun muka pamundut tarik, ngumpulkeun jumlah persetujuan anu diperyogikeun ti kolega, ngabenerkeun naon anu diperyogikeun, teras ngaluncurkeun ngawangun. Mun aranjeunna suksés, pamundut tarikan ieu dihijikeun kana ngamekarkeun. Dina hal ieu, teu aya restart tambahan, tapi eupan balikna kalem pisan. Salaku pamekar, nalika kuring muka pamundut tarik, kuring langsung hoyong ningali upami éta bakal jalan. Salaku conto, upami tés gagal, anjeun kedah gancang ngalereskeunana. Dina kasus hiji ngawangun nyangsang, eupan balik slows turun, sarta ku kituna sakabéh pangwangunan. Ieu ogé henteu cocog sareng urang.

Hasilna, ngan pilihan katilu tetep - sapédah. Sadaya kode kami, sadaya sumber kami disimpen dina gudang dina server Bitbucket. Sasuai, urang kedah ngembangkeun plugin pikeun Bitbucket.

Plugin ieu nimpa mékanisme ngahijikeun paménta tarik. Mimitina standar: PR dibuka, sadaya majelis diluncurkeun, ulasan kode parantos réngsé. Tapi sanggeus review kode geus réngsé sarta pamekar megatkeun pikeun klik "ngagabung", cék plugin ngalawan nu ngembangkeun kaayaan cék éta ngajalankeun. Upami pamekar parantos diénggalan saatos ngawangun, plugin moal ngijinkeun pamundut tarik sapertos kitu dihijikeun kana cabang utama. Éta ngan saukur bakal ngamimitian deui ngawangun pangwangunan anu kawilang anyar.

Dina conto urang sareng parobihan anu bertentangan, ngawangun sapertos kitu bakal gagal kusabab kasalahan kompilasi. Sasuai, pamekar fitur B kedah ngabenerkeun kodeu, balikan deui cék, teras plugin bakal otomatis nerapkeun pamundut tarik.

Sateuacan nerapkeun plugin ieu, urang rata-rata 2,7 review ngajalankeun per pamundut tarikan. Kalayan plugin éta aya 3,6 peluncuran. Ieu cocog kami.

Perlu dicatet yén plugin ieu ngagaduhan kakurangan: éta ngan ukur ngamimitian deui ngawangun sakali. Hartina, aya kénéh jandela leutik ngaliwatan nu parobahan conflicting bisa meunang kana ngamekarkeun. Tapi kamungkinan ieu rendah, sareng kami ngadamel perdagangan ieu antara jumlah ngamimitian sareng kamungkinan gagal. Dina dua taun éta ukur dipecat sakali, jadi ieu meureun moal sia.

Butuh waktu dua minggu pikeun nulis versi munggaran tina plugin Bitbucket.

cék anyar

Samentara éta, tim kami terus tumuwuh. cék anyar geus ditambahkeun.

Urang panginten: naha ngalakukeun kasalahan upami aranjeunna tiasa dicegah? Jeung éta naha maranéhna dilaksanakeun analisis kode statik. Urang mimitian ku lint, nu kaasup dina Android SDK. Tapi dina waktos éta anjeunna henteu terang kumaha damel sareng kode Kotlin, sareng urang parantos ngagaduhan 75% tina aplikasi anu ditulis dina Kotlin. Ku alatan éta, anu diwangun-di ditambahkeun kana lint cék Android Studio.

Jang ngalampahkeun ieu, urang kudu ngalakukeun loba perverting: nyandak Android Studio, bungkusan eta di Docker tur ngajalankeun eta dina CI kalawan monitor virtual, jadi eta nyangka eta ngajalankeun dina laptop nyata. Tapi éta hasil.

Dina waktos ieu ogé urang mimiti nulis pisan tés instrumentasi sarta dilaksanakeun nguji screenshot. Ieu nalika screenshot rujukan dihasilkeun pikeun pintonan leutik misah, sarta tés diwangun ku nyokot screenshot ti tempoan tur ngabandingkeun éta kalayan standar langsung piksel ku piksel. Upami aya panyimpangan, éta hartosna perenahna parantos salah dimana waé atanapi aya anu salah dina gaya.

Tapi tés instrumentasi sareng tés layar kedah dijalankeun dina alat: dina émulator atanapi dina alat nyata. Nganggap yén aya seueur tes sareng aranjeunna sering dijalankeun, sadayana tegalan diperyogikeun. Ngamimitian tegalan anjeun nyalira teuing padat karya, janten kami mendakan pilihan anu siap - Firebase Test Lab.

Firebase Test Lab

Éta dipilih sabab Firebase mangrupikeun produk Google, hartosna éta kedah dipercaya sareng henteu mungkin maot. Hargana lumrah: $5 per jam operasi alat nyata, 1 $ per jam operasi émulator.

Butuh kira-kira tilu minggu pikeun nerapkeun Firebase Test Lab kana CI kami.

Tapi tim terus tumuwuh, sarta Firebase, hanjakalna, mimiti ngantep kami handap. Dina waktos éta, anjeunna henteu ngagaduhan SLA. Kadang-kadang Firebase ngajantenkeun urang ngantosan dugi ka jumlah alat anu diperyogikeun gratis pikeun tés, sareng henteu langsung ngalaksanakeunana, sakumaha anu dipikahoyong. Antosan dugi ka satengah jam, waktos anu lami pisan. Tés instrumentasi dijalankeun dina unggal PR, telat leres-leres ngalambatkeun pangwangunan, teras tagihan bulanan sumping kalayan jumlah buleud. Sacara umum, ieu mutuskeun pikeun abandon Firebase sarta digawé di-imah, saprak tim geus cukup tumuwuh.

Docker + Python + bash

Simkuring nyandak Docker, boneka emulators kana eta, wrote program basajan dina Python, nu dina momen katuhu brings up jumlah diperlukeun tina emulators dina versi diperlukeun tur eureun aranjeunna lamun perlu. Sareng, tangtosna, sababaraha skrip bash - dimana urang tanpa aranjeunna?

Butuh waktu lima minggu pikeun nyiptakeun lingkungan tés urang sorangan.

Hasilna, pikeun unggal pamundut tarik aya daptar éksténsif ngagabung-blocking tina cék:

• Majelis ARK;
• tés Junit;
• Lint;
• cék Android Studio;
• Tés instrumentasi;
• Tés screenshot.

Ieu nyegah loba mungkin breakdowns. Téhnisna sagalana digawé, tapi pamekar humandeuar yén antosan hasilna panjang teuing.

Sabaraha lami teuing? Kami unggah data tina Bitbucket sareng TeamCity kana sistem analisa sareng sadar éta waktos ngantosan rata 45 menit. Nyaéta, pamekar, nalika muka pamundut tarik, ngantosan rata-rata 45 menit kanggo hasil ngawangun. Dina pamadegan mah, ieu loba, jeung anjeun teu tiasa dianggo kawas éta.

Tangtosna, urang mutuskeun pikeun nyepetkeun sadayana ngawangun.

Hayu urang gancangan

Ningali yén ngawangun sering nangtung dina antrian, hal kahiji anu urang lakukeun nyaéta meuli hardware leuwih - ngembangkeun éksténsif nyaéta pangbasajanna. Ngawangun dieureunkeun antrian, tapi waktu nungguan turun ngan saeutik, sabab sababaraha cék sorangan nyandak waktu anu pohara lila.

Nyoplokkeun cék nu lila teuing

Integrasi Kontinyu kami tiasa nangkep jinis kasalahan sareng masalah ieu.

• Henteu bade. CI bisa nyekel kasalahan kompilasi lamun hal teu ngawangun alatan parobahan conflicting. Sakumaha anu kuring parantos nyarios, maka teu aya anu tiasa ngumpul naon waé, pamekaran lirén, sareng sadayana gugup.
• Bug dina kabiasaan. Contona, nalika aplikasi diwangun, tapi ngadat mun anjeun mencet tombol, atawa tombol teu dipencet pisan. Ieu goréng sabab kutu sapertos kitu tiasa ngahontal pangguna.
• Bug dina perenah. Contona, hiji tombol diklik, tapi geus dipindahkeun 10 piksel ka kénca.
• Kanaékan hutang teknis.

Saatos ningali daptar ieu, urang sadar yén ngan ukur dua titik anu kritis. Urang rék nyekel masalah sapertos munggaran. Bug dina perenah kapanggih dina tahap desain-review sarta bisa gampang dilereskeun lajeng. Nungkulan hutang teknis merlukeun prosés jeung tata misah, sangkan mutuskeun teu nguji éta dina pamundut tarikan.

Dumasar klasifikasi ieu, urang ngoyagkeun sakabéh daptar cék. Ngaliwatan Lint sarta ditunda peluncuran na sapeuting: ngan ku kituna bakal ngahasilkeun laporan ngeunaan sabaraha masalah aya dina proyék. Urang sapuk pikeun digawé misah jeung hutang teknis, jeung Pamariksaan Android Studio parantos ditinggalkeun. Studio Android di Docker pikeun ngajalankeun pamariksaan sigana pikaresepeun, tapi nyababkeun seueur masalah dina dukungan. Pembaruan naon waé pikeun versi Android Studio hartosna perjuangan sareng bug anu teu kaharti. Éta ogé hésé ngadukung tés layar, sabab perpustakaan henteu stabil pisan sareng aya positip palsu. Tés tangkapan layar parantos dipiceun tina daptar pariksa.

Hasilna, urang ditinggalkeun ku:

• Majelis ARK;
• tés Junit;
• Tés instrumentasi.

Gradle cache jauh

Tanpa dipariksa beurat, sagalana janten hadé. Tapi teu aya watesna pikeun kasampurnaan!

Aplikasi kami parantos dibagi kana 150 modul gradle. Gradle jauh cache biasana jalan ogé dina hal ieu, sangkan mutuskeun pikeun nyobaan eta.

Gradle jauh cache nyaéta layanan nu bisa cache ngawangun artefak pikeun tugas individu dina modul individu. Gradle, tinimbang sabenerna nyusun kode, ngagunakeun HTTP pikeun sambel dina cache jauh jeung nanya lamun batur geus dipigawé tugas ieu. Upami enya, éta ngan ukur ngaunduh hasilna.

Ngajalankeun cache jauh Gradle gampang sabab Gradle nyayogikeun gambar Docker. Urang junun ngalakukeun ieu dina tilu jam.

Sadaya anu anjeun kedah laksanakeun nyaéta ngaluncurkeun Docker sareng nyerat hiji garis dina proyék éta. Tapi sanaos tiasa diluncurkeun gancang, éta bakal peryogi seueur waktos kanggo sadayana tiasa dianggo kalayan saé.

Di handap ieu cache misses grafik.

Di awal, persentase cache misses éta ngeunaan 65. Sanggeus tilu minggu, urang junun ningkatkeun nilai ieu 20%. Tétéla yén tugas anu dikumpulkeun ku aplikasi Android gaduh katergantungan transitif anu aneh, ku sabab éta Gradle sono kana cache.

Ku cara nyambungkeun cache, urang greatly speeded up ngawangun. Tapi salian assembly, aya ogé tés instrumentation, sarta maranéhna butuh waktu lila. Panginten henteu sadayana tés kedah dijalankeun pikeun unggal pamundut tarik. Pikeun manggihan, urang ngagunakeun analisis dampak.

Analisis dampak

Dina pamundut tarikan, urang ngumpulkeun git diff sarta manggihan modul Gradle dirobah.

Masuk akal pikeun ukur ngajalankeun tés instrumentasi anu mariksa modul anu dirobih sareng sadaya modul anu gumantung kana éta. Teu aya gunana pikeun ngajalankeun tés pikeun modul tatangga: kodeu di dinya henteu robih sareng teu aya anu tiasa dirobih.

Tés instrumentasi henteu saderhana pisan, sabab kedah aya dina modul Aplikasi tingkat luhur. Kami nganggo heuristik sareng analisis bytecode pikeun ngartos modul mana masing-masing tés.

Ngaronjatkeun operasi tés instrumentasi supados aranjeunna ngan ukur nguji modul anu aub nyandak sakitar dalapan minggu.

Ukuran pikeun nyepetkeun pamariksaan parantos suksés. Ti 45 menit urang indit nepi ka ngeunaan 15. Ieu geus normal antosan saparapat jam pikeun ngawangun.

Tapi ayeuna pamekar geus mimiti ngawadul yén maranéhna teu ngarti nu ngawangun keur diluncurkeun, dimana ningali log, naha wangunanna beureum, nu test gagal, jsb.

Masalah sareng eupan balik ngalambatkeun pangwangunan, janten kami nyobian nyayogikeun inpormasi anu jelas sareng detil ngeunaan unggal PR sareng ngawangun sabisa. Urang mimitian ku koméntar dina Bitbucket ka PR, nunjukkeun wangunan mana anu gagal sareng kunaon, sareng nyerat pesen anu dituju dina Slack. Tungtungna, kami nyiptakeun dasbor PR pikeun halaman kalayan daptar sadaya wangunan anu ayeuna dijalankeun sareng statusna: antrian, jalan, nabrak atanapi réngsé. Anjeun tiasa klik dina ngawangun tur meunangkeun log na.

Genep minggu dihabiskeun dina eupan balik lengkep.

Rencana

Hayu urang ngaléngkah ka sajarah panganyarna. Saatos ngabéréskeun masalah eupan balik, kami ngahontal tingkat anyar - kami mutuskeun pikeun ngawangun kebon émulator sorangan. Nalika aya seueur tés sareng émulator, aranjeunna sesah diurus. Hasilna, sadaya émulator urang dipindahkeun ka k8s kluster jeung manajemén sumberdaya fléksibel.

Sajaba ti éta, aya rencana séjén.

• Balik Lint (jeung analisis statik séjén). Kami parantos damel di arah ieu.
• Jalankeun sadayana dina pameungpeuk PR tés tungtung-to-tungtung dina sadaya vérsi SDK.

Janten, kami parantos ngalacak sajarah pangembangan Integrasi Kontinyu di Avito. Ayeuna abdi hoyong masihan sababaraha saran ti sudut pandang ngalaman.

tips

Upami kuring tiasa masihan ngan ukur hiji naséhat, éta bakal kieu:

Punten ati-ati nganggo naskah cangkang!

Bash mangrupikeun alat anu fleksibel sareng kuat, gampang pisan sareng gancang nyerat naskah. Tapi anjeun bisa digolongkeun kana bubu jeung eta, jeung, hanjakalna, urang murag kana eta.

Éta sadayana dimimitian ku skrip saderhana anu dijalankeun dina mesin ngawangun kami:

#!/usr/bin/env bash
./gradlew assembleDebug

Tapi, sakumaha anu anjeun terang, sadayana berkembang sareng janten langkung pajeulit kana waktosna - hayu urang ngajalankeun hiji naskah ti anu sanés, hayu urang lulus sababaraha parameter di dinya - tungtungna urang kedah nyerat fungsi anu nangtukeun dina tingkat naon bash nyarang urang ayeuna dina urutan. pikeun nyelapkeun tanda petik perlu, pikeun meunangkeun eta sadayana dimimitian.

Anjeun tiasa ngabayangkeun biaya tanaga gawé pikeun ngembangkeun naskah sapertos. Kuring mamatahan anjeun ulah digolongkeun kana bubu ieu.

Naon anu bisa diganti?

• Sakur basa skrip. Tulis ka Python atanapi Kotlin Script leuwih merenah sabab éta programming, teu naskah.
• Atawa ngajelaskeun sakabeh logika ngawangun dina formulir Tugas gradle custom pikeun proyék Anjeun.

Kami mutuskeun pikeun milih pilihan kadua, sareng ayeuna urang sacara sistematis ngahapus sadaya skrip bash sareng nyerat seueur tugas gradle khusus.

Tip #2: Toko infrastruktur dina kode.

Éta merenah nalika setelan Pamaduan Kontinyu disimpen teu di panganteur UI of Jenkins atanapi TeamCity, jeung sajabana, tapi dina bentuk file téks langsung dina gudang proyék. Ieu méré versionability. Moal sesah ngagulung deui atanapi ngawangun kodeu dina cabang anu sanés.

Skrip tiasa disimpen dina proyék. Naon anu kudu dipigawé kalayan lingkungan?

Tip #3: Docker tiasa ngabantosan lingkungan.

Pasti bakal ngabantosan pamekar Android; ios teu acan gaduh, hanjakalna.

Ieu mangrupikeun conto file docker saderhana anu ngandung jdk sareng android-sdk:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

Saatos nyerat file Docker ieu (Abdi bakal nyarioskeun rusiah anjeun, anjeun henteu kedah nyeratna, tapi ngan tarik éta siap-dijieun tina GitHub) sareng ngumpul gambarna, anjeun kéngingkeun mesin virtual dimana anjeun tiasa ngawangun aplikasi. tur ngajalankeun tés Junit.

Dua alesan utama naha ieu masuk akal nyaéta skalabilitas sareng kabisaulangan. Nganggo docker, anjeun tiasa gancang ngangkat belasan agén ngawangun anu bakal gaduh lingkungan anu sami sareng anu sateuacana. Ieu ngagampangkeun kahirupan insinyur CI. Ieu rada gampang pikeun nyorong android-sdk kana docker, tapi kalawan émulators éta saeutik leuwih hese: anjeun bakal kudu gawé saeutik harder (atawa ngundeur rengse ti GitHub deui).

Tip No 4: ulah hilap yén pamariksaan henteu dilakukeun pikeun pamariksaan, tapi pikeun jalma.

Gancang tur, paling importantly, eupan balik jelas pohara penting pikeun pamekar: naon peupeus, naon test gagal, dimana abdi tiasa ningali buildlog nu.

Tip #5: Janten pragmatis nalika ngamekarkeun Integrasi Kontinyu.

Jelas ngartos jinis kasalahan naon anu anjeun hoyong cegah, sabaraha sumber daya, waktos, sareng waktos komputer anu anjeun badé nyéépkeun. Cék anu panjang teuing tiasa, contona, ditunda sapeuting. Sareng di antarana anu nyekel kasalahan anu henteu penting pisan kedah dileungitkeun.

Tip #6: Paké parabot siap-dijieun.

Aya seueur perusahaan ayeuna anu nyayogikeun awan CI.

Ieu leyuran alus keur tim leutik. Anjeun teu kedah ngadukung nanaon, cukup mayar sakedik artos, ngawangun aplikasi anjeun sareng bahkan ngajalankeun tés instrumentasi.

Tip #7: Dina tim ageung, solusi in-house langkung nguntungkeun.

Tapi engké atanapi engké, nalika tim tumuwuh, solusi in-house bakal langkung nguntungkeun. Aya hiji masalah sareng kaputusan ieu. Aya hukum diminishing mulih dina ékonomi: dina proyék mana wae, unggal perbaikan saterusna beuki hese sarta merlukeun beuki loba investasi.

Ékonomi ngajelaskeun sakabéh kahirupan urang, kaasup Integrasi Kontinyu. Kuring ngawangun jadwal biaya tanaga gawé pikeun tiap tahapan ngembangkeun Integrasi Kontinyu kami.

Éta jelas yén perbaikan naon waé janten langkung sesah. Ningali grafik ieu, anjeun tiasa ngartos yén Integrasi Kontinyu kedah dikembangkeun saluyu sareng kamekaran ukuran tim. Pikeun tim dua jalma, méakkeun 50 poé ngembangkeun hiji tegalan émulator internal mangrupakeun ide biasa. Tapi dina waktos anu sami, pikeun tim anu ageung, henteu ngalakukeun Integrasi Kontinyu ogé mangrupikeun ide anu goréng, sabab masalah integrasi, ngalereskeun komunikasi, jsb. eta bakal butuh malah leuwih waktos.

Urang mimitian ku gagasan yén automation diperlukeun sabab jalma anu mahal, maranéhna nyieun kasalahan jeung puguh. Tapi jalma ogé ngajadikeun otomatis. Ku alatan éta, sagala masalah anu sarua dilarapkeun ka automation.

• Otomasi mahal. Inget jadwal kuli.
• Lamun datang ka automation, jalma nyieun kasalahan.
• Kadangkala kacida puguh pikeun ngajadikeun otomatis, sabab sagalana jalan cara éta. Naha ningkatkeun naon waé, naha sadayana Integrasi Kontinyu ieu?

Tapi kuring boga statistik: kasalahan nu bray dina 20% tina rakitan. Sareng ieu sanés kusabab pamekar urang nyerat kode anu kirang. Ieu kusabab pamekar anu yakin yén lamun maranéhna nyieun sababaraha kasalahan, eta moal mungkas nepi di ngembangkeun, éta bakal bray ku cék otomatis. Sasuai, pamekar bisa méakkeun leuwih waktos nulis kode jeung hal metot, tinimbang ngajalankeun sarta nguji hal lokal.

Praktek Integrasi Kontinyu. Tapi dina moderation.

Ku jalan kitu, Nikolai Nesterov teu ukur masihan dirina laporan hébat, tapi ogé mangrupa anggota panitia program AppsConf tur mantuan batur nyiapkeun pidato bermakna pikeun anjeun. The completeness tur mangpaat tina program konferensi salajengna bisa ditaksir ku jejer dina jadwal. Sareng pikeun detil, sumping ka Infospace tanggal 22-23 April.

sumber: www.habr.com