Saiki, umume produk piranti lunak dikembangake ing tim. Kahanan kanggo pangembangan tim sing sukses bisa diwakili ing bentuk diagram sing prasaja.

Sawise sampeyan nulis kode sampeyan, sampeyan kudu nggawe manawa:

1. nyambut gawe.
2. Ora ngrusak apa-apa, kalebu kode sing ditulis kolega sampeyan.

Yen loro kondisi wis ketemu, sampeyan ana ing dalan kanggo sukses. Kanggo gampang mriksa kahanan kasebut lan ora nyimpang saka dalan sing nguntungake, kita teka karo Integrasi Terus-terusan.

CI minangka alur kerja ing ngendi sampeyan nggabungake kode menyang kode produk sakabèhé sabisa-bisa. Lan sampeyan ora mung nggabungake, nanging uga priksa manawa kabeh bisa digunakake. Amarga sampeyan kudu mriksa akeh lan asring, sampeyan kudu mikir babagan otomatisasi. Sampeyan bisa mriksa kabeh kanthi manual, nanging sampeyan ora kudu, lan kene sebabe.

• Wong sing ditresnani. Jam kerja programmer apa wae luwih larang tinimbang jam kerja ing server apa wae.
• Wong nggawe kesalahan. Mula, kahanan bisa uga kedadeyan nalika tes ditindakake ing cabang sing salah utawa komitmen sing salah dikompilasi kanggo penguji.
• Wong kesed. Saka wektu kanggo wektu, nalika rampung tugas, pikiran muncul: "Apa sing kudu dipriksa? Aku nulis rong baris - kabeh bisa digunakake! Aku sawetara saka sampeyan uga kadhangkala duwe pikiran kaya. Nanging sampeyan kudu tansah mriksa.

Kepiye Integrasi Terus-terusan dileksanakake lan dikembangake ing tim pangembangan seluler Avito, kepiye carane saka 0 nganti 450 mbangun saben dina, lan mesin sing nggawe ngumpul 200 jam saben dina, ujare Nikolai Nesterov (nnesterov) minangka peserta ing kabeh owah-owahan evolusi aplikasi CI/CD Android.

Crita kasebut adhedhasar conto perintah Android, nanging umume pendekatan kasebut uga ditrapake ing iOS.

Biyen, siji wong kerja ing tim Android Avito. Miturut definisi, dheweke ora butuh apa-apa saka Integrasi Terus-terusan: ora ana sing bisa nggabungake.

Nanging aplikasi kasebut saya tambah akeh, luwih akeh tugas anyar muncul, lan tim saya tambah akeh. Ing sawetara titik, wektune kanggo nggawe proses integrasi kode kanthi luwih resmi. Diputusake nggunakake aliran Git.

Konsep aliran Git dikenal: proyek duwe siji cabang berkembang sing umum, lan kanggo saben fitur anyar, pangembang ngethok cabang sing kapisah, setya, push, lan nalika pengin nggabungake kode menyang cabang berkembang, mbukak panjaluk narik. Kanggo nuduhake kawruh lan ngrembug pendekatan, kita ngenalake review kode, yaiku, kolega kudu mriksa lan konfirmasi kode saben liyane.

Priksa

Ndelok kode karo mripatmu kelangan, nanging ora cukup. Mulane, mriksa otomatis lagi ngenalaken.

• Kaping pisanan, kita mriksa Majelis ARK.
• Akeh Tes Junit.
• Kita nimbang jangkoan kode, amarga kita lagi nganakake tes.

Kanggo ngerti carane mriksa iki kudu mbukak, ayo kang katon ing proses pembangunan ing Avito.

Bisa diwakili kanthi skema kaya iki:

