Talakayin natin kung bakit ang mga tool ng CI at CI ay ganap na magkaibang bagay.
Anong sakit ang nilalayong lutasin ng CI, saan nagmula ang ideya, ano ang mga pinakabagong kumpirmasyon na gumagana ito, kung paano maunawaan na mayroon kang kasanayan at hindi lamang naka-install na Jenkins.
Ang ideya ng paggawa ng isang ulat tungkol sa Patuloy na Pagsasama ay lumitaw isang taon na ang nakalilipas, nang ako ay pupunta para sa mga panayam at naghahanap ng trabaho. Nakausap ko ang 10-15 na kumpanya, isa lamang sa kanila ang malinaw na nakasagot kung ano ang CI at ipaliwanag kung paano nila napagtanto na wala sila nito. Ang natitira ay nagsasalita ng hindi maintindihan na walang kapararakan tungkol kay Jenkins :) Well, mayroon kaming Jenkins, ito ay bumubuo, CI! Sa panahon ng ulat, susubukan kong ipaliwanag kung ano talaga ang Continuous Integration at kung bakit may mahinang kaugnayan dito ang Jenkins at mga katulad na tool.
Kaya, ano ang kadalasang pumapasok sa isip mo kapag naririnig mo ang salitang CI? Iisipin ng karamihan ng mga tao ang Jenkins, Gitlab CI, Travis, atbp.
Kahit na i-google natin ito, bibigyan tayo ng mga tool na ito.
Kung pamilyar ka sa pagtatanong, pagkatapos kaagad pagkatapos ilista ang mga tool, sasabihin nila sa iyo na ang CI ay kapag bumuo at nagpatakbo ka ng mga pagsubok sa isang Pull Request para sa isang commit.
Ang Patuloy na Pagsasama ay hindi tungkol sa mga tool, hindi tungkol sa mga pagtitipon na may mga pagsubok sa isang sangay! Ang Continuous Integration ay ang pagsasagawa ng napakadalas na pagsasama ng bagong code at para gamitin ito, hindi na kailangang bakod ang Jenkins, GitLab, atbp.
Bago natin alamin kung ano ang hitsura ng isang ganap na CI, sumisid muna tayo sa konteksto ng mga taong nakaisip nito at nararamdaman ang sakit na sinusubukan nilang lutasin.
At nalutas nila ang sakit ng pagtutulungan bilang isang koponan!
Tingnan natin ang mga halimbawa ng mga paghihirap na kinakaharap ng mga developer kapag bumubuo sa mga koponan. Narito mayroon kaming isang proyekto, isang master branch sa git at dalawang developer.
At pumasok sila sa trabaho tulad ng dati nang nakasanayan ng lahat. Gumawa kami ng isang gawain sa grand scheme ng mga bagay, gumawa ng feature branch, at isinulat ang code.
Natapos ng isa ang feature nang mas mabilis at pinagsama ito sa master.
Ang pangalawa ay nangangailangan ng mas maraming oras, ito ay pinagsama sa ibang pagkakataon at nauwi sa isang salungatan. Ngayon, sa halip na isulat ang mga feature na kailangan ng negosyo, ginugugol ng developer ang kanyang oras at lakas sa paglutas ng mga salungatan.
Kung mas mahirap pagsamahin ang iyong feature sa isang karaniwang master, mas maraming oras ang ginugugol namin dito. At ipinakita ko ito sa isang medyo simpleng halimbawa. Ito ay isang halimbawa kung saan mayroon lamang 2 developer. Isipin kung 10 o 15 o 100 tao sa isang kumpanya ang sumulat sa isang repositoryo. Mababaliw ka para malutas ang lahat ng mga salungatan na ito.
Mayroong isang bahagyang naiibang kaso. Mayroon kaming master at ilang developer na gumagawa ng isang bagay.
Gumawa sila ng isang sanga.
Namatay ang isa, maayos ang lahat, naipasa niya ang gawain.
Ang pangalawang developer, samantala, ay nagbigay ng kanyang gawain. Sabihin nating ipinadala niya ito para sa pagsusuri. Maraming mga kumpanya ang may kasanayan na tinatawag na pagsusuri. Sa isang banda, ang pagsasanay na ito ay mabuti at kapaki-pakinabang, sa kabilang banda, ito ay nagpapabagal sa atin sa maraming paraan. Hindi na namin isasaalang-alang iyon, ngunit narito ang isang magandang halimbawa kung ano ang maaaring humantong sa isang masamang kuwento ng pagsusuri. Nagsumite ka ng pull request para sa pagsusuri. Wala nang magagawa ang developer. Ano ang sinisimulan niyang gawin? Nagsisimula siyang gumawa ng iba pang mga gawain.
Sa panahong ito, iba ang ginawa ng pangalawang developer.
Nakumpleto ng una ang ikatlong gawain.
At pagkaraan ng ilang mahabang panahon, nasubok ang kanyang pagsusuri, at sinusubukan niyang magkasundo. Kaya ano ang nangyayari? Nakakakuha ito ng malaking bilang ng mga salungatan. Bakit? Dahil habang nakabitin sa review ang kanyang pull request, marami nang nagbago sa code.
Bilang karagdagan sa kuwento na may mga salungatan, mayroong isang kuwento na may mga komunikasyon. Habang ang iyong thread ay nakabitin sa pagsusuri, habang ito ay naghihintay ng isang bagay, habang ikaw ay nagtatrabaho sa isang tampok sa loob ng mahabang panahon, hihinto ka sa pagsubaybay kung ano pa ang nagbabago sa code base ng iyong serbisyo. Marahil kung ano ang sinusubukan mong lutasin ngayon ay nalutas na kahapon at maaari kang gumawa ng ilang paraan at muling gamitin ito. Ngunit hindi mo ito makikita dahil palagi kang nagtatrabaho sa isang hindi napapanahong sangay. At ang hindi napapanahong sangay na ito ay palaging nagreresulta sa kailangan mong lutasin ang isang pagsasanib na salungatan.
Lumalabas na kung nagtatrabaho kami bilang isang koponan, ibig sabihin, hindi isang tao ang nanunuot sa repositoryo, ngunit 5-10 tao, kung gayon habang mas matagal na hindi namin idinagdag ang aming code sa master, lalo kaming nagdurusa dahil kailangan namin sa huli. isang bagay pagkatapos ay pagsamahin ito. At kung mas maraming mga salungatan ang mayroon kami, at ang mas lumang bersyon na pinagtatrabahuhan namin, mas maraming problema ang mayroon kami.
Ang paggawa ng isang bagay na magkasama ay masakit! Palagi kaming nagkakagulo.
Napansin ang problemang ito mahigit 20 taon na ang nakalilipas. Natagpuan ko ang unang pagbanggit ng pagsasanay ng Continuous Integration sa Extreme Programming.
Ang Extreme Programming ay ang unang maliksi na balangkas. Lumitaw ang pahina noong 96. At ang ideya ay gumamit ng ilang uri ng mga kasanayan sa programming, pagpaplano at iba pang mga bagay, upang ang pag-unlad ay maging flexible hangga't maaari, upang mabilis kaming makatugon sa anumang mga pagbabago o kinakailangan mula sa aming mga kliyente. At sinimulan nilang harapin ito 24 taon na ang nakakaraan, na kung gumawa ka ng isang bagay nang napakatagal at nasa gilid, pagkatapos ay gumugugol ka ng mas maraming oras dito dahil mayroon kang mga salungatan.
Ngayon ay susuriin natin ang pariralang "Patuloy na Pagsasama" nang paisa-isa. Kung direktang isasalin namin ito, makakakuha kami ng tuluy-tuloy na pagsasama. Ngunit kung gaano ito tuloy-tuloy ay hindi masyadong malinaw; ito ay napaka-discontinuous. Ngunit kung gaano kalaki ang pagsasama nito ay hindi rin masyadong halata.
At iyon ang dahilan kung bakit binibigyan kita ng mga panipi mula sa Extreme Programming ngayon. At pag-aralan natin ang dalawang salita nang magkahiwalay.
Pagsasama - Gaya ng nasabi ko na, sinisikap naming matiyak na gumagana ang bawat inhinyero sa pinakabagong bersyon ng code, nang sa gayon ay nagsusumikap siyang idagdag ang kanyang code nang madalas hangga't maaari sa isang karaniwang sangay, upang ang mga ito ay maliliit na sangay. Dahil kung malalaki sila, madali tayong ma-stuck sa merge conflicts sa loob ng isang linggo. Ito ay totoo lalo na kung mayroon tayong mahabang yugto ng pag-unlad tulad ng talon, kung saan umalis ang developer sa loob ng isang buwan upang i-cut ang ilang malaking feature. At siya ay maiipit sa yugto ng pagsasama sa napakahabang panahon.
Ang pagsasama ay kapag kinuha namin ang aming sangay at isinama ito sa master, pinagsama namin ito. Mayroong isang tunay na opsyon kapag kami ay isang transbase developer, kung saan kami ay nagsusumikap upang matiyak na agad kaming sumulat sa master nang walang anumang karagdagang mga sangay.
Sa pangkalahatan, ang pagsasama ay nangangahulugan ng pagkuha ng iyong code at pag-drag ito sa master.
Ano ang ibig sabihin dito ng salitang βtuloy-tuloyβ, ano ang tinatawag na pagpapatuloy? Ipinahihiwatig ng pagsasanay na nagsusumikap ang developer na isama ang kanyang code sa lalong madaling panahon. Ito ang kanyang layunin kapag nagsasagawa ng anumang gawain - upang makuha ang kanyang code sa master sa lalong madaling panahon. Sa isang perpektong mundo, gagawin ito ng mga developer bawat ilang oras. Iyon ay, kumuha ka ng isang maliit na problema at pagsamahin ito sa master. Lahat ay magaling. Ito ang iyong pinagsisikapan. At ito ay dapat gawin nang tuluy-tuloy. Sa sandaling gumawa ka ng isang bagay, agad mong inilagay ito sa master.
At ang developer na gumagawa ng isang bagay ay responsable para sa kung ano ang ginawa niya upang gumana ito at hindi masira ang anumang bagay. Dito karaniwang lumalabas ang kwento ng pagsubok. Gusto naming magpatakbo ng ilang pagsubok sa aming commit, sa aming merge, para matiyak na gumagana ito. At dito ka matutulungan ni Jenkins.
Ngunit sa mga kwento: gawin nating maliit ang mga pagbabago, hayaan nating maging maliit ang mga gawain, gumawa tayo ng problema at agad na subukang i-embed ito sa master - walang Jenkins ang makakatulong dito. Dahil tutulungan ka lang ni Jenkins na magpatakbo ng mga pagsubok.
Magagawa mo nang wala sila. Hindi ka sasaktan nito. Dahil ang layunin ng pagsasanay ay upang sukatin nang madalas hangga't maaari, upang hindi mag-aksaya ng isang malaking halaga ng oras sa anumang mga salungatan sa hinaharap.
Isipin natin na sa ilang kadahilanan ay nasa 2020 tayo nang walang Internet. At nagtatrabaho kami sa lokal. Wala kaming Jenkins. Ito ay mabuti. Maaari ka pa ring magpatuloy at gumawa ng lokal na sangay. Sumulat ka ng ilang code dito. Nakumpleto namin ang gawain sa loob ng 3-4 na oras. Lumipat kami sa master, gumawa ng git pull, at pinagsama ang aming sangay doon. handa na. Kung madalas mong gawin ito, binabati kita, mayroon kang Continuous Integration!
Anong katibayan sa modernong mundo ang nariyan na nagkakahalaga ng paggastos ng enerhiya? Dahil sa pangkalahatan ito ay mahirap. Kung susubukan mong gumawa ng ganito, mauunawaan mo na ang ilang pagpaplano ay maaapektuhan na, kailangan mong maglaan ng mas maraming oras sa mga nabubulok na gawain. Sapagkat kung gagawin mo ang tao..., kung gayon hindi ka mabilis na magkakasundo at, nang naaayon, malalagay sa gulo. Wala ka nang practice.
At ito ay magiging mahal. Hindi posible na gumana kaagad mula bukas gamit ang Continuous Integration. Kayong lahat ay aabutin ng napakatagal na panahon upang masanay, ito ay aabutin ng mahabang panahon upang masanay sa nabubulok na mga gawain, ito ay aabutin ng napakatagal na oras upang masanay sa muling paggawa ng pagsasanay sa pagsusuri, kung mayroon ka . Dahil ang layunin natin ay matunaw ito ngayon. At kung gagawa ka ng pagsusuri sa loob ng tatlong araw, magkakaroon ka ng mga problema at hindi gumagana para sa iyo ang Patuloy na Pagsasama.
Ngunit mayroon ba kaming anumang nauugnay na ebidensya sa ngayon na nagsasabi sa amin na ang pamumuhunan sa kasanayang ito ay may katuturan?
Ang unang pumasok sa isip ko ay State of DevOps. Ito ay isang pag-aaral na isinasagawa ng mga lalaki sa loob ng 7 taon. Ngayon ginagawa nila ito bilang isang independiyenteng organisasyon, ngunit sa ilalim ng Google.
At ang kanilang pag-aaral noong 2018 ay nagpakita ng ugnayan sa pagitan ng mga kumpanyang sumusubok na gumamit ng mga panandaliang sangay na mabilis na nagsasama, madalas na nagsasama, at may mas mahusay na mga tagapagpahiwatig ng pagganap ng IT.
Ano ang mga tagapagpahiwatig na ito? Ito ang 4 na sukatan na kinukuha nila mula sa lahat ng kumpanya sa kanilang mga questionnaire: dalas ng pag-deploy, oras ng pag-lead para sa mga pagbabago, oras para ibalik ang serbisyo, baguhin ang rate ng pagkabigo.
At, una, mayroong ganitong ugnayan, alam natin na ang mga kumpanyang madalas sumukat ay may mas mahusay na sukatan. At mayroon silang isang dibisyon ng mga kumpanya sa ilang mga kategorya: ito ay mga mabagal na kumpanya na gumagawa ng isang bagay na mabagal, medium performer, high performer at elite. Ang mga piling tao ay ang Netflix, Amazon, na napakabilis, ginagawa ang lahat nang mabilis, maganda at mahusay.
Ang pangalawang kuwento, na nangyari isang buwan lang ang nakalipas. May magandang artikulo ang Technology Radar tungkol sa Gitflow. Ang Gitflow ay naiiba sa lahat ng iba dahil ang mga sanga nito ay matagal nang nabubuhay. May mga release branch na nabubuhay nang mahabang panahon, at nagtatampok ng mga branch na nabubuhay din nang matagal. Ang kasanayang ito sa Technology Radar ay lumipat sa HOLD. Bakit? Dahil ang mga tao ay nahaharap sa sakit ng pagsasama.
Kung ang iyong sangay ay nabubuhay nang napakahabang panahon, ito ay natigil, nabubulok, at nagsisimula kaming gumugol ng mas maraming oras sa pagsisikap na gumawa ng ilang uri ng pagbabago dito.
At kamakailan lamang ay sinabi ng may-akda ng Gitflow na kung ang iyong layunin ay Patuloy na Pagsasama, kung ang iyong layunin ay gusto mong gumulong nang madalas hangga't maaari, kung gayon ang Gitflow ay isang masamang ideya. Hiwalay niyang idinagdag sa artikulo na kung mayroon kang backend kung saan maaari kang magsikap para dito, kung gayon ang Gitflow ay kalabisan para sa iyo, dahil ang Gitflow ay magpapabagal sa iyo, ang Gitflow ay lilikha ng mga problema para sa iyo sa pagsasama.
Hindi ito nangangahulugan na ang Gitflow ay masama at hindi dapat gamitin. Para ito sa ibang okasyon. Halimbawa, kapag kailangan mong suportahan ang ilang bersyon ng isang serbisyo o application, ibig sabihin, kung saan kailangan mo ng suporta sa mahabang panahon.
Ngunit kung makikipag-usap ka sa mga taong sumusuporta sa gayong mga serbisyo, maririnig mo ang maraming sakit tungkol sa katotohanan na ang bersyon na ito ay 3.2, na 4 na buwan na ang nakakaraan, ngunit ang pag-aayos na ito ay hindi kasama dito at ngayon, upang magawa ito, kailangan mong gumawa ng isang grupo ng mga pagbabago. At ngayon sila ay natigil muli, at ngayon sila ay naglilibot sa loob ng isang linggo na sinusubukang ipatupad ang ilang bagong tampok.
Tulad ng wastong nabanggit ni Alexander Kovalev sa chat, ang ugnayan ay hindi katulad ng sanhi. Ito ay totoo. Ibig sabihin, walang direktang koneksyon na kung mayroon kang Continuous Integration, magiging mahusay ang lahat ng sukatan. Ngunit mayroong isang positibong ugnayan na kung ang isa ay isa, malamang na ang isa ay ganoon din. Hindi isang katotohanan, ngunit malamang. Ito ay isang ugnayan lamang.
Parang may ginagawa na tayo, parang nagsasama na tayo, pero paano natin mauunawaan na meron pa tayong Continuous Integration, na medyo madalas na tayo?
Si Jez Humble ang may-akda ng Handbook, Accelerate, the Continuous Delivery website, at ang librong Continuous Delivery. Inaalok niya ang pagsubok na ito:
- Ang code ng engineer ay nakukuha sa master araw-araw.
- Para sa bawat commit na nagpapatakbo ka ng mga unit test.
- Ang build sa master ay nahulog, ito ay naayos sa loob ng 10 minuto.
Iminumungkahi niya ang paggamit ng pagsusulit na tulad nito upang matiyak na mayroon kang sapat na pagsasanay.
Sa tingin ko ang huli ay medyo kontrobersyal. Iyon ay, kung maaari mong ayusin ito sa loob ng 10 minuto, pagkatapos ay mayroon kang Continuous Integration, ito ay medyo kakaiba, sa aking opinyon, ngunit ito ay may katuturan. Bakit? Dahil kung madalas kang mag-freeze, ito ay nangangahulugan na ang iyong mga pagbabago ay maliit. Kung ang isang maliit na pagbabago ay nangangahulugan na ang iyong master build ay nasira, pagkatapos ay makakahanap ka ng isang halimbawa nang mabilis dahil ang pagbabago ay maliit. Dito nagkaroon ka ng maliit na merge, 20-30 linya dito ang nagbago. At, nang naaayon, maaari mong mabilis na maunawaan kung ano ang dahilan, dahil ang mga pagbabago ay maliit, mayroon kang isang napakaliit na lugar upang hanapin ang problema.
At kahit na ang aming prod ay bumagsak pagkatapos ng paglabas, kung gayon kung mayroon kaming pagsasanay ng Continuous Integration, mas madali para sa amin na kumilos, dahil ang mga pagbabago ay maliit. Oo, makakaapekto ito sa pagpaplano. Masasaktan ito. At, marahil, ang pinakamahirap na bagay sa pagsasanay na ito ay ang masanay sa paghiwa-hiwalay ng mga gawain, iyon ay, kung paano ito gagawin upang maaari kang kumuha ng isang bagay at gawin ito sa loob ng ilang oras at sa parehong oras ay pumasa sa isang pagsusuri, kung meron ka. Ang pagsusuri ay isang hiwalay na sakit.
Ang mga unit test ay isang katulong lamang na tumutulong sa iyong maunawaan kung matagumpay ang iyong pagsasama at kung walang nasira. Sa palagay ko, hindi rin ito ganap na sapilitan, dahil hindi ito ang punto ng pagsasanay.
Ito ay isang maikling panimula sa Patuloy na Pagsasama. Iyon lang ang mayroon sa pagsasanay na ito. Handa na akong magtanong.
Ibubuod ko na lang ulit ng maikli:
- Ang Continuous Integration ay hindi Jenkins, hindi ito Gitlab.
- Ito ay hindi isang tool, ito ay isang kasanayan na pinagsama namin ang aming code sa master nang madalas hangga't maaari.
- Ginagawa namin ito upang maiwasan ang napakalaking sakit na lumitaw sa mga pagsasanib sa hinaharap, iyon ay, nakakaranas kami ng kaunting sakit ngayon upang hindi makaranas ng higit pa sa hinaharap. Iyon ang buong punto.
- Sa gilid ay mayroong komunikasyon sa pamamagitan ng code, ngunit bihira kong makita ito, ngunit ito rin ang idinisenyo para sa.
mga katanungan
Ano ang gagawin sa mga hindi nabubulok na gawain?
Mabulok. Ano ang problema? Maaari ka bang magbigay ng isang halimbawa na mayroong isang gawain at hindi ito nabubulok?
May mga gawain na hindi mabubulok mula sa salitang "ganap", halimbawa, ang mga nangangailangan ng napakalalim na kadalubhasaan at talagang malulutas sa loob ng isang buwan upang makamit ang ilang natutunaw na resulta.
Kung naiintindihan kita ng tama, kung gayon mayroong ilang malaki at kumplikadong gawain, ang resulta nito ay makikita lamang sa isang buwan?
Oo, tama iyan. Oo, posible na suriin ang resulta nang hindi mas maaga kaysa sa isang buwan.
ayos lang. Sa pangkalahatan ito ay hindi isang problema. Bakit? Dahil sa kasong ito, kapag pinag-uusapan natin ang tungkol sa mga sanga, hindi natin pinag-uusapan ang isang sanga na may tampok. Ang mga tampok ay maaaring malaki at kumplikado. Maaari silang makaapekto sa isang malaking bilang ng mga bahagi. At marahil ay hindi natin ganap na magagawa ang mga ito sa isang sangay. Ito ay mabuti. Kailangan lang nating sirain ang kwentong ito. Kung hindi pa ganap na handa ang isang feature, hindi ito nangangahulugan na hindi maaaring pagsamahin ang ilang piraso ng code nito. Idinagdag mo, sabihin nating, paglipat at mayroong ilang mga yugto sa loob ng tampok. Sabihin nating mayroon kang yugto - gumawa ng paglipat, magdagdag ng bagong paraan. At masusukat mo na ang mga bagay na ito araw-araw.
ayos lang. Ano ang punto kung gayon?
Ano ang silbi ng pagpatay ng maliliit na bagay araw-araw?
Oo.
Kung masira nila ang isang bagay, makikita mo ito kaagad. Mayroon kang isang maliit na piraso na nasira ang isang bagay, mas madali para sa iyo na ayusin ito. Ang punto ay ang pagsasama ng isang maliit na piraso ngayon ay mas madali kaysa sa pagsasama ng isang bagay na malaki sa loob ng ilang linggo. At ang pangatlong punto ay ang ibang mga inhinyero ay gagana sa kasalukuyang bersyon ng code. Makikita nila na ang ilang mga paglilipat ay naidagdag dito, at pagkatapos ay lumitaw ang ilang pamamaraan na maaaring gusto rin nilang gamitin. Makikita ng lahat kung ano ang nangyayari sa iyong code. Para sa tatlong bagay na ito ginagawa ang pagsasanay.
Salamat, sarado na ang isyu!
(Oleg Soroka) Maaari ko bang idagdag? Nasabi mo lahat ng tama, gusto ko lang magdagdag ng isang parirala.
So.
Sa Patuloy na Pagsasama, ang code ay pinagsama sa isang karaniwang sangay hindi kapag ang tampok ay ganap na handa, ngunit kapag ang build ay tumigil sa pagsira. At maaari kang ligtas na mangako sa pag-master nang maraming beses sa isang araw hangga't gusto mo. Ang ikalawang aspeto ay na kung sa ilang kadahilanan ay hindi mo maaaring hatiin ang buwanang gawain sa mga gawain nang hindi bababa sa tatlong araw, ako ay tahimik ng halos tatlong oras, kung gayon mayroon kang malaking problema. At ang katotohanan na wala kang Continuous Integration ang pinakamaliit sa mga problemang ito. Nangangahulugan ito na mayroon kang mga problema sa arkitektura at zero na mga kasanayan sa engineering. Dahil kahit na ito ay pananaliksik, kung gayon sa anumang kaso dapat itong mabalangkas sa anyo ng mga hypotheses o isang cycle.
Napag-usapan namin ang tungkol sa 4 na sukatan na nakikilala ang mga matagumpay na kumpanya mula sa mga nahuhuli. Kailangan pa nating mabuhay para makita ang 4 na sukatan na ito. Kung ang iyong average na gawain ay tumatagal ng isang buwan upang makumpleto, pagkatapos ay tututuon ko muna ang sukatang ito. Ibaba ko muna ito sa 3 araw. At pagkatapos noon ay nagsimula akong mag-isip tungkol sa Continuous.
Naintindihan ko ba nang tama na iniisip mo na sa pangkalahatan ay walang saysay ang pamumuhunan sa mga kasanayan sa engineering kung ang anumang gawain ay tumatagal ng isang buwan upang makumpleto?
Mayroon kang Patuloy na Pagsasama. At mayroong isang paksa na sa loob ng 10 minuto maaari mong ayusin ang isang pag-aayos o ibalik ito. Isipin mong inilunsad mo ito. Bukod dito, mayroon kang tuluy-tuloy na pag-deploy, inilunsad mo ito upang i-prod at saka mo lang napansin na may nangyaring mali. At kailangan mong ibalik ito, ngunit nailipat mo na ang iyong database. Mayroon ka nang database schema ng susunod na bersyon, bukod dito, mayroon ka ring ilang uri ng backup, at ang data ay nakasulat din doon.
At anong alternatibo ang mayroon ka? Kung ibabalik mo ang code, hindi na ito gagana sa na-update na database na ito.
Ang base ay sumusulong lamang, oo.
Ang mga taong may mahihirap na kasanayan sa engineering ay malamang na hindi pa nagbabasa ng makapal na libro tungkol sa... alinman. Ano ang gagawin sa backup? Kung ibinalik mo mula sa isang backup, nangangahulugan ito na nawala mo ang data na iyong naipon sa sandaling iyon. Halimbawa, nagtrabaho kami nang tatlong oras kasama ang bagong bersyon ng database, ang mga gumagamit ay nakarehistro doon. Tinanggihan mo ang lumang backup dahil hindi gumagana ang scheme sa bagong bersyon, kaya nawala ang mga user na ito. At hindi sila nasisiyahan, nagmumura sila.
Upang makabisado ang buong hanay ng mga kasanayan na sumusuporta sa Patuloy na Pagsasama at Patuloy na Paghahatid, hindi sapat na matutunan lamang kung paano magsulat.... Una, maaaring marami sa kanila, magiging hindi praktikal. Dagdag pa, mayroong isang grupo ng iba pang mga kasanayan tulad ng Scientific. Mayroong ganoong kasanayan, pinasikat ito ng GitHub sa isang pagkakataon. Ito ay kapag mayroon kang parehong lumang code at bagong code na tumatakbo nang sabay. Ito ay kapag gumawa ka ng hindi natapos na feature, ngunit maaari itong magbalik ng ilang halaga: alinman bilang isang function o bilang isang Rest API. Isinasagawa mo ang parehong bagong code at ang lumang code, at ihambing ang pagkakaiba sa pagitan nila. At kung may pagkakaiba, pagkatapos ay i-log mo ang kaganapang ito. Sa paraang ito malalaman mo na mayroon kang bagong feature na handang ilunsad sa ibabaw ng luma kung hindi ka pa nagkaroon ng pagkakaiba sa pagitan ng dalawa sa isang partikular na oras.
Mayroong daan-daang mga ganoong kasanayan. Iminumungkahi kong magsimula sa transbase development. Hindi siya 100% sa Continuous Integration, ngunit pareho ang mga gawi, hindi mabubuhay nang maayos ang isa kung wala ang isa.
Nagbigay ka ba ng transbase development bilang isang halimbawa kung saan makikita mo ang mga kasanayan o iminumungkahi mo ba na simulan ng mga tao ang paggamit ng transbase debelopment?
Tingnan, dahil hindi nila ito magagamit. Upang magamit ang mga ito, kailangan mong magbasa ng maraming. At kapag ang isang tao ay nagtanong: "Ano ang gagawin sa isang tampok na tumatagal ng isang buwan, nangangahulugan ito na hindi niya nabasa ang tungkol sa pagpapaunlad ng transbase." Hindi ko pa ito irerekomenda. Ipapayo ko na tumutok lamang sa paksa kung paano wastong hatiin ng arkitektura ang malalaking gawain sa mas maliliit na gawain. Ito ang kakanyahan ng agnas.
Ang agnas ay isa sa mga kasangkapan ng arkitekto. Ginagawa muna namin ang pagsusuri, pagkatapos ay agnas, pagkatapos ay synthesis, pagkatapos ay pagsasama. At ito ay kung paano gumagana ang lahat para sa amin. At kailangan pa rin nating umunlad sa Continuous Integration sa pamamagitan ng decomposition. Ang mga tanong ay bumangon sa unang yugto, at pinag-uusapan na natin ang tungkol sa ikaapat na yugto, ibig sabihin, mas madalas na ginagawa natin ang pagsasama, mas mabuti. Masyado pang maaga para gawin ito; mainam na bawasan muna ang iyong monolith.
Kailangan mong gumuhit ng isang bilang ng mga arrow at mga parisukat sa ilang diagram. Hindi mo masasabi na ngayon ay ipapakita ko ang diagram ng arkitektura ng isang bagong aplikasyon at magpapakita ng isang parisukat, sa loob kung saan mayroong isang berdeng pindutan para sa aplikasyon. Sa anumang kaso, magkakaroon ng higit pang mga parisukat at mga arrow. Ang bawat diagram na nakita ko ay mayroong higit sa isa. At ang agnas, kahit na sa antas ng graphical na representasyon, ay nagaganap na. Samakatuwid, ang mga parisukat ay maaaring gawing independyente. Kung hindi, kung gayon mayroon akong malalaking katanungan para sa arkitekto.
May tanong mula sa chat: "Kung ang pagsusuri ay sapilitan at tumatagal ng mahabang panahon, maaaring isang araw o higit pa?"
Mayroon kang mga problema sa pagsasanay. Ang pagsusuri ay hindi dapat tumagal ng isang araw o higit pa. Ito ay ang parehong kuwento sa nakaraang tanong, lamang ng kaunti malambot. Kung magpapatuloy ang pagsusuri sa loob ng isang araw, malamang na ang pagsusuring ito ay magkakaroon ng napakalaking pagbabago. Nangangahulugan ito na kailangan itong gawing mas maliit. Sa pag-unlad ng transbase, na inirerekomenda ni Oleg, mayroong isang kuwento na tinatawag na tuluy-tuloy na pagsusuri. Ang kanyang ideya ay gumawa kami ng isang maliit na kahilingan sa paghila nang kusa, dahil nagsusumikap kaming patuloy na pagsamahin at paunti-unti. At kaya binago ng pull request ang isang abstraction o 10 linya. Salamat sa pagsusuring ito, aabutin kami ng ilang minuto.
Kung ang pagsusuri ay tumatagal ng isang araw o higit pa, may mali. Una, maaaring mayroon kang ilang mga problema sa arkitektura. O ito ay isang malaking piraso ng code, 1 linya, halimbawa. O ang iyong arkitektura ay napakakomplikado na hindi ito maintindihan ng isang tao. Ito ay isang bahagyang patagilid na problema, ngunit kailangan din itong lutasin. Marahil ay hindi na kailangan para sa isang pagsusuri sa lahat. Kailangan din nating pag-isipan ito. Ang pagsusuri ay ang bagay na nagpapabagal sa iyo. Mayroon itong mga pakinabang sa pangkalahatan, ngunit kailangan mong maunawaan kung bakit mo ito ginagawa. Ito ba ay isang paraan para mabilis mong maihatid ang impormasyon, ito ba ay isang paraan para sa iyo na magtakda ng ilang mga pamantayan sa loob o ano? Bakit kailangan mo ito? Dahil ang pagsusuri ay kailangang gawin nang napakabilis o kanselahin nang buo. Ito ay tulad ng transbase na pag-unlad - ang kuwento ay napakaganda, ngunit para lamang sa mga mature na lalaki.
Tungkol sa 4 na sukatan, irerekomenda ko pa rin na alisin ang mga ito upang maunawaan kung saan ito humahantong. Tingnan ang mga numero, tingnan ang larawan, kung gaano masama ang lahat.
(Dmitry) Handa akong pumasok sa isang talakayan tungkol dito sa iyo. Mahusay ang mga numero at sukatan, mahusay ang mga kasanayan. Ngunit kailangan mong maunawaan kung kailangan ito ng negosyo. May mga negosyo na hindi nangangailangan ng ganoong uri ng bilis ng pagbabago. May alam akong mga kumpanya kung saan hindi maaaring gawin ang mga pagbabago tuwing 15 minuto. At hindi dahil napakasama nila. Ito ay isang ikot ng buhay. At para gawing feature ang branches, ang toggle feature, kailangan mo ng malalim na kaalaman.
Ito ay kumplikado. Kung gusto mong basahin ang kuwento tungkol sa tampok na toggle nang mas detalyado, lubos kong inirerekomenda ito . At mayroong isang kahanga-hangang artikulo ni Martin Fowler tungkol sa mga tampok na toggle: kung anong mga uri ang mayroon, mga siklo ng buhay, atbp. Ang tampok na toggle ay kumplikado.
At hindi mo pa rin sinasagot ang tanong na: "Kailangan ba si Jenkins o hindi?"
Jenkins ay hindi kailangan sa anumang kaso talaga. Seryoso bagaman, ang mga tool: Jenkins, Gitlab ay magdadala sa iyo ng kaginhawahan. Makikita mo na ang pagpupulong ay binuo o hindi binuo. Matutulungan ka nila, ngunit hindi ka nila bibigyan ng pagsasanay. Maaari ka lang nilang bigyan ng lupon - Ok, hindi Ok. At pagkatapos, kung sumulat ka rin ng mga pagsubok, dahil kung walang mga pagsubok, kung gayon ito ay halos walang kabuluhan. Samakatuwid, ito ay kinakailangan dahil ito ay mas maginhawa, ngunit sa pangkalahatan maaari kang mabuhay nang wala ito, hindi ka mawawalan ng malaki.
Ibig sabihin, kung mayroon kang mga kasanayan, nangangahulugan ba iyon na hindi mo ito kailangan?
Tama iyan. Inirerekomenda ko ang Jez Humble test. Doon ay mayroon akong ambivalent na saloobin patungo sa huling punto. Ngunit sa pangkalahatan, kung mayroon kang tatlong bagay, patuloy kang nagsasama, nagpapatakbo ka ng mga pagsubok sa mga commit sa master, mabilis mong inaayos ang build sa master, pagkatapos ay marahil ay hindi mo na kailangan ang anumang bagay.
Habang naghihintay kami ng mga tanong ng mga kalahok, may tanong ako. Pinag-uusapan lang namin ang code ng produkto. Nagamit mo na ba ito para sa infrastructure code? Ito ba ay parehong code, mayroon ba itong parehong mga prinsipyo at parehong ikot ng buhay, o may iba't ibang mga siklo at prinsipyo ng buhay? Kadalasan, kapag pinag-uusapan ng lahat ang Continuous Integration and Development, nakakalimutan ng lahat na mayroon ding infrastructure code. At nitong mga nakaraang araw ay dumami ito. At dapat bang dalhin doon ang lahat ng panuntunang ito?
Kahit na hindi ito dapat, ito ay magiging mahusay dahil ito ay gagawing mas madali ang buhay sa parehong paraan. Sa sandaling magtrabaho kami sa code, hindi sa mga script ng bash, ngunit mayroon kaming normal na code.
Huminto, huminto, ang isang script ng bash ay code din. Huwag mong hawakan ang dati kong mahal.
Okay, hindi ko na tatapakan ang mga alaala mo. May personal akong ayaw sa bash. Nakakasira ito ng pangit at nakakatakot sa lahat ng oras. At madalas itong masira nang hindi mahuhulaan, kaya naman hindi ko ito gusto. Pero okay, sabihin nating mayroon kang bash code. Siguro hindi ko talaga maintindihan at may mga normal na testing frameworks out there. Wala lang akong alam. At pareho tayong mga benepisyo.
Sa sandaling magtrabaho kami sa imprastraktura bilang code, nakukuha namin ang lahat ng parehong problema bilang mga developer. Ilang buwan na ang nakalipas, nakatagpo ako ng sitwasyon kung saan nagpadala sa akin ang isang kasamahan ng pull request para sa 1 lines sa bash. At tumambay ka sa review ng 000 na oras. Ang parehong mga problema ay lumitaw. Code pa rin. At ito ay isang pakikipagtulungan pa rin. Natigil kami sa kahilingan sa paghila at natigil kami sa katotohanang niresolba namin ang parehong mga salungatan sa pagsasanib sa parehong bash, halimbawa.
Ako ngayon ay napaka-aktibong tumitingin sa buong bagay na ito sa pinakamagandang infra programming. Dinala ko na ngayon si Pulumi sa imprastraktura. Ito ay programming sa pinakadalisay nitong anyo. Doon ito ay mas maganda, dahil mayroon akong lahat ng mga kakayahan ng isang programming language, ibig sabihin, gumawa ako ng magandang toggle out of the blue na may parehong kung at lahat ay maayos. Ibig sabihin, nasa master na ang sukli ko. Nakikita na siya ng lahat. Alam ito ng ibang mga inhinyero. May naimpluwensyahan na ito doon. Gayunpaman, hindi ito pinagana para sa lahat ng mga imprastraktura. Naka-on ito para sa aking mga test bench, halimbawa. Samakatuwid, upang masagot muli ang iyong katanungan, ito ay kinakailangan. Ginagawa nitong mas madali ang buhay para sa amin, bilang mga inhinyero na nagtatrabaho sa code, sa parehong paraan.
Kung sino pa ang may katanungan?
May tanong ako. Gusto kong ipagpatuloy ang talakayan kay Oleg. Sa pangkalahatan, sa palagay ko tama ka, na kung ang isang gawain ay tumatagal ng isang buwan upang makumpleto, kung gayon mayroon kang problema sa arkitektura, mayroon kang problema sa pagsusuri, agnas, pagpaplano, atbp. Ngunit mayroon akong pakiramdam na kung magsisimula ka sinusubukang mabuhay ayon sa Patuloy na Pagsasama, pagkatapos ay magsisimula kang iwasto ang sakit sa pamamagitan ng pagpaplano, dahil hindi mo ito malalayo saanman.
(Oleg) Oo, tama iyan. Ang kasanayang ito ay maihahambing sa pagsisikap sa anumang iba pang seryosong kasanayan sa pagbabago ng kultura. Ang pinakamahirap na lampasan ay ang mga ugali, lalo na ang masamang ugali. At kung upang maipatupad ang kasanayang ito, kinakailangan ang isang seryosong pagbabago sa mga gawi ng mga nakapaligid sa iyo: mga developer, pamamahala, tagapamahala ng produksyon, pagkatapos ay naghihintay sa iyo ang mga sorpresa.
Anong mga sorpresa ang maaaring magkaroon? Sabihin nating magpasya kang magsasama ka nang mas madalas. At mayroon kang ilang iba pang mga bagay na nauugnay sa pagsasama, halimbawa, mga artifact. At sa iyong kumpanya, halimbawa, mayroong isang patakaran na ang bawat artifact ay dapat isaalang-alang sa ilang paraan sa ilang uri ng artifact storage system. At ito ay tumatagal ng ilang oras. Kailangang lagyan ng tsek ng isang tao ang kahon na siya, bilang isang release manager, ay sinubukan ang artifact na ito upang matiyak na ito ay handa na para sa release sa produksyon. Kung aabutin ng 5-10-15 minuto, ngunit gagawin mo ang layout isang beses sa isang linggo, kung gayon ang paggugol ng kalahating oras isang beses sa isang linggo ay isang maliit na buwis.
Kung gagawin mo ang Continuous Integration 10 beses sa isang araw, 10 beses na kailangang i-multiply sa 30 minuto. At ito ay lumampas sa dami ng oras ng pagtatrabaho ng release manager na ito. Napapagod lang siya sa ginagawa niya. May mga nakapirming gastos para sa ilang mga kasanayan. Iyon lang.
At kailangan mong kanselahin ang panuntunang ito upang hindi ka na gumawa ng ganoong basura, ibig sabihin, hindi ka manu-manong magtalaga ng isang degree na tumutugma sa isang bagay. Lubos kang umaasa sa ilang awtomatikong hanay ng mga pagsubok sa kahandaan.
At kung kailangan mo ng patunay mula sa isang tao, upang mapirmahan ito ng boss, at hindi ka makapasok sa produksyon nang hindi sinasabi ni Vasya na pinapayagan niya ito, atbp. - lahat ng katarantaduhan na ito ay humahadlang sa practitioner. Dahil kung mayroong ilang mga aktibidad na nauugnay sa isang buwis, ang lahat ay tumataas ng 100 beses. Samakatuwid, ang paglilipat ay madalas na hindi sasalubungin ng may kagalakan ng lahat. Dahil mahirap baguhin ang ugali ng tao.
Kapag ang isang tao ay gumagawa ng kanyang karaniwang gawain, halos hindi niya ito iniisip. Ang kanyang cognitive load ay zero. Pinaglalaruan lang niya ito, may checklist na siya sa isip niya, isang libong beses na niya itong ginawa. At sa sandaling dumating ka at sabihin sa kanya: "Kanselahin natin ang pagsasanay na ito at magpakilala ng bago simula Lunes," para sa kanya ito ay nagiging isang malakas na pag-load ng pag-iisip. At ito ay dumating sa lahat nang sabay-sabay.
Samakatuwid, ang pinakasimpleng bagay, bagaman hindi lahat ay kayang bayaran ang luho na ito, ngunit ito ang palagi kong ginagawa, ito ang sumusunod. Kung magsisimula ang isang bagong proyekto, kadalasan ang lahat ng hindi pa nasusubukang kasanayan ay agad na sinisiksik sa proyektong ito. Habang ang proyekto ay bata pa, hindi talaga kami nanganganib ng anuman. Wala pang Prod, wala pang sisirain. Samakatuwid, maaari itong magamit bilang pagsasanay. Gumagana ang diskarteng ito. Ngunit hindi lahat ng kumpanya ay may pagkakataon na magsimula ng mga ganitong proyekto nang madalas. Bagama't ito ay medyo kakaiba, dahil ngayon ay may kumpletong digital na pagbabago, ang lahat ay dapat maglunsad ng mga eksperimento upang makasabay sa mga kakumpitensya.
Dito ka dumating sa konklusyon na kailangan mo munang magkaroon ng pang-unawa sa kung ano ang kailangan mong gawin. Ang mundo ay hindi perpekto, at ang prod ay hindi rin perpekto.
Oo, ang mga bagay na ito ay magkakaugnay.
Hindi rin palaging naiintindihan ng mga negosyo na kailangan nilang pumunta sa ganitong paraan.
Mayroong isang sitwasyon kung saan walang mga pagbabago na posible. Ito ay isang sitwasyon kung saan mayroong higit na presyon sa koponan. Medyo burn out na ang team. Wala siyang bakanteng oras para sa anumang mga eksperimento. Gumagana sila sa mga tampok mula umaga hanggang gabi. At ang pamamahala ay may mas kaunti at mas kaunting mga tampok. Parami nang parami ang kinakailangan. Sa ganoong sitwasyon, walang anumang pagbabago ang posible. Masasabi lang sa team na bukas ay gagawin natin ang katulad ng kahapon, kailangan lang nating gumawa ng kaunting feature. Sa ganitong kahulugan, walang mga paglipat sa anumang mga kasanayan ang posible. Ito ay isang klasikong sitwasyon kapag walang oras upang patalasin ang palakol, ang mga puno ay kailangang putulin, kaya pinutol nila ito ng isang mapurol na palakol. Walang simpleng tip dito.
(Dmitry) Magbabasa ako ng paglilinaw mula sa chat: "Ngunit kailangan namin ng maraming saklaw ng pagsubok sa iba't ibang antas. Ilang oras ang inilalaan para sa mga pagsusulit? Ito ay medyo mahal at tumatagal ng maraming oras."
(Oleg) Ito ay isang klasikong maling kuru-kuro. Dapat mayroong sapat na mga pagsubok para maging kumpiyansa ka. Ang Tuloy-tuloy na Pagsasama ay hindi isang bagay kung saan 100% ng mga pagsusulit ang unang ginagawa at pagkatapos lamang ay sisimulan mong ilapat ang kasanayang ito. Binabawasan ng Continuous Integration ang iyong cognitive load dahil sa ang katunayan na ang bawat pagbabago na nakikita mo sa iyong mga mata ay napakalinaw na naiintindihan mo kung ito ay masira ang isang bagay o hindi, kahit na walang mga pagsubok. Maaari mong mabilis na subukan ito sa iyong ulo dahil ang mga pagbabago ay maliit. Kahit na mayroon ka lamang mga manu-manong tester, mas madali din ito para sa kanila. Gumalaw ka at sinabing: "Tingnan mo, may nasira ba?" Sinuri nila at sinabing, "Hindi, walang sira." Dahil alam ng tester kung saan titingin. Mayroon kang isang commit na nauugnay sa isang piraso ng code. At ito ay pinagsamantalahan ng tiyak na pag-uugali.
Dito ka, siyempre, pinalamutian.
(Dmitry) Hindi ako sang-ayon dito. Mayroong isang kasanayan - pag-unlad na hinimok ng pagsubok, na magliligtas sa iyo mula dito.
(Oleg) Well, hindi pa ako umabot sa puntong iyon. Ang unang ilusyon ay kailangan mong isulat ang 100% ng mga pagsubok o hindi mo na kailangang gawin ang Continuous Integration. Hindi yan totoo. Ito ay dalawang magkatulad na kasanayan. At hindi sila direktang umaasa. Dapat na pinakamainam ang saklaw ng iyong pagsubok. Pinakamainam - nangangahulugan ito na ikaw mismo ay tiwala na ang kalidad ng master kung saan nanatili ang iyong master pagkatapos ng commit ay nagbibigay-daan sa iyong kumpiyansa na pindutin ang "Deploy" na buton sa isang lasing na gabi ng Biyernes. Paano mo ito makakamit? Sa pamamagitan ng pagsusuri, sa pamamagitan ng coverage, sa pamamagitan ng mahusay na pagsubaybay.
Ang mahusay na pagsubaybay ay hindi naiiba sa mga pagsubok. Kung nagpapatakbo ka ng mga pagsubok nang isang beses sa pre prod, pagkatapos ay susuriin nila ang lahat ng iyong script ng user nang isang beses at iyon lang. At kung patakbuhin mo ang mga ito sa isang walang katapusang loop, ito ang iyong naka-deploy na sistema ng pagsubaybay, na walang katapusang sumusubok sa lahat - nag-crash man ito o hindi. Sa kasong ito, ang pagkakaiba lamang ay kung ito ay ginagawa nang isang beses o dalawang beses. Isang napakagandang hanay ng mga pagsubok... walang katapusang tumatakbo, ito ay pagsubaybay. At dapat ganito ang tamang pagsubaybay.
At samakatuwid, kung paano eksaktong makakamit mo ang estadong ito kapag naghanda ka sa Biyernes ng gabi at umuwi ay isa pang tanong. Baka isa ka lang matapang na scumbag.
Bumalik tayo ng kaunti sa Continuous Integration. Tumakbo kami palayo sa isang bahagyang naiibang kumplikadong pagsasanay.
At ang pangalawang ilusyon ay ang MVP, sabi nila, ay kailangang gawin nang mabilis, kaya hindi kailangan ang mga pagsubok doon. Hindi tiyak sa ganoong paraan. Ang katotohanan ay kapag sumulat ka ng isang kwento ng gumagamit sa isang MVP, maaari mo itong i-develop sa bola, iyon ay, narinig mo na mayroong ilang uri ng kwento ng gumagamit at agad na tumakbo upang i-code ito, o maaari kang magtrabaho gamit ang TDD. At ayon sa TDD, tulad ng ipinapakita ng kasanayan, hindi ito tumatagal, ibig sabihin, ang mga pagsubok ay isang side effect. Ang pagsasanay ng TDD ay hindi tungkol sa pagsubok. Sa kabila ng tinatawag na Test Driven Development, hindi ito tungkol sa mga pagsubok. Ito rin ay isang diskarte sa arkitektura. Ito ay isang diskarte sa pagsulat nang eksakto kung ano ang kailangan at hindi pagsusulat kung ano ang hindi kailangan. Ito ay isang kasanayan ng pagtutok sa susunod na pag-ulit ng iyong pag-iisip sa mga tuntunin ng paglikha ng isang arkitektura ng application.
Samakatuwid, hindi ganoon kadaling alisin ang mga ilusyong ito. Ang MVP at mga pagsubok ay hindi nagkakasalungatan. Kahit na, sa halip, sa kabaligtaran, kung gumawa ka ng MVP gamit ang TDD practice, gagawin mo ito nang mas mahusay at mas mabilis kaysa kung gagawin mo ito nang walang pagsasanay, ngunit sa isang bola.
Ito ay isang napaka-hindi-halata at kumplikadong ideya. Kapag narinig mo na ngayon ay magsusulat ako ng higit pang mga pagsubok at sa parehong oras ay gagawa ako ng isang bagay nang mas mabilis, tila hindi sapat.
(Dmitry) Maraming tao dito, kapag tinawag nilang MVP, tamad na magsulat ng normal. At ito ay iba't ibang mga bagay pa rin. Hindi na kailangang gawing isang masamang bagay ang MVP na hindi gumagana.
Oo, oo, tama ka.
Tapos biglang MVP in prod.
Magpakailanman.
At parang hindi pangkaraniwan ang TDD kapag narinig mong sumusulat ka ng mga pagsubok at mukhang mas marami kang ginagawa. Mukhang kakaiba, ngunit sa katunayan ito ay nagiging mas mabilis at mas maganda sa ganitong paraan. Kapag sumulat ka ng isang pagsubok, marami ka nang iniisip sa iyong isipan tungkol sa kung anong code ang tatawagin at kung paano, pati na rin kung anong pag-uugali ang inaasahan namin mula dito. Hindi mo lang sasabihin na nagsulat ako ng ilang function at may ginagawa ito. Noong una ay inakala mo na mayroon siyang ganito at ganoong mga kondisyon, siya ay tatawagin sa ganoon at ganoong paraan. Sinasaklaw mo ito ng mga pagsubok at mula dito naiintindihan mo kung paano titingnan ang iyong mga interface sa loob ng iyong code. Malaki ang epekto nito sa arkitektura. Awtomatikong nagiging mas modular ang iyong code, dahil susubukan mo munang maunawaan kung paano mo ito susubukan, at pagkatapos ay isulat ito.
Ang nangyari sa akin sa TDD ay may mga pagkakataon na kumuha ako ng Ruby mentor noong Ruby programmer pa ako. At sabi niya: "Gawin natin ito ayon sa TDD." Naisip ko: "Damn, ngayon kailangan kong magsulat ng isang bagay na dagdag." At napagkasunduan namin na sa loob ng dalawang linggo ay isusulat ko ang lahat ng gumaganang code sa Python gamit ang TDD. Pagkatapos ng dalawang linggo, napagtanto ko na ayaw ko nang bumalik. Pagkatapos ng dalawang linggo ng pagsubok na ilapat ito sa lahat ng dako, napagtanto mo kung gaano naging madali para sa iyo na mag-isip lamang. Ngunit ito ay hindi halata, kaya inirerekomenda ko sa lahat na kung mayroon kang pakiramdam na ang TDD ay mahirap, matagal at hindi kailangan, subukang manatili dito sa loob lamang ng dalawang linggo. Sapat na sa akin ang dalawa.
(Dmitry) Maaari nating palawakin ang ideyang ito mula sa punto ng view ng pagpapatakbo ng imprastraktura. Bago kami maglunsad ng anumang bago, ginagawa namin ang pagsubaybay at pagkatapos ay ilunsad. Sa kasong ito, ang pagsubaybay ay nagiging normal na pagsubok para sa amin. At may development sa pamamagitan ng monitoring. Pero halos lahat ay nagsasabi na mahaba ito, tinatamad ako, gumawa ako ng pansamantalang draft. Kung nakagawa kami ng normal na pagsubaybay, naiintindihan namin ang estado ng CI system. At ang sistema ng CI ay may maraming pagsubaybay. Naiintindihan namin ang estado ng sistema, naiintindihan namin kung ano ang nasa loob nito. At sa panahon ng pag-unlad, ginagawa lang natin ang sistema upang maabot nito ang nais na estado.
Ang mga kasanayang ito ay kilala sa mahabang panahon. Napag-usapan namin ito mga 4 na taon na ang nakakaraan. Ngunit sa loob ng 4 na taon halos walang nagbago.
Ngunit sa talang ito, iminumungkahi kong tapusin ang opisyal na talakayan.
Video (ipinasok bilang elemento ng media, ngunit sa ilang kadahilanan ay hindi gumagana):
Pinagmulan: www.habr.com