Kung ang iyong kumpanya ay nagpapakilala lamang ng mga tool ng DevOps o CI/CD, maaaring maging kapaki-pakinabang para sa iyo na maging pamilyar sa mga pinakakaraniwang pagkakamali upang hindi na maulit ang mga ito at hindi makatapak sa rake ng ibang tao.
Koponan isinalin ang artikulo .
Hindi kahandaang baguhin ang kultura at proseso
Kung titingnan mo ang cyclic diagram , malinaw na sa DevOps practices testing ay isang tuluy-tuloy na aktibidad, isang pangunahing bahagi ng bawat solong deployment.
DevOps Infinite Cycle Chart
Ang pagsubok at pagtiyak sa kalidad sa panahon ng pagbuo at paghahatid ay isang mahalagang bahagi ng lahat ng ginagawa ng mga developer. Nangangailangan ito ng pagbabago sa pag-iisip upang maisama ang pagsubok sa bawat gawain.
Ang pagsubok ay nagiging bahagi ng pang-araw-araw na gawain ng bawat miyembro ng koponan. Ang paglipat sa patuloy na pagsubok ay hindi madali, kailangan mong maging handa para dito.
Kakulangan ng feedback
Ang pagiging epektibo ng DevOps ay nakasalalay sa patuloy na feedback. Imposible ang patuloy na pagpapabuti kung walang puwang para sa pakikipagtulungan at komunikasyon.
Nahihirapan ang mga kumpanyang hindi nag-oorganisa ng mga retrospective na pagpupulong na ipatupad ang kultura ng tuluy-tuloy na feedback sa CI/CD. Ang mga retrospective na pagpupulong ay gaganapin sa dulo ng bawat pag-ulit, kung saan tinatalakay ng mga miyembro ng koponan kung ano ang naging maayos at kung ano ang naging hindi maganda. Ang mga retrospective meeting ay ang pundasyon ng Scrum/Agile, ngunit kailangan din ang mga ito para sa DevOps.
Ito ay dahil ang mga retrospective na pagpupulong ay nagtatanim ng ugali ng pagpapalitan ng feedback at opinyon. Ang isa sa mga pinakamahalagang punto sa simula ay ang pag-aayos ng mga umuulit na retro na pagpupulong upang sila ay maging maliwanag at pamilyar sa buong koponan.
Pagdating sa kalidad ng software, lahat ng miyembro ng team ay may pananagutan sa pagpapanatili nito. Halimbawa, maaaring magsulat ang mga developer ng mga unit test at magsulat din ng code na nasa isip ang pagiging masusubok, na tumutulong na mabawasan ang panganib sa simula.
Isang simpleng paraan para ipakita ang pagbabago sa pag-iisip tungkol sa pagsubok ay ang tawagan ang mga tester hindi QA, ngunit software tester o quality engineer. Ang pagbabagong ito ay maaaring mukhang masyadong simple o kahit na hangal. Ngunit ang pagtawag sa isang tao na isang "taong may kasiguruhan sa kalidad ng software" ay nagbibigay ng maling ideya tungkol sa kung sino ang responsable para sa kalidad ng produkto. Sa mga kasanayan sa Agile, CI/CD, at DevOps, lahat ay responsable para sa kalidad ng software.
Ang isa pang mahalagang punto ay upang maunawaan kung ano ang kahulugan ng kalidad para sa buong koponan at bawat isa sa mga miyembro nito, samahan, at mga stakeholder.
Hindi pagkakaunawaan sa pagkumpleto ng entablado
Kung ang kalidad ay isang tuluy-tuloy at pangkalahatang proseso, isang karaniwang pag-unawa sa pagkumpleto ng yugto ay kailangan. Paano mo malalaman kung tapos na ang isang yugto? Ano ang mangyayari kapag ang isang hakbang ay minarkahan bilang nakumpleto sa isang Trello o iba pang Kanban board?
Ang Definition of Done (DoD) ay isang makapangyarihang tool sa konteksto ng CD DevOps/CI. Nakakatulong ito upang mas maunawaan ang mga pamantayan ng kalidad ng kung ano at paano bubuo ang koponan.
Dapat magpasya ang development team kung ano ang ibig sabihin ng "Tapos na". Kailangan nilang umupo at gumawa ng isang listahan ng mga katangian na dapat matugunan sa bawat yugto para ito ay maituturing na kumpleto.
Ginagawang mas transparent ng DoD ang proseso at ginagawang mas madaling ipatupad ang CI/CD kung naiintindihan ito ng lahat ng miyembro ng team at napagkasunduan ng isa't isa.
Kakulangan ng makatotohanan, malinaw na tinukoy na mga layunin
Ito ay isa sa mga pinaka-madalas na sinipi na mga piraso ng payo, ngunit ito ay paulit-ulit. Upang magtagumpay sa anumang pangunahing pagsisikap, kabilang ang CI/CD o DevOps, kailangan mong magtakda ng mga makatotohanang layunin at sukatin ang pagganap laban sa mga ito. Ano ang sinusubukan mong makamit sa CI/CD? Nagbibigay ba ito ng mas mabilis na paglabas na may mas mahusay na kalidad?
Ang anumang mga layunin na itinakda ay dapat hindi lamang maging transparent at makatotohanan, ngunit maging pare-pareho sa kasalukuyang mga aktibidad ng kumpanya. Halimbawa, gaano kadalas kailangan ng iyong mga customer ang mga bagong patch o bersyon? Hindi na kailangang mag-overload ng mga proseso at maglabas ng mas mabilis kung walang karagdagang benepisyo sa mga user.
Bukod pa rito, hindi mo palaging kailangang ipatupad ang parehong CD at CI. Halimbawa, ang mga kumpanyang lubos na kinokontrol gaya ng mga bangko at mga medikal na klinika ay maaari lamang gumana sa CI.
Ang CI ay nagsisilbing magandang panimulang punto para sa anumang kumpanyang nagpapatupad ng DevOps. Kapag ito ay ipinatupad, ang mga diskarte ng mga kumpanya sa paghahatid ng software ay makabuluhang nagbabago. Kapag na-master na ang CI, maaari mong isipin ang tungkol sa pagpapabuti sa buong proseso, pagpapataas ng bilis ng paglulunsad at iba pang mga pagbabago.
Para sa maraming organisasyon, sapat na ang CI lamang, at dapat lang ipatupad ang CD kung magdaragdag ito ng halaga.
Kakulangan ng naaangkop na mga dashboard at sukatan
Kapag naitakda mo na ang iyong mga layunin, makakagawa ang development team ng dashboard para sukatin ang mga KPI. Bago ang pag-unlad nito, ito ay nagkakahalaga ng pagtatasa ng mga parameter na susubaybayan.
Ang iba't ibang ulat at aplikasyon ay kapaki-pakinabang para sa iba't ibang miyembro ng koponan. Ang Scrum Master ay mas interesado sa katayuan at abot. Habang ang senior management ay maaaring interesado sa burnout rate ng mga espesyalista.
Gumagamit din ang ilang team ng mga dashboard na may mga indicator na pula, dilaw at berde upang masuri ang status ng CI/CD para maunawaan kung ginagawa nila ang lahat ng tama o kung may error. Ang ibig sabihin ng pula ay kailangan mong bigyang pansin ang mga nangyayari.
Gayunpaman, kung ang mga dashboard ay hindi na-standardize, maaari silang mapanlinlang. Suriin kung anong data ang kailangan ng lahat, at pagkatapos ay gumawa ng standardized na paglalarawan kung ano ang ibig sabihin nito. Alamin kung ano ang mas makabuluhan sa mga stakeholder: mga graphics, text, o mga numero.
Walang manu-manong pagsusuri
Ang pag-aautomat ng pagsubok ay naglalagay ng pundasyon para sa isang mahusay na pipeline ng CI/CD. Ngunit ang awtomatikong pagsubok sa lahat ng yugto ay hindi nangangahulugan na hindi ka dapat magsagawa ng manu-manong pagsubok.
Upang makabuo ng isang epektibong pipeline ng CI/CD, kailangan mo rin ng mga manu-manong pagsusuri. Palaging may ilang aspeto ng pagsubok na nangangailangan ng pagsusuri ng tao.
Ito ay nagkakahalaga ng pagsasaalang-alang sa pagsasama ng mga pagsusumikap sa manu-manong pagsubok sa iyong pipeline. Kapag nakumpleto na ang manu-manong pagsubok ng ilang kaso ng pagsubok, maaari kang magpatuloy sa yugto ng pag-deploy.
Huwag subukang pagbutihin ang mga pagsubok
Ang isang epektibong pipeline ng CI/CD ay nangangailangan ng access sa mga tamang tool, ito man ay pamamahala ng pagsubok o pagsasama at patuloy na pagsubaybay.
Ang paglikha ng isang malakas, kalidad-oriented na kultura ay naglalayong , pagsubaybay sa mga pakikipag-ugnayan ng customer pagkatapos ng pag-deploy at pagsubaybay sa mga pagpapabuti.
Narito ang ilang praktikal na tip na madali mong maipatupad:
- Siguraduhin na ang iyong mga pagsubok ay madaling isulat at sapat na kakayahang umangkop upang hindi masira kapag refactor mo ang code.
- Dapat isama ang mga development team sa proseso ng pagsubok - tingnan ang isang listahan ng mga isyu at kahilingan ng user na mahalagang subukan sa panahon ng mga pipeline ng CI.
- Maaaring wala kang ganap na saklaw ng pagsubok, ngunit palaging tiyaking nasusubok ang mga daloy na mahalaga sa UX at karanasan ng customer.
Huling ngunit hindi bababa sa mahalagang punto
Ang paglipat sa CI/CD ay karaniwang hinihimok mula sa ibaba pataas, ngunit sa huli ito ay isang pagbabagong nangangailangan ng pamumuno sa pagbili, oras, at mga mapagkukunan mula sa kumpanya. Pagkatapos ng lahat, ang CI/CD ay isang hanay ng mga kasanayan, proseso, kasangkapan at muling pagsasaayos ng kultura; sistematikong maipapatupad lamang ang mga naturang pagbabago.
Ano pa ang mababasa sa paksa:
- .
- .
- .
Pinagmulan: www.habr.com