• Pangembang nulis kode ing laptop. Sampeyan bisa nindakake mriksa integrasi ing kene - kanthi pancing komit, utawa mung mriksa ing latar mburi.
• Sawise pangembang wis push kode, mbukak panjalukan narik. Supaya kode kasebut bisa dilebokake ing cabang berkembang, perlu kanggo mriksa kode lan ngumpulake jumlah konfirmasi sing dibutuhake. Sampeyan bisa ngaktifake mriksa lan mbangun ing kene: nganti kabeh mbangun sukses, panjalukan tarik ora bisa digabung.
• Sawise panjalukan narik digabungake lan kode kasebut kalebu ing ngembangake, sampeyan bisa milih wektu sing trep: umpamane, ing wayah wengi, nalika kabeh server gratis, lan mbukak akeh mriksa sing dikarepake.

Ora ana sing seneng mindai ing laptop. Nalika pangembang wis rampung fitur, dheweke pengin cepet push lan mbukak panjalukan narik. Yen ing wayahe sawetara kir dawa dibukak, iki ora mung ora banget penake, nanging uga slows mudhun pembangunan: nalika laptop mriksa soko, iku mokal kanggo bisa normal.

Kita pancene disenengi mlaku mriksa ing wayah wengi, amarga ana akeh wektu lan server, sampeyan bisa roam watara. Nanging, sayangé, nalika kode fitur berkembang, pangembang kurang motivasi kanggo ndandani kesalahan sing ditemokake CI. Aku periodik kejiret aku mikir nalika aku katon ing kabeh kasalahan ketemu ing laporan esuk sing aku bakal ndandani mau mengko, amarga saiki ana tugas anyar kelangan ing Jira aku mung arep kanggo miwiti.

Yen mriksa mblokir panjalukan tarik, banjur ana cukup motivasi, amarga nganti mbangun dadi ijo, kode ora bakal berkembang, tegese tugas ora bakal rampung.

Akibaté, kita milih strategi ing ngisor iki: kita mbukak pesawat maksimum bisa mriksa ing wayah wengi, lan miwiti paling kritis mau lan, paling Jahwéh, paling cepet ing request narik. Nanging kita ora mandheg ing kono-sejajar, kita ngoptimalake kacepetan mriksa supaya bisa nransfer saka mode wengi kanggo narik priksa panjaluk.

Ing wektu iku, kabeh mbangun kita rampung cukup cepet, supaya kita mung kalebu mbangun ARK, tes Junit lan petungan jangkoan kode minangka blocker kanggo panjalukan narik. Kita nguripake, mikir babagan iki, lan nilar jangkoan kode amarga kita mikir yen kita ora perlu.

Kita butuh rong dina kanggo nyiyapake CI dhasar kanthi lengkap (sawise perkiraan wektu kira-kira, dibutuhake kanggo skala).

Sawise iku, kita wiwit mikir luwih lanjut - apa kita mriksa kanthi bener? Apa kita mlaku mbangun panjaluk narik kanthi bener?

Kita miwiti mbangun ing komit pungkasan cabang saka panyuwunan narik dibukak. Nanging tes komitmen iki mung bisa nuduhake yen kode sing ditulis pangembang bisa digunakake. Nanging dheweke ora mbuktekake manawa dheweke ora nglanggar apa-apa. Nyatane, sampeyan kudu mriksa kahanan cabang berkembang sawise fitur kasebut digabungake.

Kanggo nindakake iki, kita nulis skrip bash sing prasaja premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Ing kene kabeh owah-owahan paling anyar saka berkembang mung ditarik munggah lan digabung menyang cabang saiki. Kita nambahake skrip premerge.sh minangka langkah pisanan ing kabeh bangunan lan wiwit mriksa persis apa sing dikarepake, yaiku integrasi.

Butuh telung dina kanggo lokalake masalah, golek solusi, lan nulis skrip iki.

Aplikasi dikembangake, akeh tugas sing muncul, tim saya tambah akeh, lan premerge.sh kadhangkala wiwit nguciwani kita. Ngembangake duwe owah-owahan sing bertentangan sing ngrusak bangunan kasebut.

