Ayo dirembug kenapa alat CI lan CI pancen beda.
Apa pain CI dimaksudaké kanggo ngatasi, ngendi teka saka idea, apa konfirmasi paling anyar sing bisa, carane ngerti sing duwe laku lan ora mung diinstal Jenkins.
Gagasan nggawe laporan babagan Integrasi Terus-terusan muncul setahun kepungkur, nalika aku arep wawancara lan golek kerja. Aku ngobrol karo 10-15 perusahaan, mung siji sing bisa njawab kanthi jelas apa CI lan nerangake carane dheweke ngerti yen dheweke ora duwe. Liyane ngomong omong kosong sing ora bisa dingerteni babagan Jenkins :) Inggih, kita duwe Jenkins, iku mbangun, CI! Sajrone laporan kasebut, aku bakal nyoba nerangake apa Integrasi Terus-terusan lan ngapa Jenkins lan alat sing padha duwe hubungan sing lemah banget karo iki.
Dadi, apa sing biasane ana ing pikiran nalika krungu tembung CI? Umume wong bakal mikir babagan Jenkins, Gitlab CI, Travis, lsp.
Sanajan kita google, bakal menehi alat kasebut.
Yen sampeyan kenal karo takon, banjur sawise dhaptar alat kasebut, dheweke bakal ngandhani yen CI nalika sampeyan mbangun lan nganakake tes ing Panjaluk Tarik kanggo komitmen.
Integrasi terus-terusan ora babagan alat, dudu babagan rakitan kanthi tes ing cabang! Integrasi terus-terusan minangka praktik integrasi kode anyar sing kerep banget lan nggunakake kode kasebut ora perlu kanggo pager Jenkins, GitLab, lsp.
Sadurunge kita ngerteni apa CI lengkap, ayo padha nyilem menyang konteks saka wong-wong sing teka karo lan aran pain padha nyoba kanggo ngatasi.
Lan dheweke ngrampungake rasa nyuda kerja bareng minangka tim!
Ayo goleki conto kesulitan sing diadhepi para pangembang nalika berkembang ing tim. Ing kene kita duwe proyek, cabang master ing git lan loro pangembang.
Lan padha mangkat kerja kaya sing wis biasa saben wong. Kita njupuk tugas ing rencana gedhe, nggawe cabang fitur, lan nulis kode kasebut.
Siji rampung fitur luwih cepet lan nggabung menyang master.
Sing nomer loro mbutuhake wektu luwih akeh, banjur gabung lan dadi konflik. Saiki, tinimbang nulis fitur sing dibutuhake bisnis, pangembang mbuwang wektu lan energi kanggo ngrampungake konflik.
Sing luwih angel kanggo nggabungake fitur sampeyan karo master umum, luwih akeh wektu sing ditindakake. Lan aku nuduhake iki kanthi conto sing cukup prasaja. Iki minangka conto sing mung ana pangembang 2. Mbayangno yen 10 utawa 15 utawa 100 wong ing perusahaan nulis menyang siji repositori. Sampeyan bakal edan kanggo ngrampungake kabeh konflik kasebut.
Ana kasus sing rada beda. Kita duwe master lan sawetara pangembang sing nindakake apa wae.
Dheweke nggawe ranting.
Siji mati, kabeh apik, dheweke lulus tugas.
Pangembang kapindho, sauntara, nyerahake tugase. Ayo dadi ngomong kang dikirim kanggo review. Akeh perusahaan duwe praktik sing diarani review. Ing tangan siji, laku iki apik lan migunani, ing tangan liyane, iku slows kita mudhun ing akeh cara. Kita ora bakal mlebu, nanging iki minangka conto sing apik babagan crita review sing ala. Sampeyan wis ngirim panjalukan narik kanggo review. Ora ana maneh sing kudu ditindakake pangembang. Apa sing diwiwiti? Dheweke wiwit nindakake tugas liyane.
Sajrone wektu iki, pangembang kapindho nindakake perkara liya.
Sing pisanan ngrampungake tugas katelu.
Lan sawise sawetara wektu suwene, review wis dites, lan nyoba kanggo nerangake. Dadi apa sing kedadeyan? Iku keno nomer ageng konflik. Kenging punapa? Amarga nalika panjaluk narik kasebut digantung ing review, akeh sing wis diganti ing kode kasebut.
Saliyane crita kanthi konflik, ana crita kanthi komunikasi. Nalika thread sampeyan lagi ditinjau, nalika ngenteni apa-apa, nalika sampeyan lagi nggarap fitur kanggo dangu, sampeyan mandheg nglacak apa sing diganti ing basis kode layanan sampeyan. Mungkin apa sing sampeyan coba ngrampungake saiki wis ditanggulangi wingi lan sampeyan bisa njupuk sawetara cara lan nggunakake maneh. Nanging sampeyan ora bakal weruh iki amarga sampeyan tansah nggarap cabang sing wis lawas. Lan cabang sing wis lawas iki mesthi nyebabake sampeyan kudu ngrampungake konflik gabungan.
Pranyata yen kita kerja minangka tim, yaiku, ora ana wong siji-sijine sing ngubengi gudang, nanging 5-10 wong, mula saya suwe ora nambah kode menyang master, saya tambah nandhang sangsara amarga pungkasane butuh. soko banjur nggabungake. Lan luwih akeh konflik, lan versi lawas sing bisa digunakake, saya akeh masalah.
Nindakake soko bebarengan iku nglarani! Kita tansah njaluk ing cara saben liyane.
Masalah iki ditemokake luwih saka 20 taun kepungkur. Aku nemokake sebutan pisanan babagan praktik Integrasi Terus-terusan ing Pemrograman Ekstrem.
Extreme Programming minangka kerangka agile pisanan. Kaca kasebut muncul ing taun 96. Lan ide kasebut nggunakake sawetara praktik pemrograman, perencanaan lan liya-liyane, supaya pangembangan dadi fleksibel sabisa, supaya kita bisa cepet nanggapi owah-owahan utawa syarat saka klien kita. Lan dheweke wiwit ngadhepi iki 24 taun kepungkur, yen sampeyan nindakake apa-apa kanggo wektu sing suwe lan ing pinggir, sampeyan bakal nglampahi wektu luwih akeh amarga sampeyan duwe konflik.
Saiki kita bakal nganalisa frasa "Integrasi Terus-terusan" kanthi individu. Yen kita nerjemahake langsung, kita entuk integrasi sing terus-terusan. Nanging carane terus-terusan iku ora cetha banget; iku banget pedhot. Nanging sepira integrasi kasebut uga ora jelas.
Lan mulane aku menehi kuotasi saka Extreme Programming saiki. Lan kita bakal nganalisa loro tembung kasebut kanthi kapisah.
Integrasi - Nalika aku wis ngandika, kita usaha kanggo mesthekake yen saben engineer dianggo karo versi paling anyar saka kode, supaya kang usaha kanggo nambah kode asring sabisa kanggo cabang umum, supaya iki cabang cilik. Amarga yen gedhe, mula kita bisa gampang macet karo konflik gabungan sajrone seminggu. Iki utamané bener yen kita duwe siklus pembangunan dawa kayata grojogan, ngendi pangembang lunga kanggo sasi kanggo Cut sawetara fitur ageng. Lan dheweke bakal macet ing tahap integrasi kanggo wektu sing suwe.
Integrasi yaiku nalika kita njupuk cabang lan nggabungake karo master, kita gabung. Ana pilihan pokok nalika kita dadi pangembang transbase, ngendi kita usaha kanggo mesthekake yen kita langsung nulis kanggo master tanpa cabang ekstra.
Umumé, integrasi tegese njupuk kode lan nyeret menyang master.
Apa tegese tembung "terus-terusan", apa sing diarani kontinuitas? Praktek nuduhake manawa pangembang ngupayakake nggabungake kode kasebut kanthi cepet. Iki minangka tujuane nalika nindakake tugas apa wae - supaya kode kasebut dadi master kanthi cepet. Ing donya becik, pangembang bakal nindakake iki saben sawetara jam. Sing, sampeyan njupuk masalah cilik lan nggabung menyang master. Kabeh apik. Iki sing sampeyan usahakake. Lan iki kudu ditindakake terus-terusan. Sanalika sampeyan nindakake soko, sampeyan langsung sijine menyang master.
Lan pangembang sing nggawe soko tanggung jawab kanggo apa sing ditindakake supaya bisa digunakake lan ora ngrusak apa-apa. Iki ngendi crita test biasane metu. Kita pengin nglakokake sawetara tes babagan komitmen kita, ing gabungan kita, kanggo mesthekake yen bisa. Lan ing kene Jenkins bisa mbantu sampeyan.
Nanging kanthi crita: ayo nggawe owah-owahan cilik, ayo tugas dadi cilik, ayo nggawe masalah lan langsung nyoba masangake menyang master - ora ana Jenkins sing bakal nulungi ing kene. Amarga Jenkins mung bakal mbantu sampeyan mbukak tes.
Sampeyan bisa nindakake tanpa wong-wong mau. Iki ora bakal natoni sampeyan. Amarga tujuane latihan yaiku kanggo ngukur sabisa-bisa, supaya ora mbuwang wektu akeh kanggo konflik apa wae ing mangsa ngarep.
Ayo bayangake manawa ana alesan kita ing 2020 tanpa Internet. Lan kita kerja lokal. Kita ora duwe Jenkins. Iki apik. Sampeyan isih bisa nerusake lan nggawe cabang lokal. Sampeyan nulis sawetara kode ing. Kita ngrampungake tugas ing 3-4 jam. Kita ngalih menyang master, narik git, lan nggabungake cabang ing kana. siyap. Yen sampeyan nindakake iki asring, Sugeng, sampeyan duwe Integrasi Terus!
Apa bukti ing donya modhèrn sing ana sing kudu mbuwang energi? Amarga umume angel. Yen sampeyan nyoba kerja kaya iki, sampeyan bakal ngerti manawa sawetara perencanaan saiki bakal kena pengaruh, sampeyan kudu nyawisake wektu luwih akeh kanggo tugas sing rusak. Amarga yen sampeyan nindakake wong ..., sampeyan ora bakal bisa kanthi cepet lan, kanthi mangkono, bakal ngalami alangan. Sampeyan ora bakal duwe latihan maneh.
Lan bakal larang. Sampeyan ora bisa langsung kerja wiwit sesuk nggunakake Integrasi Terus-terusan. Sampeyan kabeh bakal suwe banget kanggo digunakake, bakal mbutuhake wektu sing suwe kanggo digunakake kanggo ngurai tugas, bakal mbutuhake wektu sing suwe kanggo sinau maneh praktik review, yen sampeyan duwe. . Amarga tujuan kita yaiku kanggo nyawiji dina iki. Lan yen sampeyan nindakake review sajrone telung dina, sampeyan duwe masalah lan Integrasi Terus-terusan ora bisa digunakake kanggo sampeyan.
Nanging apa kita duwe bukti sing relevan saiki sing ngandhani yen nandur modal ing praktik iki nggawe akal?
Bab pisanan sing ana ing pikiranku yaiku Negara DevOps. Iki minangka panaliten sing ditindakake wong lanang sajrone 7 taun. Saiki dheweke nindakake minangka organisasi independen, nanging miturut Google.
Lan panaliten 2018 nuduhake korélasi antarane perusahaan sing nyoba nggunakake cabang sing cendhak sing nggabungake kanthi cepet, asring nggabungake, lan duwe indikator kinerja IT sing luwih apik.
Apa indikator kasebut? Iki minangka metrik 4 sing dijupuk saka kabeh perusahaan ing kuesioner: frekuensi penyebaran, wektu timbal kanggo owah-owahan, wektu kanggo mulihake layanan, ngganti tingkat kegagalan.
Lan, sepisanan, ana korélasi iki, kita ngerti manawa perusahaan sing ngukur asring duwe metrik sing luwih apik. Lan dheweke duwe divisi perusahaan dadi sawetara kategori: iki minangka perusahaan alon sing ngasilake alon-alon, pemain medium, pemain dhuwur lan elit. Elit yaiku Netflix, Amazon, sing cepet banget, nindakake kabeh kanthi cepet, apik lan efisien.
Crita kapindho, sing kedadeyan mung sewulan kepungkur. Radar Teknologi duwe artikel sing apik babagan Gitflow. Gitflow beda karo kabeh liyane amarga cabang-cabange umure dawa. Ana cabang release sing urip kanggo dangu, lan fitur cabang sing uga urip kanggo dangu. Praktek iki ing Radar Teknologi wis pindhah menyang HOLD. Kenging punapa? Amarga wong ngadhepi pain saka integrasi.
Yen cabang urip kanggo dangu banget, bakal macet, dadi bosok, lan kita miwiti nglampahi liyane wektu nyoba kanggo nggawe sawetara jenis owah-owahan menyang.
Lan bubar penulis Gitflow ujar manawa tujuan sampeyan yaiku Integrasi Terus-terusan, yen tujuane sampeyan pengin muter kanthi asring, mula Gitflow minangka ide sing ala. Dheweke nambahake kanthi kapisah ing artikel yen sampeyan duwe backend ing ngendi sampeyan bisa ngupayakake iki, banjur Gitflow ora perlu kanggo sampeyan, amarga Gitflow bakal alon-alon sampeyan, Gitflow bakal nggawe masalah kanggo sampeyan kanthi integrasi.
Iki ora ateges Gitflow ala lan ora kudu digunakake. Iku kanggo kesempatan liyane. Contone, yen sampeyan kudu ndhukung sawetara versi layanan utawa aplikasi, yaiku ing ngendi sampeyan butuh dhukungan kanggo wektu sing suwe.
Nanging yen sampeyan ngomong karo wong sing ndhukung layanan kasebut, sampeyan bakal krungu akeh rasa lara babagan kasunyatan manawa versi iki 3.2, yaiku 4 wulan kepungkur, nanging fix iki ora kalebu lan saiki, kanggo nggawe, sampeyan kudu nggawe akeh owah-owahan. Lan saiki lagi macet maneh, lan saiki dheweke wis muter-muter sajrone seminggu nyoba ngetrapake sawetara fitur anyar.
Minangka Alexander Kovalev nyathet kanthi bener ing obrolan, korélasi ora padha karo sabab. Iki bener. Tegese, ora ana sambungan langsung yen sampeyan duwe Integrasi Terus-terusan, banjur kabeh metrik bakal apik. Nanging ana korélasi positif yen siji iku siji, banjur paling kamungkinan liyane uga. Ora kasunyatan, nanging paling kamungkinan. Iku mung korélasi.
Iku misale jek sing kita wis nindakake soko, misale jek sing kita wis nggabung, nanging carane kita bisa ngerti sing kita isih duwe Integrasi Terus-terusan, sing kita wis nggabung cukup asring?
Jez Humble minangka penulis Handbook, Accelerate, situs web Continuous Delivery, lan buku Continuous Delivery. Dheweke nawakake tes iki:
- Kode insinyur tekan master saben dina.
- Kanggo saben komitmen sampeyan mbukak tes unit.
- Mbangun ing master ambruk, iku tetep ing bab 10 menit.
Dheweke nyaranake nggunakake tes kaya iki kanggo mesthekake yen sampeyan duwe latihan sing cukup.
Aku nemokake sing terakhir rada kontroversial. Sing, yen sampeyan bisa ndandani iku ing 10 menit, banjur sampeyan duwe Integrasi Terus-terusan, muni sethitik aneh, ing mratelakake panemume, nanging ndadekake pangertèn. Kenging punapa? Amarga yen sampeyan kerep beku, tegese owah-owahan sampeyan cilik. Yen owah-owahan cilik tegese bangunan master sampeyan rusak, mula sampeyan bisa nemokake conto kanthi cepet amarga owah-owahan cilik. Kene sampeyan wis nggabung cilik, 20-30 garis ing diganti. Lan, kanthi mangkono, sampeyan bisa ngerti kanthi cepet apa sebabe, amarga owah-owahan cilik, sampeyan duwe area cilik kanggo nggoleki masalah kasebut.
Lan sanajan prod kita ambruk sawise release, banjur yen kita duwe laku Integrasi Terus-terusan, iku luwih gampang kanggo kita tumindak, amarga owah-owahan cilik. Ya, iki bakal mengaruhi perencanaan. Iki bakal lara. Lan, mbok menawa, sing paling angel ing praktik iki yaiku sinau kanggo ngrusak tugas, yaiku, carane nindakake supaya sampeyan bisa njupuk lan nindakake ing sawetara jam lan ing wektu sing padha ngliwati review, yen sampeyan duwe siji. Review punika pain kapisah.
Tes unit mung minangka asisten sing mbantu sampeyan ngerti apa integrasi sampeyan sukses lan ora ana sing rusak. Miturut pendapatku, iki uga ora kabeh wajib, amarga iki dudu titik praktik.
Iki minangka introduksi singkat kanggo Integrasi Terus-terusan. Praktek iki mung ana. Aku siyap kanggo pitakonan.
Aku mung bakal ngringkes sedhela maneh:
- Integrasi Terus-terusan dudu Jenkins, dudu Gitlab.
- Iki dudu alat, iku praktik sing kita gabungke kode menyang master minangka asring sabisa.
- Kita nindakake iki kanggo ngindhari rasa lara sing gedhe banget sing muncul kanthi gabungan ing mangsa ngarep, yaiku, kita ngalami rasa lara sing sithik saiki supaya ora ngalami luwih akeh ing mangsa ngarep. Sing kabeh titik.
- Ing sisih ana komunikasi liwat kode, nanging aku arang banget ndeleng iki, nanging iki uga dirancang kanggo.
Pitakonan
Apa sing kudu ditindakake karo tugas sing ora diurai?
decompose. Apa masalahe? Apa sampeyan bisa menehi conto yen ana tugas lan ora rusak?
Ana tugas sing ora bisa diurai saka tembung "rampung", contone, sing mbutuhake keahlian sing jero banget lan bisa dirampungake sajrone sasi kanggo entuk asil sing bisa dicerna.
Yen aku ngerti sampeyan kanthi bener, banjur ana sawetara tugas gedhe lan rumit, asil sing bakal katon mung ing sasi?
Pancen bener. Ya, sampeyan bisa ngevaluasi asil ora luwih awal tinimbang sasi.
nggih. Umumé, iki ora dadi masalah. Kenging punapa? Amarga ing kasus iki, nalika kita ngomong babagan ranting, kita ora ngomong babagan ranting kanthi fitur. Fitur bisa dadi gedhe lan rumit. Padha bisa mengaruhi nomer akeh komponen. Lan bisa uga kita ora bisa nindakake kanthi lengkap ing siji cabang. Iki apik. Kita mung kudu ngilangi crita iki. Yen fitur durung siap, iki ora ateges sawetara potongan kode kasebut ora bisa digabung. Sampeyan nambahake, ngomong, migrasi lan ana sawetara tahapan ing fitur kasebut. Contone, sampeyan duwe panggung - nggawe migrasi, tambahake metode anyar. Lan sampeyan wis bisa ngukur samubarang iki saben dina.
nggih. Apa gunane?
Apa gunane mateni barang cilik saben dina?
Ya.
Yen padha break soko, sampeyan ndeleng iku langsung. Sampeyan duwe potongan cilik sing wis rusak, luwih gampang sampeyan ndandani. Intine yaiku nggabungake potongan cilik saiki luwih gampang tinimbang nggabungake barang sing gedhe sajrone sawetara minggu. Lan titik katelu yaiku insinyur liyane bakal nggarap versi kode saiki. Dheweke bakal weruh manawa sawetara migrasi wis ditambahake ing kene, banjur sawetara cara katon sing uga pengin digunakake. Saben uwong bakal weruh apa sing kedadeyan ing kode sampeyan. Kanggo telung prakara iki latihan ditindakake.
Matur nuwun, masalah wis ditutup!
(Oleg Soroka) Aku bisa nambah? Sampeyan ngandika kabeh bener, aku mung pengin nambah siji frase.
So.
Kanthi Integrasi Terus-terusan, kode kasebut digabung dadi cabang umum ora nalika fitur wis rampung, nanging nalika mbangun mandheg. Lan sampeyan bisa kanthi aman tundhuk master kaping pirang-pirang dina sing dikarepake. Aspek kapindho yaiku yen sampeyan ora bisa ngilangi tugas saben wulan dadi tugas paling ora telung dina, aku meneng udakara telung jam, mula sampeyan duwe masalah gedhe. Lan kasunyatan manawa sampeyan ora duwe Integrasi Terus-terusan minangka masalah sing paling sithik. Iki tegese sampeyan duwe masalah karo arsitektur lan praktik teknik nol. Amarga sanajan iki minangka riset, mula kudu dirumusake kanthi hipotesis utawa siklus.
Kita ngomong babagan metrik 4 sing mbedakake perusahaan sing sukses saka sing ketinggalan. Kita isih kudu urip kanggo ndeleng 4 metrik iki. Yen tugas rata-rata mbutuhake sasi kanggo ngrampungake, mula aku bakal fokus ing metrik iki dhisik. Aku bakal mudhun kanggo 3 dina pisanan. Lan sawise iku aku wiwit mikir babagan Continuous.
Apa aku ngerti sampeyan kanthi bener yen sampeyan mikir yen umume ora ana gunane nandur modal ing praktik teknik yen ana tugas sing butuh sewulan?
Sampeyan duwe Integrasi Terus-terusan. Lan ana topik sing ing 10 menit sampeyan bisa ndandani fix utawa muter maneh. Mbayangno sampeyan mbalek metu. Kajaba iku, sampeyan malah duwe panyebaran sing terus-terusan, sampeyan gulung menyang prod lan mung weruh yen ana sing salah. Lan sampeyan kudu muter maneh, nanging sampeyan wis migrasi database. Sampeyan wis duwe skema database versi sabanjure, luwih-luwih sampeyan uga duwe sawetara jinis serep, lan data kasebut uga ditulis ing kana.
Lan apa alternatif sampeyan duwe? Yen sampeyan muter maneh kode kasebut, mula ora bisa digunakake maneh karo database sing dianyari iki.
Dasar mung maju, ya.
Wong-wong sing duwe praktik teknik sing kurang apik kemungkinan durung maca buku sing kandel babagan ... uga. Apa sing kudu dilakoni karo serep? Yen sampeyan mulihake saka serep, tegese sampeyan bakal kelangan data sing wis diklumpukake sajrone wektu kasebut. Contone, kita makarya telung jam karo versi anyar saka database, kedhaftar kedhaftar ana. Sampeyan nolak serep lawas amarga skema kasebut ora bisa digunakake karo versi anyar, mula sampeyan ilang pangguna kasebut. Lan padha ora marem, padha sumpah.
Kanggo nguwasani macem-macem praktik sing ndhukung Integrasi Terus-terusan lan Pangiriman Terus-terusan, ora cukup mung sinau nulis .... Kaping pisanan, bisa uga akeh, mula ora praktis. Kajaba iku, ana akeh praktik liyane kaya Ilmiah. Ana praktik kaya ngono, GitHub dipopulerkan sekaligus. Iki nalika sampeyan duwe kode lawas lan kode anyar sing mlaku bebarengan. Iki nalika sampeyan nggawe fitur sing durung rampung, nanging bisa ngasilake sawetara nilai: minangka fungsi utawa minangka API Rest. Sampeyan nglakokake kode anyar lan kode lawas, lan mbandhingake bedane. Lan yen ana prabédan, banjur log acara iki. Kanthi cara iki sampeyan ngerti manawa sampeyan duwe fitur anyar sing siap diluncurake ing ndhuwur sing lawas yen sampeyan ora duwe bedo antarane loro kasebut sajrone wektu tartamtu.
Ana atusan laku kuwi. Aku suggest miwiti karo pembangunan transbase. Dheweke ora 100% ing Integrasi Terus-terusan, nanging praktik kasebut padha, siji ora bisa urip kanthi becik tanpa liyane.
Apa sampeyan menehi pangembangan transbase minangka conto ing ngendi sampeyan bisa ndeleng praktik utawa sampeyan menehi saran supaya wong wiwit nggunakake debelopment transbase?
Deleng, amarga dheweke ora bakal bisa nggunakake. Kanggo nggunakake, sampeyan kudu maca akeh. Lan nalika ana wong takon: "Apa sing kudu ditindakake karo fitur sing butuh sewulan, tegese dheweke durung maca babagan pangembangan transbase." Aku durung nyaranake. Aku bakal menehi saran supaya fokus mung ing topik babagan cara ngrusak arsitektur kanthi bener dadi tugas sing luwih cilik. Iki minangka inti saka dekomposisi.
Dekomposisi minangka salah sawijining piranti arsitek. Kita pisanan nindakake analisis, banjur dekomposisi, banjur sintesis, banjur integrasi. Lan iki carane kabeh bisa kanggo kita. Lan kita isih kudu tuwuh menyang Integrasi Terus-terusan liwat dekomposisi. Pitakonan muncul ing tahap pisanan, lan kita wis ngomong babagan tahap kaping papat, yaiku, luwih asring kita nindakake integrasi, luwih apik. Isih awal banget kanggo nindakake iki; luwih becik nyuda monolit sampeyan dhisik.
Sampeyan kudu nggambar sawetara panah lan kothak ing sawetara diagram. Sampeyan ora bisa ngomong yen saiki aku bakal nuduhake diagram arsitektur aplikasi anyar lan nuduhake siji kothak, ing njero ana tombol ijo kanggo aplikasi kasebut. Ing kasus apa wae, bakal luwih akeh kothak lan panah. Saben diagram sing dakdeleng ana luwih saka siji. Lan dekomposisi, sanajan ing tingkat perwakilan grafis, wis kedadeyan. Mulane, kothak bisa digawe independen. Yen ora, aku duwe pitakonan gedhe kanggo arsitek.
Ana pitakonan saka obrolan: "Yen review wajib lan butuh wektu suwe, bisa uga sedina utawa luwih?"
Sampeyan duwe masalah karo latihan. Tinjauan kasebut ora kudu suwene sedina utawa luwih. Iki crita sing padha karo pitakonan sadurunge, mung luwih alus. Yen review diterusake sedina, mesthine review iki bakal ana owah-owahan sing gedhe banget. Iki tegese kudu digawe luwih cilik. Ing pangembangan transbase, sing dianjurake Oleg, ana crita sing diarani review terus-terusan. Ide dheweke yaiku supaya kita nggawe panjaluk tarik cilik kanthi sengaja, amarga kita ngupayakake gabung terus-terusan lan sithik-sithik. Lan panjaluk narik ngganti siji abstraksi utawa 10 baris. Thanks kanggo review iki, kita butuh sawetara menit.
Yen review njupuk dina utawa luwih, ana sing salah. Kaping pisanan, sampeyan bisa uga duwe masalah karo arsitektur. Utawa iki Piece gedhe saka kode, 1 baris, contone. Utawa arsitektur sampeyan rumit banget nganti wong ora bisa ngerti. Iki minangka masalah sing rada miring, nanging uga kudu dirampungake. Mbok menawa ana ora perlu kanggo review ing kabeh. Kita uga kudu mikir babagan iki. Review iku bab sing slows sampeyan mudhun. Umume duwe kaluwihan, nanging sampeyan kudu ngerti kenapa sampeyan nindakake. Apa iki cara kanggo sampeyan ngirim informasi kanthi cepet, apa iki cara kanggo nyetel sawetara standar internal utawa apa? Napa sampeyan butuh iki? Amarga review kudu ditindakake kanthi cepet utawa dibatalake kabeh. Kaya dene pembangunan transbase - critane apik banget, nanging mung kanggo wong diwasa.
Babagan 4 metrik, aku isih bakal nyaranake mbusak mau kanggo ngerti apa iki ndadékaké kanggo. Delengen angka-angka, deleng gambar, kabeh ala.
(Dmitry) Aku siap melu diskusi babagan iki karo sampeyan. Nomer lan metrik kabeh apik, praktik apik banget. Nanging sampeyan kudu ngerti apa bisnis mbutuhake. Ana bisnis sing ora mbutuhake owah-owahan kaya ngono. Aku ngerti perusahaan sing ora bisa owah-owahan saben 15 menit. Lan ora amarga padha ala banget. Iki minangka siklus urip. Lan kanggo nggawe fitur cabang, fitur toggle, sampeyan butuh kawruh sing jero.
Iku rumit. Yen sampeyan pengin maca crita babagan fitur toggle kanthi luwih rinci, aku menehi saran banget . Lan ana artikel sing apik banget dening Martin Fowler babagan fitur toggle: jinis apa sing ana, siklus urip, lan liya-liyane. Fitur pilihan kasebut rumit.
Lan sampeyan isih durung mangsuli pitakon: "Apa Jenkins dibutuhake utawa ora?"
Jenkins ora perlu ing kasus apa wae. Nanging, alat kasebut: Jenkins, Gitlab bakal nggawe sampeyan kepenak. Sampeyan bakal weruh sing Déwan wis nglumpuk utawa ora nglumpuk. Dheweke bisa mbantu sampeyan, nanging ora bakal menehi latihan. Dheweke mung bisa menehi bunder - Ok, ora Ok. Banjur, yen sampeyan uga nulis tes, amarga yen ora ana tes, mula meh ora ana gunane. Mulane, perlu amarga luwih trep, nanging ing umum sampeyan bisa urip tanpa iku, sampeyan ora bakal kelangan akeh.
Yaiku, yen sampeyan duwe praktik, tegese sampeyan ora butuh?
Bener. Aku nyaranake test Jez Humble. Ana aku duwe sikap ambivalent menyang titik pungkasan. Nanging umume, yen sampeyan duwe telung perkara, sampeyan terus-terusan nggabung, sampeyan nganakake tes kanggo nindakake master, kanthi cepet ndandani bangunan ing master, mula sampeyan ora butuh apa-apa liyane.
Nalika kita ngenteni pitakonan saka peserta, aku duwe pitakonan. Kita mung ngomong babagan kode produk. Apa sampeyan wis digunakake kanggo kode infrastruktur? Apa kode sing padha, duwe prinsip sing padha lan siklus urip sing padha, utawa ana siklus lan prinsip urip sing beda? Biasane, nalika saben wong ngomong babagan Integrasi lan Pengembangan Terus-terusan, kabeh wong lali yen ana uga kode infrastruktur. Lan akhir-akhir iki tambah akeh. Lan apa kabeh aturan kasebut kudu digawa menyang kana?
Ora malah sing ngirim, iku bakal gedhe amarga bakal nggawe urip luwih gampang ing cara sing padha. Sanalika kita nggarap kode, ora nganggo skrip bash, nanging kita duwe kode normal.
Stop, stop, script bash uga kode. Aja dumeh tresnaku sing lawas.
Oke, aku ora bakal ngidak-idak kenanganmu. Aku duwe pribadi ora seneng kanggo bash. Iku rusak ala lan medeni kabeh wektu. Lan asring rusak ora bisa ditebak, mula aku ora seneng. Nanging oke, ayo ngomong sampeyan duwe kode bash. Mungkin aku pancene ora ngerti lan ana kerangka testing normal metu ana. Aku mung ora ngerti. Lan kita entuk keuntungan sing padha.
Sanalika kita nggarap infrastruktur minangka kode, kita entuk kabeh masalah sing padha karo pangembang. Sawetara sasi kepungkur, aku nemoni kahanan ing ngendi kolega ngirim panjaluk tarik kanggo 1 baris ing bash. Lan sampeyan nongkrong ing review kanggo 000 jam. Masalah sing padha muncul. Iku isih kode. Lan isih kolaborasi. Kita macet karo panyuwunan narik lan kita macet kanthi kasunyatan manawa kita ngrampungake konflik gabungan sing padha ing bash sing padha, umpamane.
Aku saiki aktif banget ndeleng kabeh babagan program infra sing paling apik. Aku saiki wis nggawa Pulumi menyang infrastruktur. Iki minangka pemrograman ing wangun sing paling murni. Ana iku malah luwih apik, amarga aku duwe kabeh kemampuan saka basa program, i.e. Aku nggawe pilihan ayu metu saka biru karo ifs padha lan kabeh iku nggoleki. Tegese, owah-owahanku wis ana ing master. Kabeh wong wis bisa ndeleng dheweke. Insinyur liyane ngerti babagan iki. Iku wis dipengaruhi soko ana. Nanging, ora diaktifake kanggo kabeh infrastruktur. Diuripake kanggo bangku test, contone. Mulane, kanggo njawab pitakonan sampeyan maneh, iku perlu. Iki nggawe urip luwih gampang kanggo kita, minangka insinyur sing nggarap kode, kanthi cara sing padha.
Yen wong liya duwe pitakonan?
Aku duwe pitakonan. Aku pengin nerusake diskusi karo Oleg. Umumé, aku mikir sing bener, yen tugas njupuk sasi kanggo ngrampungake, sampeyan duwe masalah karo arsitektur, sampeyan duwe masalah karo analisis, dekomposisi, planning, etc. Nanging aku duwe perasaan yen sampeyan miwiti nyoba urip miturut Integrasi Terus-terusan, banjur sampeyan bakal miwiti kanggo mbenerake pain karo planning, amarga sampeyan ora bakal njaluk adoh saka ngendi wae liya.
(Oleg) Ya, bener. Praktek iki bisa dibandhingke ing upaya kanggo praktik owah-owahan budaya liyane sing serius. Bab sing paling angel diatasi yaiku kabiasaan, utamane kebiasaan sing ala. Lan yen kanggo ngleksanakake praktik iki, owah-owahan serius ing kabiasaan wong-wong sing ana ing sekitar sampeyan dibutuhake: pangembang, manajemen, manajer produksi, banjur kejutan nunggu sampeyan.
Apa surprises bisa ana? Contone, sampeyan mutusake yen sampeyan bakal luwih kerep nggabungake. Lan sampeyan duwe sawetara perkara liyane sing ana gandhengane karo integrasi, contone, artefak. Lan ing perusahaan sampeyan, umpamane, ana kabijakan manawa saben artefak kudu dipertanggungjawabake ing sawetara sistem panyimpenan artefak. Lan butuh sawetara wektu. Wong kudu mriksa kothak yen dheweke, minangka manajer rilis, wis nguji artefak iki kanggo mesthekake yen wis siyap diluncurake ing produksi. Yen njupuk 5-10-15 menit, nanging sampeyan nindakake tata letak sapisan minggu, banjur nglampahi setengah jam sapisan minggu iku tax cilik.
Yen sampeyan nindakake Integrasi Terus-terusan 10 kaping dina, banjur kaping 10 kudu dikali 30 menit. Lan iki ngluwihi jumlah wektu kerja manajer rilis iki. Dheweke mung kesel nglakoni. Ana biaya tetep kanggo sawetara praktik. Mekaten.
Lan sampeyan kudu mbatalake aturan iki supaya sampeyan ora nindakake sampah kasebut, yaiku sampeyan ora menehi gelar kanthi manual kanggo cocog karo apa wae. Sampeyan ngandelake kabeh tes kesiapan otomatis.
Lan yen sampeyan butuh bukti saka wong, supaya bos menehi tandha, lan sampeyan ora entuk produksi tanpa Vasya ujar manawa dheweke ngidini, lan liya-liyane - kabeh omong kosong iki bakal ana ing cara praktisi. Amarga yen ana sawetara kegiatan sing digandhengake karo pajak, kabeh mundhak 100 kaping. Mula, owah-owahan kasebut asring ora bakal disambut kanthi bungah dening kabeh wong. Amarga pakulinan wong angel diowahi.
Nalika wong nindakake pakaryan sing biasa, dheweke nindakake meh tanpa mikir. Beban kognitif dheweke nol. Dheweke mung muter-muter, dheweke wis duwe daftar priksa ing sirahe, wis kaping sewu. Lan sanalika sampeyan teka lan ngomong: "Ayo mbatalake praktik iki lan ngenalake sing anyar wiwit Senin," kanggo dheweke dadi beban kognitif sing kuat. Lan nerangake saben wong bebarengan.
Mulane, sing paling gampang, sanajan ora kabeh wong bisa duwe kemewahan iki, nanging iki sing tansah daklakoni, iki ing ngisor iki. Yen proyek anyar diwiwiti, biasane kabeh praktik sing durung dites langsung dirampungake ing proyek iki. Nalika proyek isih enom, kita ora duwe risiko apa-apa. Durung ana Prod, ora ana sing bisa dirusak. Mulane, bisa digunakake minangka latihan. Pendekatan iki bisa digunakake. Nanging ora kabeh perusahaan duwe kesempatan kanggo miwiti proyek kasebut asring. Sanajan iki uga rada aneh, amarga saiki ana transformasi digital sing lengkap, kabeh wong kudu ngluncurake eksperimen supaya bisa bersaing karo pesaing.
Ing kene sampeyan entuk kesimpulan yen sampeyan kudu ngerti apa sing kudu sampeyan lakoni. Donya ora becik, lan prod uga ora becik.
Ya, bab-bab iki saling gegandhèngan.
Bisnis uga ora mesthi ngerti yen dheweke kudu mlaku kanthi cara iki.
Ana kahanan sing ora ana owah-owahan sing bisa ditindakake. Iki minangka kahanan sing luwih akeh tekanan ing tim. Tim wis cukup kobong. Dheweke ora duwe wektu luang kanggo eksperimen apa wae. Padha nggarap fitur saka esuk nganti sore. Lan manajemen nduweni fitur sing luwih sithik. Luwih akeh sing dibutuhake. Ing kahanan kaya mengkono, ora ana owah-owahan sing bisa ditindakake. Tim kasebut mung bisa dikandhani yen sesuk kita bakal nindakake kaya wingi, kita mung kudu nggawe fitur liyane. Ing pangertèn iki, ora ana transisi menyang praktik apa wae sing bisa ditindakake. Iki minangka kahanan klasik nalika ora ana wektu kanggo ngasah kapak, wit kudu ditegor, mula dipotong nganggo kapak sing kusam. Ora ana tips prasaja ing kene.
(Dmitry) Aku bakal maca klarifikasi saka obrolan: "Nanging kita butuh akeh jangkoan tes ing tingkat sing beda. Pira wektu sing diparengake kanggo tes? Regane rada larang lan butuh wektu akeh.”
(Oleg) Iki salah paham klasik. Mesthi ana tes sing cukup kanggo sampeyan supaya yakin. Integrasi sing terus-terusan dudu perkara sing 100% tes ditindakake dhisik lan banjur sampeyan miwiti ngetrapake praktik kasebut. Integrasi sing terus-terusan nyuda beban kognitif amarga kasunyatane saben owah-owahan sing sampeyan deleng kanthi mripat katon jelas yen sampeyan ngerti manawa bakal ngrusak utawa ora, sanajan tanpa tes. Sampeyan bisa kanthi cepet nyoba iki ing sirah amarga owah-owahan cilik. Sanajan sampeyan mung duwe panguji manual, luwih gampang uga. Sampeyan muter metu lan ngandika: "Lah, apa ana sing rusak?" Dheweke mriksa lan ujar, "Ora, ora ana sing rusak." Amarga panguji ngerti ngendi arep katon. Sampeyan duwe siji komit sing digandhengake karo siji potongan kode. Lan iki dieksploitasi dening prilaku tartamtu.
Kene sampeyan, mesthi, embellished.
(Dmitry) Aku ora setuju ing kene. Ana praktik - pangembangan sing didorong tes, sing bakal nylametake sampeyan saka iki.
(Oleg) Inggih, aku durung tekan titik kasebut. Ilusi pisanan yaiku sampeyan kudu nulis 100% tes utawa sampeyan ora perlu nindakake Integrasi Terus-terusan. Iku ora bener. Iki minangka rong praktik paralel. Lan padha ora langsung gumantung. Jangkoan tes sampeyan kudu optimal. Optimal - iki tegese sampeyan dhewe manteb ing ati yen kualitas master ing ngendi master sampeyan tetep sawise komit ngidini sampeyan kanthi yakin mencet tombol "Sebar" ing wayah sore mabuk. Kepiye carane entuk iki? Liwat review, liwat jangkoan, liwat pemantauan sing apik.
Pemantauan sing apik ora bisa dibedakake karo tes. Yen sampeyan nglakokake tes sapisan ing pre prod, banjur padha mriksa kabeh skrip pangguna sapisan lan mung. Lan yen sampeyan mbukak ing daur ulang tanpa wates, mula iki minangka sistem pemantauan sing disebarake, sing nyoba kabeh tanpa wates - apa tabrakan utawa ora. Ing kasus iki, bedane mung yen ditindakake sepisan utawa kaping pindho. Tes sing apik banget ... mlaku tanpa wates, iki ngawasi. Lan pemantauan sing tepat kudu kaya iki.
Lan mulane, kepiye carane sampeyan bakal entuk negara iki nalika sampeyan siyap ing wayah sore Jumuah lan mulih minangka pitakonan liyane. Mungkin sampeyan mung scumbag kendel.
Ayo bali sethithik menyang Integrasi Terus-terusan. Kita mlayu menyang praktik rumit sing rada beda.
Lan khayalan kapindho yaiku MVP, ujare, kudu ditindakake kanthi cepet, mula ora ana tes sing dibutuhake. Ora mesthi ing cara sing. Kasunyatane yaiku nalika sampeyan nulis crita pangguna ing MVP, sampeyan bisa ngembangake bal kasebut, yaiku, sampeyan krungu manawa ana sawetara crita pangguna lan langsung mlayu menyang kode, utawa sampeyan bisa nggunakake TDD. Lan miturut TDD, minangka praktik nuduhake, ora butuh wektu maneh, yaiku tes minangka efek samping. Praktek TDD dudu babagan tes. Senadyan apa sing diarani Test Driven Development, ora mung babagan tes. Iki uga minangka pendekatan arsitektur. Iki minangka pendekatan kanggo nulis apa sing dibutuhake lan ora nulis apa sing ora dibutuhake. Iki minangka praktik fokus ing iterasi sabanjure babagan mikir babagan nggawe arsitektur aplikasi.
Mulane, ora gampang banget kanggo nyingkirake ilusi kasebut. MVP lan tes ora mbantah saben liyane. Malah, malah, ing nalisir, yen sampeyan nindakake MVP nggunakake TDD laku, sampeyan bakal nindakake iku luwih apik lan luwih cepet saka yen nindakaken tanpa laku ing kabeh, nanging ing werni.
Iki minangka ide sing ora jelas lan rumit. Yen sampeyan krungu saiki, aku bakal nulis luwih akeh tes lan ing wektu sing padha aku bakal nindakake luwih cepet, kayane ora cukup.
(Dmitry) Akeh wong ing kene, nalika nelpon MVP, wong kesed nulis sing normal. Lan iki isih beda. Ora perlu ngowahi MVP dadi sawetara perkara sing ora bisa ditindakake.
Ya, ya, sampeyan bener.
Banjur dumadakan MVP ing prod.
Selawase.
Lan TDD muni banget mirunggan nalika krungu sing nulis tes lan koyone apa liyane karya. Iku muni banget aneh, nanging nyatane dadi luwih cepet lan luwih ayu ing cara iki. Nalika sampeyan nulis tes, sampeyan wis mikir akeh babagan kode apa sing bakal diarani lan kepiye carane, uga prilaku sing dikarepake. Sampeyan ora mung ngomong aku wrote sawetara fungsi lan nindakake soko. Ing wiwitan sampeyan mikir yen dheweke duwe kahanan kaya mengkono, dheweke bakal ditimbali kanthi cara kasebut. Sampeyan nutupi iki karo tes lan saka iki sampeyan ngerti carane antarmuka bakal katon ing kode sampeyan. Iki nduwe pengaruh gedhe ing arsitektur. Kode sampeyan kanthi otomatis dadi luwih modular, amarga sampeyan pisanan nyoba kanggo mangerteni carane sampeyan bakal nyoba, lan mung banjur nulis.
Apa sing kedadeyan karo TDD yaiku nalika aku nyewa mentor Ruby nalika isih dadi programmer Ruby. Lan ngandika: "Ayo nindakaken miturut TDD." Aku mikir: "Sialan, saiki aku kudu nulis tambahan." Lan kita sarujuk yen ing rong minggu aku bakal nulis kabeh kode kerja ing Python nggunakake TDD. Sawise rong minggu, aku ngerti yen aku ora pengin bali. Sawise rong minggu nyoba ngetrapake iki ing endi wae, sampeyan bakal ngerti kepiye luwih gampang sampeyan mikir. Nanging iki ora ketok, mula aku menehi saran kanggo kabeh wong yen sampeyan duwe perasaan yen TDD angel, akeh wektu lan ora perlu, coba tetep mung rong minggu. Loro cukup kanggo aku.
(Dmitry) Kita bisa nggedhekake gagasan iki saka sudut pandang operasi infrastruktur. Sadurunge miwiti apa wae sing anyar, kita ngawasi banjur diluncurake. Ing kasus iki, ngawasi dadi tes normal kanggo kita. Lan ana pangembangan liwat pemantauan. Nanging meh kabeh wong ngomong yen dawa, aku kesed, aku nggawe rancangan sementara. Yen kita wis ngawasi normal, kita ngerti kahanan sistem CI. Lan sistem CI duwe akeh pemantauan. Kita ngerti kahanan sistem kasebut, kita ngerti apa sing ana ing njero. Lan sajrone pembangunan, kita mung nggawe sistem supaya bisa tekan negara sing dikarepake.
Laku iki wis dikenal kanggo dangu. Kita ngrembug babagan iki 4 taun kepungkur. Nanging ing 4 taun praktis ora ana owah-owahan.
Nanging ing cathetan iki, aku ngusulake kanggo mungkasi diskusi resmi.
Video (dilebokake minangka unsur media, nanging sakperangan alesan ora bisa digunakake):
Source: www.habr.com