Hayu urang bahas naha alat CI sareng CI mangrupikeun hal anu béda.
Naon nyeri CI dimaksudkeun pikeun ngajawab, ti mana ideu asalna, naon confirmations panganyarna nu gawéna, kumaha ngarti yén anjeun boga prakték sarta teu ngan dipasang Jenkins.
Gagasan nyieun laporan ngeunaan Continuous Integration muncul sataun katukang, nalika kuring badé ngawawancara sareng milarian padamelan. Kuring ngobrol jeung 10-15 pausahaan, ngan salah sahijina éta bisa jelas ngajawab naon CI jeung ngajelaskeun kumaha maranéhna sadar yén maranéhna teu boga eta. Sésana nyarios omong kosong anu teu kaharti ngeunaan Jenkins :) Nya, urang gaduh Jenkins, éta ngawangun, CI! Salila laporan, abdi bakal coba ngajelaskeun naon Continuous Pamaduan sabenerna sarta naha Jenkins sarta parabot sarupa boga hubungan pisan lemah sareng ieu.
Janten, naon anu biasana aya dina pikiran nalika anjeun nguping kecap CI? Seueur jalma bakal mikirkeun Jenkins, Gitlab CI, Travis, jsb.
Malah lamun urang google eta, éta bakal masihan urang parabot ieu.
Upami anjeun wawuh sareng naroskeun, teras saatos daptar alat, aranjeunna bakal nyarios yén CI nyaéta nalika anjeun ngawangun sareng ngajalankeun tés dina Paménta Tarik pikeun komitmen.
Integrasi Kontinyu sanés ngeunaan alat, sanés ngeunaan rakitan sareng tés dina cabang! Integrasi Kontinyu mangrupikeun prakték integrasi kode énggal anu sering pisan sareng ngagunakeun éta henteu kedah dipager Jenkins, GitLab, jsb.
Sateuacan urang terangkeun kumaha rupa CI anu lengkep, hayu urang teuleum heula kana kontéks jalma-jalma anu mendakan éta sareng ngaraosan nyeri anu aranjeunna nyobian direngsekeun.
Sareng aranjeunna ngarengsekeun nyeri damel babarengan salaku tim!
Hayu urang tingali conto kasusah anu disanghareupan ku pamekar nalika ngembangkeun tim. Di dieu urang gaduh proyék, cabang master di git sareng dua pamekar.
Jeung maranéhna indit ka pagawean sakumaha dulur geus lila biasa. Kami nyandak tugas dina skéma hébat, nyiptakeun cabang fitur, sareng nyerat kodeu.
Hiji réngsé fitur nu leuwih gancang sarta ngagabung kana master.
Anu kadua peryogi langkung waktos, éta ngahiji engké sareng ditungtungan ku konflik. Ayeuna, tinimbang nyerat fitur anu diperyogikeun ku bisnis, pamekar nyéépkeun waktos sareng tanaga pikeun ngarengsekeun konflik.
Beuki hese ngagabungkeun fitur anjeun sareng master umum, langkung seueur waktos urang nyéépkeun éta. Sareng kuring nunjukkeun ieu kalayan conto anu saderhana. Ieu mangrupikeun conto dimana ngan ukur aya pamekar 2. Bayangkeun upami 10 atanapi 15 atanapi 100 jalma dina perusahaan nyerat kana hiji gudang. Anjeun bakal gélo pikeun ngabéréskeun sagala konflik ieu.
Aya kasus anu rada béda. Kami gaduh master sareng sababaraha pamekar anu ngalakukeun hiji hal.
Aranjeunna nyiptakeun dahan.
Hiji maot, sagalana éta rupa, anjeunna lulus tugas.
Pangembang kadua, samentawis, nyerahkeun tugasna. Hayu urang nyebutkeun anjeunna dikirim pikeun review. Loba pausahaan boga prakték disebut review. Di hiji sisi, prakték ieu saé sareng mangpaat, di sisi sanésna, ngalambatkeun urang ku sababaraha cara. Kami moal lebet kana éta, tapi ieu mangrupikeun conto anu saé ngeunaan naon anu tiasa nyababkeun carita ulasan anu goréng. Anjeun geus dikintunkeun pamundut tarikan pikeun review. Aya nanaon deui pikeun pamekar do a. Naon anu anjeunna ngamimitian? Anjeunna mimiti nyandak tugas séjén.
Salila ieu, pamekar kadua ngalakukeun hal anu sanés.
Anu kahiji réngsé tugas katilu.
Sarta sanggeus sababaraha lila, review na ieu diuji, sarta anjeunna nyobian datang ka istilah. Janten naon anu lumangsung? Éta nyekel sajumlah ageung konflik. Naha? Kusabab bari pamundut tarikan na nongkrong di review, loba hal geus robah dina kode.
Salian ti carita kalawan konflik, aya carita kalawan komunikasi. Nalika thread anjeun ngagantung dina ulasan, bari ngantosan hiji hal, nalika anjeun damel dina fitur anu lami, anjeun ngeureunkeun nyukcruk naon deui anu robih dina dasar kode jasa anjeun. Panginten naon anu anjeun badé mecahkeun ayeuna parantos direngsekeun kamari sareng anjeun tiasa nyandak sababaraha metode sareng nganggo deui. Tapi anjeun moal ningali ieu kusabab anjeun sok damel sareng cabang anu luntur. Sareng cabang anu luntur ieu salawasna nyababkeun anjeun kedah ngabéréskeun konflik ngahiji.
Tétéla yén upami urang damel salaku tim, nyaéta, sanés hiji jalma anu poking di gudang, tapi 5-10 urang, teras langkung lami urang henteu nambihan kodeu ka master, langkung seueur urang sangsara sabab pamustunganana peryogi. hiji hal tuluy ngahiji. Sareng langkung seueur konflik anu urang gaduh, sareng versi anu langkung lami anu urang damel, langkung seueur masalah anu urang gaduh.
Ngalakukeun hiji hal babarengan téh nyeri! Urang sok ngahalangan.
Masalah ieu diperhatoskeun langkung ti 20 taun ka pengker. Kuring mendakan anu disebatkeun heula prakték Integrasi Kontinyu dina Programming Ekstrim.
Extreme Programming mangrupikeun kerangka tangkas munggaran. Kaca ieu muncul dina 96. Sareng ideu nyaéta ngagunakeun sababaraha jinis prakték pemrograman, perencanaan sareng hal-hal anu sanés, ku kituna pamekaran bakal fleksibel sabisa-gancang, ku kituna urang tiasa gancang ngaréspon kana parobihan atanapi sarat ti klien kami. Sareng aranjeunna mimiti nyanghareupan ieu 24 sababaraha taun ka pengker, yén upami anjeun ngalakukeun hiji hal pikeun waktos anu lami pisan sareng di sela-sela, maka anjeun nyéépkeun waktos langkung seueur kusabab anjeun gaduh konflik.
Ayeuna urang bakal nganalisis frase "Continuous Integration" masing-masing. Lamun urang narjamahkeun langsung, urang meunang integrasi kontinyu. Tapi kumaha kontinyu éta henteu écés pisan; éta pisan discontinuous. Tapi sabaraha integrasi éta ogé henteu écés pisan.
Sareng sababna kuring masihan anjeun kutipan tina Extreme Programming ayeuna. Sareng urang bakal nganalisis duanana kecap sacara misah.
Integrasi - Sakumaha anu parantos nyarios, urang narékahan pikeun mastikeun yén unggal insinyur damel sareng versi kode anu paling ayeuna, ku kituna anjeunna narékahan pikeun nambihan kode na sering-gancang ka cabang umum, ku kituna ieu mangrupikeun cabang leutik. Kusabab upami aranjeunna ageung, maka urang tiasa gampang macét sareng konflik gabungan salami saminggu. Ieu hususna leres upami urang gaduh siklus pangembangan anu panjang sapertos curug, dimana pamekar angkat salami sabulan pikeun motong sababaraha fitur anu ageung. Sareng anjeunna bakal macét dina tahap integrasi pikeun waktos anu lami pisan.
Integrasi nyaéta nalika urang nyandak cabang urang sareng ngahijikeunana sareng master, urang ngahijikeunana. Aya hiji pilihan pamungkas lamun urang pamekar transbase, dimana urang narékahan pikeun mastikeun yén urang langsung nulis ka master tanpa cabang tambahan.
Sacara umum, integrasi hartosna nyandak kode anjeun sareng nyered kana master.
Naon anu dimaksud di dieu ku kecap "terus-terusan", naon anu disebut kontinuitas? Prakték nunjukkeun yén pamekar narékahan pikeun ngahijikeun kode na gancang-gancang. Ieu mangrupikeun tujuanana nalika ngalaksanakeun tugas naon waé - pikeun gancang-gancang nyandak kodena kana master. Dina dunya idéal, pamekar bakal ngalakukeun ieu unggal sababaraha jam. Nyaéta, anjeun nyandak masalah leutik sareng ngahijikeun kana master. Sagalana hébat. Ieu naon narékahan pikeun. Sareng ieu kedah dilakukeun terus-terusan. Pas anjeun ngalakukeun hiji hal, anjeun langsung nempatkeun kana master.
Jeung pamekar anu nyieun hiji hal anu tanggung jawab naon manéhna dipigawé pikeun nyieun jalan jeung teu megatkeun nanaon. Ieu tempat carita tés biasana kaluar. Kami hoyong ngajalankeun sababaraha tés dina komitmen kami, dina ngahiji kami, pikeun mastikeun yén éta tiasa dianggo. Sareng ieu dimana Jenkins tiasa ngabantosan anjeun.
Tapi kalayan carita: hayu urang ngadamel parobihan sakedik, hayu tugas janten alit, hayu urang ngadamel masalah sareng langsung cobian kumaha waé ngalebetkeun kana master - teu aya Jenkins anu ngabantosan di dieu. Kusabab Jenkins ngan bakal nulungan anjeun ngajalankeun tés.
Anjeun tiasa ngalakukeun tanpa aranjeunna. Ieu moal menyakiti anjeun pisan. Kusabab tujuan prakna nyaéta ngukur sering-gancang, ku kituna henteu miceunan waktos anu ageung dina konflik anu bakal datang.
Hayu urang bayangkeun yén kusabab sababaraha alesan urang aya dina 2020 tanpa Internét. Sareng urang damel lokal. Urang teu boga Jenkins. Ieu sae. Anjeun masih tiasa teraskeun sareng ngadamel cabang lokal. Anjeun nulis sababaraha kode di dinya. Urang réngsé tugas dina 3-4 jam. Kami ngalih ka master, narik git, sareng ngahijikeun cabang kami di dinya. Siap. Upami anjeun sering ngalakukeun ieu, ucapan salamet, anjeun gaduh Integrasi Kontinyu!
Naon buktina di dunya modéren yén éta patut nyéépkeun énergi? Sabab sacara umum hese. Upami anjeun nyobian damel sapertos kieu, anjeun bakal ngartos yén sababaraha perencanaan ayeuna bakal dipangaruhan, anjeun kedah nyéépkeun waktos langkung seueur pikeun tugas-tugas anu rusak. Kusabab lamun ngalakukeun man ..., mangka anjeun moal bisa datang ka istilah gancang sarta, sasuai, bakal meunang kana kasulitan. Anjeun moal aya deui latihan.
Sarta eta bakal mahal. Éta moal tiasa dianggo langsung ti énjing nganggo Integrasi Kontinyu. Éta bakal nyandak anjeun sadayana waktos anu lami pisan pikeun ngabiasakeun éta, éta bakal nyandak anjeun waktos anu lami pisan pikeun ngabiasakeun tugas-tugas anu terurai, éta bakal peryogi waktos anu lami pisan pikeun ngabiasakeun deui prakték ulasan, upami anjeun ngagaduhan. . Kusabab tujuan urang nyaéta pikeun ngalembereh dinten ieu. Sareng upami anjeun ngalakukeun ulasan dina tilu dinten, maka anjeun ngagaduhan masalah sareng Integrasi Kontinyu henteu tiasa dianggo pikeun anjeun.
Tapi naha urang ngagaduhan bukti anu relevan ayeuna anu nyarioskeun ka urang yén investasi dina prakték ieu asup akal?
Hal kahiji anu aya dina pikiran kuring nyaéta State of DevOps. Ieu mangrupikeun panilitian anu dilakukeun ku budak lalaki salami 7 taun. Ayeuna maranehna ngalakukeun eta salaku hiji organisasi bebas, tapi dina Google.
Jeung ulikan 2018 maranéhanana némbongkeun korelasi antara pausahaan nu nyoba ngagunakeun cabang pondok-cicing nu ngahijikeun gancang, integrasi remen, sarta ngabogaan indikator kinerja IT hadé.
Naon indikator ieu? Ieu mangrupikeun métrik 4 anu aranjeunna candak ti sadaya perusahaan dina angkétna: frékuénsi panyebaran, waktos kalungguhan pikeun parobihan, waktos mulangkeun jasa, ngarobih tingkat gagalna.
Sareng, mimitina, aya korelasi ieu, urang terang yén perusahaan anu sering ngukur gaduh métrik anu langkung saé. Jeung maranéhna boga division pausahaan kana sababaraha kategori: ieu pausahaan slow nu ngahasilkeun hal lalaunan, pamaen sedeng, pamaen luhur jeung elit. The elit anu Netflix, Amazon, nu super gancang, ngalakukeun sagalana gancang, beautifully jeung éfisién.
Carita kadua, anu kajantenan sabulan katukang. Radar Téhnologi gaduh tulisan anu saé ngeunaan Gitflow. Gitflow béda ti anu sanés sabab cabangna umurna panjang. Aya dahan pelepasan anu hirup pikeun lila, sarta dahan ciri anu ogé hirup pikeun lila. Prakték ieu di Technology Radar parantos ngalih ka HOLD. Naha? Kusabab jalma nyanghareupan nyeri integrasi.
Upami cabang anjeun hirup kanggo waktos anu lami, éta macét, janten busuk, sareng urang mimitian nyéépkeun waktos langkung seueur pikeun ngalakukeun sababaraha parobihan.
Sareng nembe panulis Gitflow nyarios yén upami tujuan anjeun nyaéta Integrasi Kontinyu, upami tujuan anjeun nyaéta yén anjeun badé ngagulung sabisa-bisa, maka Gitflow mangrupikeun ide anu goréng. Anjeunna misah ditambahkeun kana artikel nu lamun boga backend mana anjeun bisa narékahan pikeun ieu, lajeng Gitflow superfluous pikeun anjeun, sabab Gitflow bakal ngalambatkeun anjeun turun, Gitflow bakal nyieun masalah pikeun anjeun kalawan integrasi.
Ieu sanés hartosna yén Gitflow goréng sareng henteu kedah dianggo. Ieu keur kasempetan séjén. Salaku conto, nalika anjeun kedah ngadukung sababaraha vérsi jasa atanapi aplikasi, nyaéta dimana anjeun peryogi dukungan pikeun waktos anu lami.
Tapi upami anjeun ngobrol sareng jalma anu ngadukung jasa sapertos kitu, anjeun bakal nguping seueur nyeri ngeunaan kanyataan yén versi ieu 3.2, nyaéta 4 sababaraha bulan kapengker, tapi perbaikan ieu henteu kalebet dina éta sareng ayeuna, pikeun ngajantenkeun, Anjeun kudu nyieun sababaraha parobahan. Sareng ayeuna aranjeunna macét deui, sareng ayeuna aranjeunna nuju ngulik saminggu nyobian ngalaksanakeun sababaraha fitur énggal.
Salaku Alexander Kovalev neuleu nyatet dina obrolan, korelasi teu sarua sabab musabab. Ieu leres. Nyaéta, teu aya sambungan langsung anu upami anjeun gaduh Integrasi Kontinyu, maka sadaya métrik bakal saé. Tapi aya korelasi anu positip yén upami hiji mangrupikeun hiji, maka kamungkinan anu sanésna ogé. Teu kanyataan, tapi paling dipikaresep. Éta ngan ukur korelasi.
Sigana mah urang geus ngalakukeun hiji hal, sigana nu urang geus ngahiji, tapi kumaha urang bisa ngarti yén urang masih boga Continuous Integration, yén urang rada mindeng ngagabung?
Jez Humble mangrupikeun panulis Buku Panduan, Akselerasi, situs wéb Continuous Delivery, sareng buku Continuous Delivery. Anjeunna nawiskeun tés ieu:
- Kode insinyur meunang ka master unggal dinten.
- Pikeun unggal komitmen anjeun ngajalankeun tés unit.
- Ngawangun dina master murag, éta dibereskeun dina ngeunaan 10 menit.
Anjeunna nyarankeun ngagunakeun tés sapertos ieu pikeun mastikeun yén anjeun ngagaduhan latihan anu cekap.
Kuring manggihan dimungkinkeun saeutik kontroversial. Hartina, lamun bisa ngalereskeun eta dina 10 menit, mangka anjeun boga Pamaduan Kontinyu, keur disada rada aneh, dina pamadegan mah, tapi ngajadikeun rasa. Naha? Kusabab upami anjeun sering beku, éta hartosna parobahan anjeun leutik. Upami parobihan anu alit hartosna ngawangun master anjeun rusak, maka anjeun tiasa mendakan conto gancang kusabab parobihanana leutik. Di dieu anjeun kungsi ngahiji leutik, 20-30 garis di dinya robah. Sareng, sasuai, anjeun tiasa gancang ngartos naon alesanana, sabab parobihanna alit, anjeun gaduh daérah anu alit pikeun milarian masalahna.
Komo lamun prod urang ragrag eta sanggeus release, mangka lamun urang boga prakték Continuous Integrasi, eta leuwih gampang pikeun urang pikeun meta, sabab parobahanana leutik. Leres, ieu bakal mangaruhan perencanaan. Ieu bakal menyakiti. Sareng, sigana, hal anu paling hese dina prakték ieu nyaéta ngabiasakeun ngarecah tugas, nyaéta, kumaha cara ngalakukeunana supados anjeun tiasa nyandak hiji hal sareng ngalakukeunana dina sababaraha jam sareng dina waktos anu sami lulus ulasan, upami anjeun gaduh hiji. Review mangrupakeun nyeri misah.
Tes unit ngan ukur asisten anu ngabantosan anjeun ngartos naha integrasi anjeun suksés sareng naha teu aya anu rusak. Dina pamanggih kuring, ieu ogé teu sagemblengna wajib, sabab ieu teu titik prakték.
Ieu mangrupikeun bubuka ringkes pikeun Integrasi Kontinyu. Éta sadayana aya dina prakték ieu. Abdi siap pikeun patarosan.
Kuring ngan bakal nyimpulkeun sakeudeung deui:
- Integrasi Kontinyu sanés Jenkins, sanés Gitlab.
- Ieu sanés alat, éta mangrupikeun prakték yén urang ngahijikeun kode urang kana master sagancangna.
- Kami ngalakukeun ieu pikeun ngahindarkeun nyeri anu ageung anu timbul nalika ngahiji di hareup, nyaéta, urang ngalaman sakedik nyeri ayeuna supados henteu ngalaman deui di hareup. Éta sakabéh titik.
- Di sisi aya komunikasi ngaliwatan kode, tapi jarang pisan ningali ieu, tapi ieu oge naon eta dirancang pikeun.
patarosan
Naon anu kudu dipigawé kalayan tugas non-decomposed?
Ngarecah. Naon masalahna? Dupi anjeun masihan conto yen aya tugas jeung teu decomposed?
Aya tugas anu teu tiasa diuraikan tina kecap "lengkep", contona, anu peryogi kaahlian anu jero pisan sareng anu leres-leres tiasa direngsekeun salami sabulan pikeun ngahontal hasil anu tiasa dicerna.
Upami kuring ngartos anjeun leres, maka aya sababaraha tugas anu ageung sareng rumit, anu hasilna bakal katingali ngan ukur sabulan?
Sumuhun leres. Leres, éta bakal tiasa ngira-ngira hasilna henteu langkung awal ti sabulan.
muhun. Sacara umum ieu teu masalah. Naha? Kusabab dina hal ieu, nalika urang ngobrol ngeunaan twigs, urang teu ngobrol ngeunaan twigs kalawan fitur. Fitur tiasa ageung sareng rumit. Éta tiasa mangaruhan sajumlah ageung komponén. Sareng panginten urang henteu tiasa ngalakukeunana lengkep dina hiji cabang. Ieu sae. Urang ngan perlu megatkeun carita ieu. Lamun hiji fitur teu sagemblengna siap, ieu lain hartosna yén sababaraha potongan kode na teu bisa dihijikeun. Anjeun nambihan, sebutkeun, migrasi sareng aya sababaraha tahapan dina fitur éta. Anggap anjeun gaduh panggung - ngadamel migrasi, tambahkeun metode énggal. Sareng anjeun parantos tiasa ngukur hal-hal ieu unggal dinten.
muhun. Naon gunana teras?
Naon gunana maehan hal leutik unggal poe?
Sumuhun.
Mun aranjeunna megatkeun hiji hal, anjeun ningali eta langsung. Anjeun gaduh sapotong leutik nu geus pegat hal, éta gampang pikeun anjeun ngalereskeun eta. Intina nyaéta ngahijikeun sapotong leutik ayeuna langkung gampang tibatan ngahijikeun anu ageung dina sababaraha minggu. Sareng titik katilu nyaéta insinyur sanés bakal tiasa dianggo sareng versi kode ayeuna. Aranjeunna baris nempo yén sababaraha migrasi geus ditambahkeun di dieu, lajeng sababaraha métode geus mucunghul yén maranéhna ogé bisa hayang ngagunakeun. Sarerea bakal ningali naon anu lumangsung dina kode anjeun. Pikeun tilu hal ieu latihan dilakukeun.
Hatur nuhun, masalahna ditutup!
(Oleg Soroka) Dupi abdi tiasa nambihan? Anjeun nyarios sadayana leres, kuring ngan ukur hoyong nambihan hiji frasa.
Janten
Kalayan Integrasi Kontinyu, kode dihijikeun kana cabang umum sanés nalika fiturna tos siap, tapi nalika wangunanna lirén rusak. Sareng anjeun aman tiasa komitmen pikeun ngawasaan saloba kali sadinten anu dipikahoyong. Aspék kadua nyaéta upami kusabab sababaraha alesan anjeun henteu tiasa ngarobih tugas bulanan kana tugas sahenteuna tilu dinten, kuring jempé sakitar tilu jam, maka anjeun gaduh masalah anu ageung. Sareng kanyataan yén anjeun henteu gaduh Integrasi Kontinyu mangrupikeun pangsaeutikna tina masalah ieu. Ieu ngandung harti yén anjeun gaduh masalah sareng arsitéktur sareng prakték rékayasa enol. Kusabab sanajan ieu panalungtikan, mangka dina sagala hal kudu dirumuskeun dina wangun hipotésis atawa siklus.
Urang ngobrol ngeunaan 4 métrik anu ngabédakeun perusahaan anu suksés sareng anu katinggaleun. Urang masih kedah hirup ningali 4 métrik ieu. Upami tugas rata-rata anjeun peryogi sabulan kanggo réngsé, maka kuring bakal difokuskeun métrik ieu heula. Abdi badé nurunkeun kana 3 dinten heula. Sareng saatos éta kuring mimiti mikir ngeunaan Kontinyu.
Naha kuring leres-leres ngartos anjeun yén anjeun mikir yén sacara umum henteu aya gunana pikeun investasi dina prakték rékayasa upami aya tugas anu peryogi sabulan kanggo réngsé?
Anjeun gaduh Integrasi Kontinyu. Sareng aya topik sapertos anu dina 10 menit anjeun tiasa ngalereskeun ngalereskeun atanapi ngagulung deui. Bayangkeun anjeun ngagulung kaluar. Leuwih ti éta, anjeun malah boga deployment kontinyu, Anjeun digulung kaluar prod na ngan lajeng noticed nu aya lepat. Sareng anjeun kedah ngagulung deui, tapi anjeun parantos migrasi database anjeun. Anjeun geus boga schema database tina versi salajengna, komo deui, anjeun ogé kungsi sababaraha jenis cadangan, sarta data ieu ogé ditulis aya.
Sareng alternatif naon anu anjeun gaduh? Upami anjeun ngagulung deui kodeu, éta moal tiasa dianggo deui sareng database anu diropéa ieu.
Dasar ukur maju, enya.
Jalma anu boga prakték rékayasa goréng paling dipikaresep teu maca buku kandel ngeunaan ... boh. Naon anu kudu dipigawé kalayan cadangan? Upami anjeun malikkeun tina cadangan, éta hartosna anjeun kaleungitan data anu anjeun kumpulkeun salami waktos éta. Contona, urang digawé salila tilu jam jeung versi anyar tina database, pamaké didaptarkeun aya. Anjeun nolak cadangan heubeul sabab skéma teu jalan kalawan versi anyar, jadi Anjeun geus leungit pamaké ieu. Jeung maranéhna sugema, aranjeunna sumpah.
Pikeun ngawasaan prak-prakan anu lengkep anu ngadukung Integrasi Kontinyu sareng Pangiriman Kontinyu, henteu cekap ngan ukur diajar nyerat.... Firstly, aya bisa jadi loba di antarana, éta bakal praktis. Tambih Deui, aya seueur prakték sanés sapertos Ilmiah. Aya prakték sapertos kitu, GitHub ngapopulérkeun éta dina hiji waktos. Ieu nalika anjeun gaduh duanana kode heubeul jeung kode anyar ngajalankeun dina waktos anu sareng. Ieu mun anjeun nyieun hiji fitur tacan beres, tapi bisa balik sababaraha nilai: boh salaku fungsi atawa salaku API Rest. Anjeun ngaéksekusi duanana kode anyar jeung kode heubeul, sarta ngabandingkeun bédana antara aranjeunna. Tur upami aya bédana, mangka anjeun log acara ieu. Ku cara kieu anjeun terang yén anjeun gaduh fitur énggal anu siap digulung dina luhureun anu lami upami anjeun teu acan gaduh bédana antara dua pikeun waktos anu tangtu.
Aya ratusan prakték sapertos kitu. Abdi nyarankeun dimimitian ku ngembangkeun transbase. Anjeunna henteu 100% dina Integrasi Kontinyu, tapi praktékna sami, hiji henteu tiasa hirup saé tanpa anu sanés.
Naha anjeun masihan pamekaran transbase sabagé conto dimana anjeun tiasa ningali prakték atanapi anjeun nyarankeun jalma-jalma mimitian nganggo debelopment transbase?
Tingali, sabab moal tiasa dianggo. Pikeun ngagunakeunana, anjeun kedah seueur maca. Sareng nalika hiji jalma naroskeun: "Naon anu kedah dilakukeun sareng fitur anu peryogi sabulan, éta hartosna anjeunna henteu acan maca ngeunaan pangwangunan transbase." Abdi teu bakal nyarankeun eta ngan acan. Abdi mamatahan ngan fokus kana topik kumaha leres arsitéktur ngarecah tugas ageung kana anu langkung alit. Ieu hakekat dékomposisi.
Dékomposisi mangrupa salah sahiji parabot arsiték. Urang mimiti ngalakukeun analisa, teras dékomposisi, teras sintésis, teras integrasi. Sareng ieu kumaha sadayana dianggo pikeun urang. Sareng urang masih kedah tumuh kana Integrasi Kontinyu ngaliwatan dékomposisi. Patarosan timbul dina tahap kahiji, sarta kami geus ngobrol ngeunaan tahap kaopat, i.e. beuki sering urang ngalakukeun integrasi, anu hadé. Masih awal teuing pikeun ngalakukeun ieu; éta hadé pikeun ngirangan monolit anjeun heula.
Anjeun kedah ngagambar sababaraha panah sareng kuadrat dina sababaraha diagram. Anjeun teu tiasa nyarios yén ayeuna kuring bakal nunjukkeun diagram arsitéktur aplikasi énggal sareng nunjukkeun hiji pasagi, di jerona aya tombol héjo pikeun aplikasi éta. Dina sagala hal, bakal aya deui kuadrat jeung panah. Unggal diagram kuring nempo boga leuwih ti hiji. Sareng dékomposisi, bahkan dina tingkat répréséntasi grafis, parantos lumangsung. Ku alatan éta, kuadrat bisa dijieun mandiri. Upami henteu, maka kuring gaduh patarosan ageung pikeun arsitek.
Aya patarosan tina obrolan: "Upami ulasan wajib sareng peryogi waktos anu lami, panginten sadinten atanapi langkung?"
Anjeun gaduh masalah sareng latihan. Resensi teu kedah lepas sadinten atanapi langkung. Ieu carita sarua jeung patarosan saméméhna, ngan saeutik lemes. Upami ulasan lumangsung sadinten, teras paling dipikaresep ulasan ieu bakal aya parobihan anu ageung. Ieu ngandung harti yén éta perlu dijieun leutik. Dina pamekaran transbase, anu disarankeun Oleg, aya carita anu disebut ulasan kontinyu. Gagasanna nyaéta yén urang ngadamel pamenta tarik anu sakedik waé, sabab urang narékahan pikeun ngahijikeun terus-terusan sareng sakedik-sakedik. Janten pamundut tarik ngarobih hiji abstraksi atanapi 10 garis. Hatur nuhun kana ulasan ieu, kami peryogi sababaraha menit.
Lamun review nyokot sapoé atawa leuwih, aya nu salah. Anu mimiti, anjeun tiasa gaduh sababaraha masalah sareng arsitéktur. Atawa ieu sapotong badag kode, 1 garis, contona. Atanapi arsitéktur anjeun rumit pisan sahingga jalma henteu tiasa ngartos. Ieu masalah rada gigir, tapi ogé kudu direngsekeun. Panginten henteu peryogi ulasan pisan. Urang ogé kudu mikir ngeunaan ieu. Review mangrupikeun hal anu ngalambatkeun anjeun. Cai mibanda kaunggulan na sacara umum, tapi anjeun kudu ngarti naha anjeun ngalakukeun eta. Ieu cara pikeun anjeun gancang nepikeun informasi, ieu cara pikeun anjeun nyetel sababaraha standar internal atanapi naon? Naha anjeun peryogi ieu? Kusabab resensi kedah dilakukeun gancang-gancang atanapi dibatalkeun sadayana. Éta sapertos pamekaran transbase - caritana saé pisan, tapi ngan ukur pikeun lalaki dewasa.
Ngeunaan 4 métrik, kuring masih bakal nyarankeun ngahapus aranjeunna pikeun ngartos naon anu nyababkeun. Tingali dina angka, tingali gambar, kumaha goréng sagalana.
(Dmitry) Abdi siap lebet kana sawala ngeunaan ieu sareng anjeun. Angka sareng métrik sadayana saé, praktékna saé. Tapi anjeun kedah ngartos naha bisnis peryogi éta. Aya usaha anu henteu peryogi laju parobihan sapertos kitu. Kuring terang perusahaan dimana parobihan teu tiasa dilakukeun unggal 15 menit. Sareng sanés kusabab aranjeunna parah pisan. Ieu mangrupikeun siklus kahirupan. Sareng pikeun ngadamel fitur cabang, fitur toggle, anjeun peryogi pangaweruh anu jero.
Éta hésé. Upami anjeun hoyong maca carita ngeunaan fitur toggle sacara langkung rinci, kuring nyarankeun pisan . Sareng aya tulisan anu saé ku Martin Fowler ngeunaan fitur toggle: jinis naon anu aya, siklus kahirupan, jsb. Fitur toggle pajeulit.
Sareng anjeun masih teu acan ngajawab patarosan: "Naha Jenkins diperyogikeun atanapi henteu?"
Jenkins henteu diperlukeun dina sagala hal bener. Serius sanaos, alat: Jenkins, Gitlab bakal ngajantenkeun anjeun genah. Anjeun bakal ningali yén rakitan dirakit atanapi henteu dirakit. Aranjeunna tiasa ngabantosan anjeun, tapi aranjeunna moal masihan anjeun latihan. Aranjeunna ukur tiasa masihan anjeun bunderan - Ok, moal Ok. Teras, upami anjeun ogé nyerat tés, sabab upami teu aya tés, maka éta ampir teu aya gunana. Ku alatan éta, diperlukeun sabab leuwih merenah, tapi sacara umum bisa hirup tanpa eta, anjeun moal leungit loba.
Nyaéta, upami anjeun ngagaduhan prakték, naha éta hartosna anjeun henteu peryogi?
Éta leres. Abdi nyarankeun test Jez Humble. Aya kuring boga sikep ambivalent nuju titik panungtungan. Tapi sacara umum, upami anjeun gaduh tilu hal, anjeun ngagabung terus-terusan, anjeun ngajalankeun tés dina komitmen dina master, anjeun gancang ngalereskeun ngawangun dina master, teras panginten anjeun henteu peryogi anu sanés.
Bari ngadagoan patarosan ti pamilon, abdi gaduh patarosan. Kami ngan ngobrol ngeunaan kode produk. Dupi anjeun dipaké pikeun kode infrastruktur? Naha éta kode anu sami, naha éta gaduh prinsip anu sami sareng siklus kahirupan anu sami, atanapi aya siklus sareng prinsip hirup anu béda? Biasana, nalika sadayana ngobrol ngeunaan Integrasi sareng Pangembangan Berkelanjutan, sadayana hilap yén aya ogé kode infrastruktur. Sareng akhir-akhir ieu langkung seueur deui. Sareng kedah sadayana aturan ieu dibawa ka dinya?
Teu malah nu sakuduna, éta bakal jadi hébat sabab bakal nyieun hirup leuwih gampang dina cara nu sarua. Pas urang dianggo kalayan kode, teu kalawan Aksara bash, tapi urang boga kode normal.
Eureun, eureun, skrip bash ogé kode. Tong némpél ka asih baheula.
Oke, kuring moal ngintip kenangan anjeun. Kuring boga henteu resep pribadi pikeun bash. Ngarecah awon jeung pikasieuneun sadaya waktu. Sarta eta mindeng ngarecah unpredictably, naha kuring teu resep eta. Tapi oke, hayu urang nyebutkeun anjeun boga kode bash. Panginten kuring henteu ngartos sareng aya kerangka uji normal di luar. Abdi ngan teu terang. Sarta kami meunang kauntungan anu sarua.
Pas urang damel sareng infrastruktur salaku kode, urang nampi sagala masalah anu sami sareng pamekar. Sababaraha bulan kapengker, abdi encountered kaayaan dimana batur sapagawean dikirim kuring pamundut tarikan pikeun 1 garis dina bash. Sareng anjeun nongkrong di ulasan salami 000 jam. Masalah anu sami timbul. Ieu masih kode. Sareng éta masih kolaborasi. Kami nyangkut kana pamundut tarik sareng kami nyangkut kanyataan yén urang ngabéréskeun konflik ngahiji anu sami dina bash anu sami, contona.
Kuring ayeuna pisan aktip ningali sakabeh hal ieu dina programming infra paling geulis. Kuring ayeuna geus dibawa Pulumi kana infrastruktur. Ieu programming dina formulir purest na. Aya éta malah nicer, sabab kuring boga sagala kamampuhan basa programming, i.e. Kuring dijieun toggle geulis kaluar tina bulao jeung ifs sarua jeung sagalana rupa. Hartina, robahna mah geus aya dina juragan. Sadayana parantos tiasa ningali anjeunna. Insinyur anu sanés terang ngeunaan éta. Eta geus dipangaruhan hal aya. Nanging, éta henteu diaktipkeun pikeun sadaya infrastruktur. Dihurungkeun pikeun bangku uji kuring, contona. Ku alatan éta, pikeun ngajawab patarosan anjeun deui, perlu. Éta ngagampangkeun kahirupan pikeun urang, salaku insinyur damel sareng kode, dina cara anu sami.
Lamun batur boga patarosan?
Abdi gaduh patarosan. Abdi hoyong neraskeun diskusi sareng Oleg. Sacara umum, kuring nyangka yén anjeun leres, yén upami tugas peryogi sabulan kanggo réngsé, maka anjeun gaduh masalah sareng arsitéktur, anjeun gaduh masalah sareng analisa, dékomposisi, perencanaan, jsb.. Tapi kuring ngarasa yén upami anjeun ngamimitian nyobian hirup nurutkeun Pamaduan Kontinyu, mangka anjeun bakal ngawitan ngabenerkeun nyeri kalawan tata, sabab moal meunang jauh ti dinya mana sejenna.
(Oleg) Leres, leres. Prakték ieu tiasa dibandingkeun dina usaha naon waé prakték ngarobah budaya anu serius. Hal anu paling hese pikeun diatasi nyaéta kabiasaan, khususna kabiasaan anu goréng. Sareng upami pikeun ngalaksanakeun prakték ieu, parobihan anu serius dina kabiasaan jalma-jalma di sabudeureun anjeun diperyogikeun: pamekar, manajemén, manajer produksi, teras kejutan ngantosan anjeun.
kejutan naon bisa aya? Anggap anjeun mutuskeun yén anjeun bakal ngahijikeun langkung sering. Sareng anjeun gaduh sababaraha hal anu aya hubunganana sareng integrasi, contona, artefak. Sareng di perusahaan anjeun, contona, aya kabijakan yén unggal artefak kedah dipertanggungjawabkeun ku sababaraha cara dina sababaraha jinis sistem panyimpen artefak. Sareng peryogi sababaraha waktos. Hiji jalma kedah pariksa kotak yén anjeunna, salaku manajer sékrési, parantos nguji artefak ieu pikeun mastikeun éta siap dileupaskeun dina produksi. Lamun nyokot 5-10-15 menit, tapi anjeun ngalakukeun perenah saminggu sakali, lajeng méakkeun satengah jam saminggu sakali nyaéta pajeg leutik.
Upami anjeun ngalakukeun Integrasi Kontinyu 10 kali sadinten, teras 10 kali kedah dikali 30 menit. Sarta ieu ngaleuwihan jumlah waktu gawé manajer release ieu. Anjeunna ngan meunang capé ngalakonan eta. Aya biaya tetep pikeun sababaraha prakték. Éta hungkul.
Sareng anjeun kedah ngabatalkeun aturan ieu supados anjeun henteu deui ngalakukeun sampah sapertos kitu, nyaéta anjeun henteu sacara manual napelkeun gelar pikeun pakait sareng hiji hal. Anjeun ngandelkeun sapinuhna kana sababaraha set otomatis tina tés kesiapan.
Tur upami Anjeun salah butuh bukti ti batur, ku kituna boss ditandatanganan eta, sarta anjeun teu meunang kana produksi tanpa Vasya nyebutkeun yen anjeunna ngidinan eta, jsb - kabeh omong kosong ieu meunang di jalan praktisi nu. Kusabab upami aya sababaraha kagiatan anu aya hubunganana sareng pajak, maka sadayana ningkat 100 kali. Ku alatan éta, shift bakal mindeng teu disambut ku kabagjaan ku sarerea. Sabab kabiasaan jalma hésé dirobah.
Nalika hiji jalma ngalakukeun pagawéan anu biasa, anjeunna ngalakukeunana ampir tanpa mikir. beban kognitif nya nol. Anjeunna ngan ukur maén sareng éta, anjeunna parantos gaduh daptar pariksa dina sirahna, anjeunna parantos sarébu kali. Sareng pas anjeun sumping sareng nyarios ka anjeunna: "Hayu urang ngabatalkeun prakték ieu sareng ngenalkeun anu énggal dimimitian Senén," pikeun anjeunna janten beban kognitif anu kuat. Sarta datang ka dulur sakaligus.
Ku alatan éta, hal pangbasajanna, sanajan teu sadaya jelema bisa nanggung méwah ieu, tapi ieu mah sok ngalakukeun, ieu di handap. Upami hiji proyék anyar dimimitian, teras biasana sadayana prakték anu teu acan diuji langsung dijejalkeun kana proyék ieu. Bari proyék ieu ngora, urang teu bener risiko nanaon. Teu acan aya Prod, teu aya anu ngancurkeun. Ku alatan éta, éta bisa dipaké salaku latihan. pendekatan ieu jalan. Tapi henteu sadayana perusahaan ngagaduhan kasempetan pikeun ngamimitian proyék sapertos kitu sering. Sanaos ieu ogé rada anéh, sabab ayeuna parantos aya transformasi digital anu lengkep, sadayana kedah ngaluncurkeun ékspérimén supados tiasa ngiringan pesaing.
Di dieu anjeun datang ka kacindekan yén anjeun mimitina kudu boga pamahaman naon kudu maneh mun. Dunya henteu idéal, sareng prod ogé henteu idéal.
Sumuhun, hal ieu interconnected.
Usaha ogé henteu salawasna ngartos yén aranjeunna kedah jalan ieu.
Aya kaayaan dimana teu aya parobahan anu mungkin. Ieu kaayaan dimana aya leuwih tekanan dina tim. Tim geus rada kaduruk kaluar. Manehna teu boga waktu luang pikeun percobaan nanaon. Aranjeunna dianggo dina fitur ti isuk nepi ka sore. Sareng manajemén gaduh fitur anu langkung sakedik. Beuki loba nu diperlukeun. Dina kaayaan kitu, teu aya parobahan anu mungkin. Tim ngan tiasa nyarios yén isukan urang bakal ngalakukeun anu sami sareng kamari, urang ngan ukur kedah ngadamel langkung seueur fitur. Dina hal ieu, teu aya transisi ka prakték naon waé anu mungkin. Ieu mangrupikeun kaayaan klasik nalika teu aya waktos pikeun ngasah kampak, tatangkalan kedah ditegor, janten aranjeunna dipotong ku kampak kusam. Henteu aya tips basajan di dieu.
(Dmitry) Kuring bakal maca klarifikasi tina obrolan: "Tapi urang peryogi seueur sinyalna tés dina tingkat anu béda. Sabaraha waktos anu dialokasikeun pikeun tés? Éta rada mahal sareng peryogi seueur waktos. ”
(Oleg) Ieu misconception Palasik. Kudu aya cukup tés pikeun anjeun yakin. Integrasi Kontinyu sanés mangrupikeun hal anu 100% tina tés dilakukeun heula sareng saatos anjeun ngamimitian nerapkeun prakték ieu. Pamaduan kontinyu ngirangan beban kognitif anjeun kusabab kanyataan yén unggal parobihan anu anjeun tingali ku panon anjeun atra pisan yén anjeun ngartos naha éta bakal ngarobih atanapi henteu, sanaos tanpa tés. Anjeun tiasa gancang nguji ieu dina sirah anjeun sabab parobahanana leutik. Sanaos anjeun ngan ukur gaduh panguji manual, éta ogé langkung gampang pikeun aranjeunna. Anjeun ngagulung sareng nyarios: "Tingali, aya anu rusak?" Aranjeunna pariksa sareng nyarios, "Henteu, teu aya anu rusak." Kusabab tester weruh dimana néangan. Anjeun gaduh hiji komitmen pakait sareng hiji sapotong kode. Sarta ieu dieksploitasi ku kabiasaan husus.
Di dieu anjeun, tangtosna, embellished.
(Dmitry) Abdi henteu satuju di dieu. Aya prakték - pamekaran anu didorong ku uji, anu bakal nyalametkeun anjeun tina ieu.
(Oleg) Nya, kuring henteu acan dugi ka titik éta. Ilusi kahiji nyaéta yén anjeun kedah nyerat 100% tina tés atanapi anjeun henteu kedah ngalakukeun Integrasi Kontinyu pisan. Éta henteu leres. Ieu dua prakték paralel. Sareng aranjeunna henteu langsung gumantung. Liputan tés anjeun kedah optimal. Optimal - ieu ngandung harti yén anjeun sorangan yakin yén kualitas master di mana master anjeun tetep sanggeus komitmen ngidinan Anjeun pikeun confidently pencét tombol "Nyebarkeun" dina malem Jumaah mabok. Kumaha anjeun ngahontal ieu? Ngaliwatan review, ngaliwatan sinyalna, ngaliwatan monitoring alus.
Ngawaskeun anu saé teu tiasa dibédakeun tina tés. Upami anjeun ngajalankeun tés sakali dina pre prod, teras aranjeunna pariksa sadaya skrip pangguna anjeun sakali sareng éta. Tur upami Anjeun salah ngajalankeun aranjeunna dina loop sajajalan, teras ieu sistem monitoring deployed Anjeun, nu endlessly nguji sagalana - naha éta nabrak atanapi henteu. Dina hal ieu, hijina bédana nyaéta naha éta dipigawé sakali atawa dua kali. Hiji set pohara alus tina tés ... ngajalankeun endlessly, ieu ngawaskeun. Sareng pangawasan anu leres kedah sapertos kieu.
Ku alatan éta, kumaha kahayang anjeun bakal ngahontal kaayaan ieu nalika anjeun siap on Jumaah soré jeung balik ka imah téh patarosan sejen. Meureun anjeun ngan hiji scumbag wani.
Hayu urang balik saeutik ka Continuous Integration. Urang lumpat kana prakték kompléks rada béda.
Sareng ilusi anu kadua nyaéta MVP, saurna, kedah dilakukeun gancang, janten tés henteu diperyogikeun pisan. Teu tangtu ku cara éta. Kanyataanna nyaéta nalika anjeun nyerat carita pangguna dina MVP, anjeun tiasa ngembangkeun éta dina bal, nyaéta, anjeun nguping yén aya sababaraha jinis carita pangguna sareng langsung lumpat ka kodeu, atanapi anjeun tiasa damel nganggo TDD. Sareng numutkeun TDD, sakumaha prakték nunjukkeun, éta henteu peryogi langkung lami, nyaéta tés mangrupikeun efek samping. Prakték TDD sanés ngeunaan tés. Sanaos anu disebut Pangembangan Didorong Tes, éta sanés ngeunaan tés. Ieu ogé rada pendekatan arsitéktur. Ieu mangrupikeun pendekatan pikeun nyerat naon anu diperyogikeun sareng henteu nyerat anu henteu diperyogikeun. Ieu prakték fokus kana iterasi salajengna pamikiran anjeun dina hal nyiptakeun arsitéktur aplikasi.
Ku alatan éta, teu jadi gampang meunang leupas tina ilusi ieu. MVP sareng tés henteu saling bertentangan. Malah, sabalikna, lamun ngalakukeun MVP ngagunakeun latihan TDD, mangka anjeun bakal ngalakukeun eta hadé tur gancang ti lamun ngalakukeun eta tanpa latihan pisan, tapi dina bal.
Ieu mangrupikeun ide anu teu jelas sareng rumit. Nalika anjeun nguping yén ayeuna kuring bakal nyerat langkung seueur tés sareng dina waktos anu sami kuring bakal ngalakukeun anu langkung gancang, sigana henteu cekap.
(Dmitry) Seueur jalma di dieu, nalika aranjeunna nyauran MVP, jalma-jalma teuing puguh nyerat anu normal. Sarta ieu masih hal béda. Teu perlu ngarobah MVP kana sababaraha hal goréng nu teu jalan.
Sumuhun, leres, anjeun leres.
Lajeng dumadakan MVP di prod.
Salami-lamina.
Sareng TDD disada teu biasa nalika anjeun nguping yén anjeun nyerat tés sareng sigana ngalakukeun langkung seueur padamelan. Ieu hurung pisan aneh, tapi dina kanyataanana tétéla leuwih gancang sarta prettier cara kieu. Nalika anjeun nyerat tés, anjeun parantos mikir pisan dina sirah anjeun ngeunaan naon kode anu bakal disebat sareng kumaha, kitu ogé kabiasaan naon anu urang ngarepkeun. Anjeun teu ngan nyebutkeun kuring nulis sababaraha fungsi sarta ngalakukeun hal. Mimitina anjeun ngira yén anjeunna ngagaduhan kaayaan sapertos kitu, anjeunna bakal disauran ku cara sapertos kitu. Anjeun nutupan ieu ku tés sareng ti ieu anjeun ngartos kumaha antarmuka anjeun bakal katingali dina kode anjeun. Ieu boga dampak badag dina arsitektur. Kode anjeun otomatis janten langkung modular, sabab mimitina anjeun nyobian ngartos kumaha anjeun bakal nguji éta, sarta ngan lajeng nulis eta.
Naon anu lumangsung ka kuring kalawan TDD éta di sawatara titik kuring hired a mentor Ruby nalika kuring masih programmer Ruby. Sareng anjeunna nyarios: "Hayu urang lakukeun dumasar kana TDD." Kuring mikir: "Damn, ayeuna kuring kedah nyerat tambahan." Sarta kami sapuk yén dina dua minggu kuring bakal nulis sagala kode gawé di Python maké TDD. Saatos dua minggu, kuring sadar yén kuring henteu hoyong uih deui. Saatos dua minggu nyobian nerapkeun ieu di mana waé, anjeun sadar kumaha gampangna pikeun anjeun ngan ukur mikir. Tapi ieu henteu écés, janten kuring nyarankeun ka sadayana yén upami anjeun gaduh perasaan yén TDD sesah, nyéépkeun waktos sareng teu perlu, cobian nempelkeun éta ngan ukur dua minggu. Dua éta cukup pikeun kuring.
(Dmitry) Urang tiasa ngalegaan ide ieu tina sudut pandang operasi infrastruktur. Sateuacan urang ngajalankeun nanaon anyar, urang ngalakukeun monitoring lajeng ngajalankeun. Dina hal ieu, ngawaskeun janten tés normal pikeun urang. Tur aya ngembangkeun ngaliwatan monitoring. Tapi ampir sadayana nyarios yén éta panjang, kuring puguh, kuring ngadamel draf samentawis. Upami urang parantos ngawaskeun normal, urang ngartos kaayaan sistem CI. Jeung sistem CI boga loba ngawaskeun. Kami ngartos kaayaan sistem, kami ngartos naon anu aya di jerona. Sareng nalika pangwangunan, urang ngan ukur ngadamel sistem supados ngahontal kaayaan anu dipikahoyong.
prakték ieu geus dipikawanoh pikeun lila. Urang bahas ieu ngeunaan 4 sababaraha taun ka pengker. Tapi dina 4 taun praktis nanaon geus robah.
Tapi dina catetan ieu, kuring ngajukeun pikeun ngeureunkeun diskusi resmi.
Video (diselapkeun salaku unsur média, tapi pikeun sababaraha alesan henteu jalan):
sumber: www.habr.com