Conto carane iki kedadeyan:

Loro pangembang bebarengan miwiti nggarap fitur A lan B. Pangembang fitur A nemokake fitur sing ora digunakake ing proyek kasebut answer() lan, kaya pramuka lanang apik, mbusak. Ing wektu sing padha, pangembang fitur B nambah telpon anyar kanggo fungsi iki ing cabang.

Pangembang rampung karya lan mbukak panjalukan narik ing wektu sing padha. Dibangun diluncurake, premerge.sh mriksa loro panjaluk narik babagan negara berkembang paling anyar - kabeh mriksa ijo. Sawise iku, panjaluk tarik fitur A digabung, panjaluk tarik fitur B digabung ... Boom! Ngembangake break amarga kode ngembangake ngemot panggilan menyang fungsi sing ora ana.

Nalika iku ora arep kanggo berkembang, iku bencana lokal. Kabeh tim ora bisa ngumpulake apa-apa lan ngirim kanggo testing.

Kedaden aku paling kerep nggarap tugas infrastruktur: analytics, jaringan, database. Yaiku, aku sing nulis fungsi lan kelas kasebut sing digunakake pangembang liyane. Amarga iki, aku kerep nemoni kahanan sing padha. Aku malah duwe gambar iki hanging kanggo nalika.

Amarga iki ora cocog karo kita, kita wiwit njelajah pilihan babagan carane nyegah iki.

Carane ora break berkembang

Pilihan kapisan: mbangun maneh kabeh panjalukan narik nalika nganyari berkembang. Yen, ing conto kita, panjalukan tarik kanthi fitur A minangka sing pertama dilebokake ing pangembangan, panjaluk tarik fitur B bakal dibangun maneh, lan, kanthi mangkono, pamriksa bakal gagal amarga kesalahan kompilasi.

Kanggo mangerteni suwene iki bakal njupuk, nimbang conto karo loro PRs. Kita mbukak rong PR: loro mbangun, loro mriksa. Sawise PR pisanan digabung dadi berkembang, sing kapindho kudu dibangun maneh. Secara total, rong PR mbutuhake telung pemeriksaan: 2 + 1 = 3.

Ing asas, iku apik. Nanging kita katon ing statistik, lan kahanan khas ing tim kita ana 10 PR mbukak, lan banjur nomer mriksa iku jumlah saka kemajuan: 10 + 9 +... + 1 = 55. Yaiku, kanggo nampa 10. PRs, sampeyan kudu mbangun maneh 55 kaping. Lan iki ing kahanan becik, nalika kabeh mriksa pass pisanan, nalika ora ana siji mbukak panjalukan narik tambahan nalika rolas iki lagi diproses.

Mbayangno sampeyan minangka pangembang sing kudu dadi sing pertama ngeklik tombol "gabung", amarga yen pepadhamu nindakake iki, sampeyan kudu ngenteni nganti kabeh bangunan kasebut bali maneh ... Ora, ora bakal bisa. , iku bakal alon mudhun pembangunan.

Cara kapindho bisa: ngumpulake panjalukan narik sawise review kode. Yaiku, sampeyan mbukak panjaluk tarik, ngumpulake jumlah persetujuan sing dibutuhake saka kolega, mbenerake apa sing dibutuhake, banjur miwiti mbangun. Yen padha sukses, panjalukan narik digabung dadi berkembang. Ing kasus iki, ora ana restart tambahan, nanging umpan balik kalem banget. Minangka pangembang, nalika aku mbukak panjalukan narik, aku langsung pengin ndeleng apa iku bakal bisa. Contone, yen tes gagal, sampeyan kudu ndandani kanthi cepet. Ing cilik saka mbangun telat, umpan balik slows mudhun, lan mulane kabeh pembangunan. Iki uga ora cocog karo kita.

Akibaté, mung pilihan katelu tetep - pit. Kabeh kode kita, kabeh sumber kita disimpen ing repositori ing server Bitbucket. Dadi, kita kudu nggawe plugin kanggo Bitbucket.

Plugin iki ngatasi mekanisme penggabungan panjaluk tarik. Wiwitane standar: PR mbukak, kabeh majelis diluncurake, review kode wis rampung. Nanging sawise review kode rampung lan pangembang mutusake kanggo ngeklik "gabung", plugin mriksa sing negara berkembang mriksa kasebut ditindakake. Yen pangembangan wis dianyari sawise mbangun, plugin ora bakal ngidini panjaluk narik kasebut digabung menyang cabang utama. Iku mung bakal miwiti maneh mbangun pembangunan relatif anyar.

Ing conto kita kanthi owah-owahan sing bertentangan, mbangun kasebut bakal gagal amarga kesalahan kompilasi. Mulane, pangembang fitur B kudu mbenerake kode kasebut, miwiti maneh mriksa, banjur plugin bakal kanthi otomatis ngetrapake panjaluk tarik kasebut.

Sadurunge ngleksanakake plugin iki, kita rata-rata 2,7 review mlaku saben panjaluk narik. Kanthi plugin kasebut ana 3,6 diluncurake. Iki cocog karo kita.

Wigati dimangerteni manawa plugin iki duwe kekurangan: mung miwiti maneh mbangun sapisan. Tegese, isih ana jendhela cilik sing bisa berkembang owah-owahan sing bertentangan. Nanging kemungkinan iki kurang, lan kita nggawe perdagangan iki antarane jumlah wiwitan lan kemungkinan gagal. Ing rong taun iku mung murub sapisan, dadi mbokmenawa ora muspra.

Kita butuh rong minggu kanggo nulis versi pisanan saka plugin Bitbucket.

Cek anyar

Kangge, tim kita terus berkembang. Priksa anyar wis ditambahake.

Kita mikir: kenapa nggawe kesalahan yen bisa dicegah? Lan mulane padha dileksanakake analisis kode statis. Kita miwiti karo lint, sing kalebu ing Android SDK. Nanging ing wektu iku dheweke ora ngerti carane nggarap kode Kotlin, lan kita wis duwe 75% aplikasi sing ditulis ing Kotlin. Mulane, sing dibangun ing ditambahake menyang lint Android Studio mriksa.

Kanggo nindakake iki, kita kudu nindakake akeh perverting: njupuk Android Studio, paket ing Docker lan mbukak ing CI karo monitor virtual, supaya mikir iku mlaku ing laptop nyata. Nanging makarya.

Ing wektu iki uga kita wiwit nulis akeh tes instrumentasi lan dileksanakake tes screenshot. Iki nalika referensi gambar kui kanggo tampilan cilik kapisah, lan test kasusun saka njupuk gambar saka tampilan lan mbandhingaké karo standar langsung piksel dening piksel. Yen ana bedo, tegese tata letak wis salah nang endi wae utawa ana sing salah ing gaya.

Nanging tes instrumentasi lan tes gambar kudu ditindakake ing piranti: ing emulator utawa ing piranti nyata. Ngelingi yen ana akeh tes lan asring ditindakake, kabeh peternakan dibutuhake. Miwiti peternakan dhewe uga mbutuhake tenaga kerja, mula kita nemokake pilihan sing wis siap - Firebase Test Lab.

Firebase Test Lab

Iki dipilih amarga Firebase minangka produk Google, tegese kudu dipercaya lan ora bakal mati. Rega cukup: $ 5 saben jam operasi piranti nyata, 1 $ saben jam operasi emulator.

Butuh udakara telung minggu kanggo ngetrapake Firebase Test Lab menyang CI kita.

Nanging tim terus berkembang, lan Firebase, sayangé, wiwit nguciwani kita. Nalika iku, dheweke ora duwe SLA. Kadhangkala Firebase nggawe kita ngenteni nganti jumlah piranti sing dibutuhake gratis kanggo tes, lan ora langsung nglakokake, kaya sing dikarepake. Nunggu ing baris njupuk nganti setengah jam, sing dawa banget. Tes instrumentasi ditindakake ing saben PR, keterlambatan pancen nyuda pangembangan, banjur tagihan saben wulan teka kanthi jumlah bunder. Umumé, diputusake kanggo ninggalake Firebase lan kerja ing omah, amarga tim wis cukup berkembang.

Docker + Python + bash

We njupuk Docker, diiseni emulators menyang, wrote program prasaja ing Python, kang ing wayahe tengen ndadekke munggah nomer emulator dibutuhake ing versi dibutuhake lan mandheg yen perlu. Lan, mesthi, sawetara skrip bash - ing ngendi kita bakal tanpa?

Butuh limang minggu kanggo nggawe lingkungan tes kita dhewe.

Akibaté, kanggo saben panyuwunan narik ana dhaptar pamblokiran gabungan sing ekstensif:

• Majelis ARK;
• tes Junit;
• Lint;
• mriksa Android Studio;
• Tes instrumentasi;
• Tes gambar.

Iki nyegah akeh kemungkinan risak. Secara teknis, kabeh bisa digunakake, nanging para pangembang ngeluh yen ngenteni asil wis suwe banget.

Suwene suwe banget? Kita ngunggah data saka Bitbucket lan TeamCity menyang sistem analisis lan nyadari wektu nunggu rata-rata 45 menit. Yaiku, pangembang, nalika mbukak panjaluk narik, ngenteni rata-rata 45 menit kanggo asil mbangun. Ing mratelakake panemume, iki akeh banget, lan sampeyan ora bisa kaya.

Mesthi, kita mutusake kanggo nyepetake kabeh mbangun.

Ayo nyepetake

Weruh sing mbangun asring ngadeg ing antrian, bab pisanan kita nindakake iku tuku hardware liyane - pangembangan ekstensif paling gampang. Mbangun mandegake antrian, nanging wektu nunggu sudo mung sethitik, amarga sawetara mriksa dhewe njupuk wektu dawa banget.

Mbusak mriksa sing dawa banget

Integrasi Terus-terusan bisa nyekel jinis kesalahan lan masalah kasebut.

• Ora arep. CI bisa nyekel kesalahan kompilasi nalika ana sing ora dibangun amarga owah-owahan sing bertentangan. Kaya sing wis dakkandhakake, mula ora ana sing bisa nglumpukake apa-apa, pembangunan mandheg, lan kabeh wong gemeter.
• Bug ing prilaku. Contone, nalika aplikasi dibangun, nanging tubrukan nalika sampeyan menet tombol, utawa tombol ora dipencet ing kabeh. Iki ala amarga bug kasebut bisa tekan pangguna.
• Bug ing tata letak. Contone, tombol diklik, nanging wis dipindhah 10 piksel ngiwa.
• Tambah ing utang technical.

Sawise ndeleng dhaptar iki, kita ngerti yen mung rong poin pisanan sing kritis. Kita pengin nyekel masalah kasebut dhisik. Kewan omo ing tata letak ditemokake ing tahap desain-review lan bisa gampang didandani. Nangani utang teknis mbutuhake proses lan perencanaan sing kapisah, mula kita mutusake ora nyoba kanggo njaluk panjaluk.

Adhedhasar klasifikasi iki, kita guncang kabeh dhaptar mriksa. Nyabrang Lint lan nundha peluncuran sewengi: mung supaya bisa ngasilake laporan babagan pirang-pirang masalah ing proyek kasebut. Kita sarujuk kanggo bisa dhewe karo utang technical, lan Pemeriksaan Android Studio ditinggalake. Android Studio ing Docker kanggo inspeksi mlaku katon menarik, nanging nyebabake akeh masalah ing dhukungan. Sembarang nganyari kanggo versi Android Studio tegese perjuangan karo kewan omo sing ora bisa dingerteni. Iku uga angel ndhukung tes gambar, amarga perpustakaan ora stabil banget lan ana positip palsu. Tes gambar wis dibusak saka dhaptar mriksa.

Akibaté, kita ditinggalake:

• Majelis ARK;
• tes Junit;
• Tes instrumentasi.

Gradle remot cache

Tanpa mriksa abot, kabeh dadi luwih apik. Nanging ora ana watesan kanggo kesempurnaan!

Aplikasi kita wis dipérang dadi udakara 150 modul gradle. Cache remot Gradle biasane bisa digunakake ing kasus iki, mula kita mutusake kanggo nyoba.

Cache remot Gradle minangka layanan sing bisa nggawe cache artefak kanggo tugas individu ing modul individu. Gradle, tinimbang nyusun kode kasebut, nggunakake HTTP kanggo ngalahake cache remot lan takon yen ana wong sing wis nindakake tugas iki. Yen ya, iku mung ngundhuh asil.

Mbukak cache remot Gradle gampang amarga Gradle nyedhiyakake gambar Docker. Kita bisa nindakake iki ing telung jam.

Sampeyan mung kudu miwiti Docker lan nulis siji baris ing proyek kasebut. Nanging sanajan bisa diluncurake kanthi cepet, butuh wektu akeh supaya kabeh bisa mlaku kanthi apik.

Ngisor iki cache mbleset graph.

Ing wiwitan, persentase cache luput kira-kira 65. Sawise telung minggu, kita bisa nambah nilai iki nganti 20%. Ternyata tugas sing dikumpulake aplikasi Android duwe dependensi transitif aneh, amarga Gradle ora kejawab cache.

Kanthi nyambungake cache, kita nyepetake mbangun. Nanging saliyane perakitan, ana uga tes instrumentasi, lan butuh wektu suwe. Mbok menawa ora kabeh tes kudu ditindakake kanggo saben panjaluk narik. Kanggo ngerteni, kita nggunakake analisis dampak.

Analisis dampak

Ing panjalukan narik, kita ngumpulake git diff lan nemokake modul Gradle sing diowahi.

Iku ndadekake pangertèn kanggo mung mbukak tes instrumentasi sing mriksa modul diganti lan kabeh modul sing gumantung ing. Ora ana gunane kanggo nganakake tes kanggo modul tetanggan: kode kasebut ora diganti lan ora ana sing bisa rusak.

Tes instrumentasi ora gampang banget, amarga kudu ana ing modul Aplikasi tingkat paling dhuwur. Kita nggunakake heuristik kanthi analisis bytecode kanggo mangerteni modul sing saben tes kasebut.

Nganyarke operasi saka tes instrumentasi supaya padha mung nyoba modul melu njupuk bab wolung minggu.

Langkah-langkah kanggo nyepetake pemeriksaan wis sukses. Saka 45 menit kita munggah kanggo bab 15. Iku wis normal ngenteni seprapat jam kanggo mbangun.

Nanging saiki pangembang wiwit sambat amarga ora ngerti bangunan sing diluncurake, ing endi ndeleng log, kenapa bangunan kasebut abang, tes sing gagal, lsp.

Masalah karo umpan balik alon mudhun pembangunan, supaya kita nyoba kanggo nyedhiyani informasi cetha lan rinci babagan saben PR lan mbangun sabisa. Kita miwiti karo komentar ing Bitbucket kanggo PR, nuduhake kang mbangun wis gagal lan apa, lan nulis pesen diangkah ing Slack. Pungkasane, kita nggawe dashboard PR kanggo kaca kanthi dhaptar kabeh bangunan sing lagi mlaku lan statuse: antri, mlaku, tabrakan utawa rampung. Sampeyan bisa ngeklik mbangun lan mlebu log.

Enem minggu digunakake kanggo umpan balik sing rinci.

Rencana

Ayo pindhah menyang sajarah anyar. Sawise ngrampungake masalah umpan balik, kita tekan level anyar - kita mutusake kanggo mbangun farm emulator dhewe. Nalika ana akeh tes lan emulator, iku angel kanggo ngatur. Akibaté, kabeh emulator kita pindhah menyang k8s kluster kanthi manajemen sumber daya fleksibel.

Kajaba iku, ana rencana liyane.

• Bali menyang Lint (lan analisis statis liyane). Kita wis kerja ing arah iki.
• Mbukak kabeh ing blocker PR tes end-to-end ing kabeh versi SDK.

Dadi, kita wis nglacak sejarah pangembangan Integrasi Terus-terusan ing Avito. Saiki aku pengin menehi saran saka sudut pandang sing berpengalaman.

Tip

Yen aku bisa menehi saran mung siji iki:

Ati-ati nganggo skrip cangkang!

Bash minangka alat sing fleksibel lan kuat, trep lan cepet nulis skrip. Nanging sampeyan bisa tiba menyang sworo cangkem karo, lan, sayangé, kita ambruk menyang.

Iku kabeh diwiwiti kanthi skrip prasaja sing mlaku ing mesin mbangun kita:

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

Nanging, kaya sing sampeyan ngerteni, kabeh berkembang lan dadi luwih rumit sajrone wektu - ayo mbukak siji skrip saka liyane, ayo ngliwati sawetara paramèter ing kana - ing pungkasan kita kudu nulis fungsi sing nemtokake tingkat bash nesting saiki. kanggo masang kuotasi sing perlu, kanggo miwiti kabeh.

Sampeyan bisa mbayangno biaya tenaga kerja kanggo pangembangan skrip kasebut. Aku menehi saran supaya sampeyan ora tiba ing jebakan iki.

Apa sing bisa diganti?

• Basa skrip apa wae. Tulis menyang Python utawa Kotlin Script luwih trep amarga iku program, ora script.
• Utawa njlèntrèhaké kabeh logika mbangun ing wangun Tugas gradle khusus kanggo proyek sampeyan.

Kita mutusake kanggo milih opsi kapindho, lan saiki kita kanthi sistematis mbusak kabeh skrip bash lan nulis akeh tugas gradle khusus.

Tip #2: Simpen infrastruktur ing kode.

Iku trep nalika setelan Integrasi Terus ora disimpen ing antarmuka UI saka Jenkins utawa TeamCity, etc., nanging ing wangun file teks langsung ing repositori project. Iki menehi versionability. Ora bakal angel mbalekake utawa mbangun kode ing cabang liyane.

Skrip bisa disimpen ing proyek. Apa sing kudu dilakoni karo lingkungan?

Tip #3: Docker bisa mbantu lingkungan.

Iku mesthi bakal mbantu pangembang Android; iOS durung duwe, sayangé.

Iki minangka conto file docker prasaja sing ngemot jdk lan 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

Sawise nulis file Docker iki (Aku bakal ngandhani rahasia, sampeyan ora kudu nulis, nanging mung narik siap digawe saka GitHub) lan ngumpulake gambar kasebut, sampeyan entuk mesin virtual sing bisa nggawe aplikasi kasebut. lan mbukak tes Junit.

Rong alasan utama kenapa iki masuk akal yaiku skalabilitas lan bisa diulang. Nggunakake docker, sampeyan bisa kanthi cepet ngunggahake puluhan agen mbangun sing bakal duwe lingkungan sing padha karo sing sadurunge. Iki nggawe urip insinyur CI luwih gampang. Iku cukup gampang kanggo push Android-sdk menyang docker, nanging karo emulator iku sethitik liyane angel: sampeyan kudu bisa sethitik harder (utawa download rampung saka GitHub maneh).

Tip No 4: aja lali yen pemeriksaan ora ditindakake kanggo pamriksa, nanging kanggo wong.

Cepet lan, sing paling penting, umpan balik sing jelas penting banget kanggo pangembang: apa sing rusak, tes apa sing gagal, ing ngendi aku bisa ndeleng buildlog.

Tip #5: Dadi pragmatis nalika ngembangake Integrasi Terus-terusan.

Cetha ngerti jinis kesalahan apa sing pengin dicegah, pira sumber daya, wektu, lan wektu komputer sing arep sampeyan gunakake. Priksa sing dawa banget bisa, contone, ditundha sewengi. Lan wong-wong sing nyekel kesalahan sing ora penting banget kudu ditinggalake.

Tip # 6: Gunakake alat sing wis siap.

Saiki ana akeh perusahaan sing nyedhiyakake cloud CI.

Iki minangka solusi sing apik kanggo tim cilik. Sampeyan ora perlu ndhukung apa-apa, mung mbayar dhuwit sethithik, mbangun aplikasi lan malah nganakake tes instrumentasi.

Tip #7: Ing tim gedhe, solusi ing omah luwih nguntungake.

Nanging cepet utawa mengko, nalika tim tuwuh, solusi ing omah bakal luwih nguntungake. Ana siji masalah karo keputusan kasebut. Ana hukum nyuda bali ing ekonomi: ing proyek apa wae, saben dandan sakteruse luwih angel lan mbutuhake investasi luwih akeh.

Ekonomi nggambarake kabeh urip kita, kalebu Integrasi Terus-terusan. Aku nggawe jadwal biaya tenaga kerja kanggo saben tahap pangembangan Integrasi Terus-terusan.

Cetha yen dandan apa wae dadi saya angel. Deleng ing grafik iki, sampeyan bisa ngerti manawa Integrasi Terus-terusan kudu dikembangake sesuai karo pertumbuhan ukuran tim. Kanggo tim loro wong, nglampahi 50 dina ngembangaken farm emulator internal punika idea biasa-biasa wae. Nanging ing wektu sing padha, kanggo tim sing gedhe, ora nindakake Integrasi Terus-terusan uga minangka ide sing ala, amarga masalah integrasi, ndandani komunikasi, lsp. iku bakal njupuk malah luwih wektu.

Kita miwiti kanthi ide manawa otomatisasi dibutuhake amarga wong larang, nggawe kesalahan lan kesed. Nanging wong uga ngotomatisasi. Mulane, kabeh masalah sing padha ditrapake kanggo otomatisasi.

• Otomasi larang. Elinga jadwal pegawe.
• Nalika nerangake otomatisasi, wong nggawe kesalahan.
• Kadhangkala kesed banget kanggo ngotomatisasi, amarga kabeh bisa kaya ngono. Napa nambah apa wae, kenapa kabeh Integrasi Terus-terusan iki?

Nanging aku duwe statistik: kesalahan kejiret ing 20% ​​saka kumpulan. Lan iki ora amarga pangembang kita nulis kode kanthi apik. Iki amarga pangembang manteb ing ati yen padha nggawe sawetara kesalahan, iku ora bakal mungkasi munggah ing pembangunan, iku bakal kejiret dening mriksa otomatis. Mulane, pangembang bisa nglampahi wektu luwih akeh kanggo nulis kode lan barang-barang sing menarik, tinimbang mbukak lan nyoba soko lokal.

Praktek Integrasi Terus. Nanging ing moderat.

Miturut cara, Nikolai Nesterov ora mung menehi laporan gedhe, nanging uga dadi anggota panitia program AplikasiConf lan mbantu wong liya nyiapake pidato sing migunani kanggo sampeyan. Kelengkapan lan kegunaan program konferensi sabanjure bisa ditaksir miturut topik ing jadwal. Lan kanggo rincian, teka ing Infospace tanggal 22-23 April.

Source: www.habr.com