Хэрэв танай компани DevOps эсвэл CI/CD хэрэгслүүдийг дөнгөж нэвтрүүлж байгаа бол давтахгүйн тулд өөр хэн нэгний тармуурыг гишгэхгүйн тулд хамгийн нийтлэг алдаануудыг мэдэж байх нь танд ашигтай байх болно.
баг нийтлэлийг орчуулав .
Соёл, үйл явцыг өөрчлөхөд бэлэн бус байх
Хэрэв та мөчлөгийн диаграммыг харвал , DevOps практикт туршилт хийх нь тасралтгүй үйл ажиллагаа бөгөөд байршуулалт бүрийн үндсэн хэсэг болох нь тодорхой байна.
DevOps Infinite Cycle Chart
Хөгжүүлэлт, хүргэлтийн явцад туршилт, чанарын баталгаа нь хөгжүүлэгчид хийдэг бүх зүйлийн чухал хэсэг юм. Энэ нь даалгавар болгонд тестийг тусгах сэтгэлгээний өөрчлөлтийг шаарддаг.
Туршилт нь багийн гишүүн бүрийн өдөр тутмын ажлын нэг хэсэг болдог. Тогтмол туршилтанд шилжих нь тийм ч хялбар биш бөгөөд та үүнд бэлэн байх хэрэгтэй.
Санал хүсэлт байхгүй байна
DevOps-ийн үр ашиг нь байнгын санал хүсэлтээс хамаардаг. Хамтын ажиллагаа, харилцаа холбоо байхгүй бол тасралтгүй сайжруулах боломжгүй юм.
Ретроспектив уулзалт зохион байгуулдаггүй компаниуд CI/CD-д байнгын санал хүсэлтийн соёлыг хэрэгжүүлэхэд хэцүү байдаг. Давталт бүрийн төгсгөлд эргэн харах уулзалтууд зохион байгуулагддаг бөгөөд энэ үеэр багийн гишүүд юу сайн, юу нь муу болсон талаар ярилцдаг. Ретроспектив уулзалтууд нь Scrum/Agile-ийн үндэс суурь боловч DevOps-д бас зайлшгүй шаардлагатай.
Учир нь эргэн тойрны уулзалтууд нь санал бодлоо солилцох, санал бодлоо солилцох зуршлыг бий болгодог. Эхэндээ хамгийн чухал зүйлүүдийн нэг бол бүхэл бүтэн багт ойлгомжтой, танил болсон чимэг уулзалтуудыг зохион байгуулах явдал юм.
Програм хангамжийн чанарын тухайд багийн бүх гишүүд үүнийг хадгалах үүрэгтэй. Жишээлбэл, хөгжүүлэгчид нэгжийн тест бичихээс гадна код бичих боломжтой бөгөөд энэ нь эрсдэлийг эхнээс нь бууруулахад тусалдаг.
Туршилтын талаарх сэтгэлгээний өөрчлөлтийг тусгах нэг энгийн арга бол шалгагчдыг QA биш, харин програм хангамж шалгагч эсвэл чанарын инженер гэж дуудах явдал юм. Энэ өөрчлөлт нь хэтэрхий энгийн эсвэл бүр тэнэг мэт санагдаж магадгүй юм. Харин хэн нэгнийг "програм хангамжийн чанарын баталгааны ажилтан" гэж нэрлэх нь тухайн бүтээгдэхүүний чанарыг хэн хариуцах талаар буруу ойлголт төрүүлдэг. Agile, CI/CD, DevOps практикт хүн бүр програм хангамжийн чанарыг хариуцдаг.
Өөр нэг чухал зүйл бол бүхэл бүтэн баг, түүний гишүүн, байгууллага, оролцогч талуудын хувьд чанар гэж юу болохыг ойлгох явдал юм.
Үе шат дуусгах тухай буруу ойлголт
Хэрэв чанар нь тасралтгүй бөгөөд ерөнхий үйл явц юм бол үе шатыг дуусгах талаар нийтлэг ойлголт хэрэгтэй. Нэг үе шат дууссаныг яаж мэдэх вэ? Trello эсвэл бусад Канбан самбар дээр алхмыг дууссан гэж тэмдэглэвэл юу болох вэ?
Definition of Done (DoD) нь CD DevOps/CI-ийн хүрээнд хүчирхэг хэрэгсэл юм. Энэ нь багийг юу, хэрхэн бүтээдэг чанарын стандартыг илүү сайн ойлгоход тусалдаг.
Хөгжлийн баг "Дууссан" гэж юу болохыг шийдэх ёстой. Тэд сууж, бүрэн гүйцэд гэж үзэхийн тулд үе шат бүрт хангагдсан байх ёстой шинж чанаруудын жагсаалтыг гаргах хэрэгтэй.
DoD нь үйл явцыг илүү ил тод болгож, багийн бүх гишүүдэд ойлгогдож, харилцан тохиролцсон тохиолдолд CI/CD-г хэрэгжүүлэхэд хялбар болгодог.
Бодит, тодорхой тодорхойлсон зорилго байхгүй
Энэ бол хамгийн олон удаа иш татсан зөвлөгөөний нэг боловч дахин давтах нь зүйтэй. CI/CD эсвэл DevOps зэрэг аливаа томоохон ажилд амжилтанд хүрэхийн тулд та бодит зорилго тавьж, тэдгээрийн гүйцэтгэлийг хэмжих хэрэгтэй. Та CI/CD-ээр юунд хүрэхийг оролдож байна вэ? Энэ нь илүү чанартай, хурдан гаргах боломжийг олгож байна уу?
Аливаа зорилго нь ил тод, бодитой байхаас гадна компанийн одоогийн үйл ажиллагаатай нийцэж байх ёстой. Жишээлбэл, танай үйлчлүүлэгчид шинэ засварууд эсвэл хувилбаруудыг хэр их шаарддаг вэ? Хэрэглэгчдэд нэмэлт ашиг тус байхгүй бол процессыг хэт ачаалж, илүү хурдан гаргах шаардлагагүй.
Нэмж дурдахад та CD болон CI хоёрыг хоёуланг нь хэрэгжүүлэх шаардлагагүй. Жишээлбэл, банк, эмнэлгийн клиник зэрэг өндөр зохицуулалттай компаниуд зөвхөн CI-тэй хамтран ажиллах боломжтой.
CI нь DevOps-ийг хэрэгжүүлдэг аливаа компанид сайн эхлэлийн цэг болдог. Үүнийг хэрэгжүүлснээр компаниудын програм хангамжийг хүргэх арга барил эрс өөрчлөгддөг. CI-г эзэмшсэний дараа та бүх үйл явцыг сайжруулах, нэвтрүүлэх хурдыг нэмэгдүүлэх болон бусад өөрчлөлтийн талаар бодож болно.
Олон байгууллагын хувьд CI дангаараа хангалттай бөгөөд CD нь үнэ цэнийг нэмсэн тохиолдолд л хэрэгжих ёстой.
Тохиромжтой хяналтын самбар, хэмжүүр дутмаг
Та зорилгоо тодорхойлсны дараа хөгжлийн баг KPI-ийг хэмжих хяналтын самбар үүсгэж болно. Үүнийг боловсруулахаасаа өмнө хяналт тавих параметрүүдийг үнэлэх нь зүйтэй.
Өөр өөр тайлан, програмууд нь багийн өөр гишүүдэд хэрэгтэй. Scrum Master нь статус, хүртээмжийг илүү сонирхдог. Хэдийгээр ахлах удирдлага мэргэжилтнүүдийн шатах түвшинг сонирхож магадгүй юм.
Зарим багууд бүх зүйлийг зөв хийж байгаа эсэх, алдаа байгаа эсэхийг ойлгохын тулд CI/CD-ийн төлөвийг үнэлэхийн тулд улаан, шар, ногоон үзүүлэлт бүхий хяналтын самбар ашигладаг. Улаан өнгө нь юу болж байгааг анхаарч үзэх хэрэгтэй гэсэн үг юм.
Гэсэн хэдий ч, хэрэв хяналтын самбар нь стандартчилагдаагүй бол тэдгээр нь төөрөгдүүлж болзошгүй юм. Хүн бүрт ямар өгөгдөл хэрэгтэй байгааг шинжилж, дараа нь энэ нь юу гэсэн үг болохыг стандартчилсан тайлбарыг бий болго. График, текст эсвэл тоо гэх мэт оролцогч талуудад юу илүү ойлгомжтой болохыг олж мэдээрэй.
Гарын авлагын туршилт байхгүй
Туршилтын автоматжуулалт нь сайн CI/CD дамжуулах хоолойн үндэс суурийг тавьдаг. Гэхдээ бүх үе шатанд автоматжуулсан туршилт нь гар аргаар туршилт хийх ёсгүй гэсэн үг биш юм.
Үр дүнтэй CI/CD дамжуулах хоолойг бий болгохын тулд танд гарын авлагын туршилт хэрэгтэй. Шинжилгээнд хүний шинжилгээ хийх шаардлагатай зарим талууд үргэлж байх болно.
Гарын авлагын туршилтын хүчин чармайлтыг дамжуулах хоолойдоо нэгтгэх талаар бодох нь зүйтэй. Зарим туршилтын тохиолдлуудыг гараар туршиж дууссаны дараа та байршуулах үе шатанд шилжиж болно.
Туршилтыг сайжруулах гэж бүү оролд
Үр дүнтэй CI/CD дамжуулах хоолой нь туршилтын удирдлага эсвэл интеграци, байнгын хяналт гэх мэт зөв хэрэгсэлд хандахыг шаарддаг.
Хүчтэй, чанарт чиглэсэн соёлыг бий болгох зорилготой , байршуулсны дараах хэрэглэгчийн харилцан үйлчлэлийг хянах, сайжруулалтыг хянах.
Энд та хялбархан хэрэгжүүлж болох практик зөвлөмжүүд байна:
- Тестүүдээ бичихэд хялбар, кодыг дахин засварлахад эвдэхгүй уян хатан эсэхийг шалгаарай.
- Туршилтын үйл явцад хөгжүүлэлтийн багууд хамрагдах ёстой - CI дамжуулах хоолойн үед шалгахад чухал хэрэглэгчийн асуудал, хүсэлтийн жагсаалтыг харна уу.
- Танд туршилтын бүрэн хамрах хүрээ байхгүй байж болох ч UX болон хэрэглэгчийн туршлагад чухал ач холбогдолтой урсгалуудыг үргэлж шалгаж байгаарай.
Хамгийн сүүлчийн гэхдээ хамгийн чухал зүйл
CI/CD-д шилжих шилжилтийг ихэвчлэн доороос дээш эхлүүлдэг боловч эцсийн эцэст энэ нь манлайллын худалдан авалт, цаг хугацаа, компаниас нөөц хөрөнгө шаарддаг өөрчлөлт юм. Эцсийн эцэст, CI/CD нь ур чадвар, үйл явц, арга хэрэгсэл, соёлын бүтцийн өөрчлөлтийг зөвхөн системтэйгээр хэрэгжүүлэх боломжтой юм.
Энэ сэдвээр өөр юу унших вэ:
- .
- .
- .
Эх сурвалж: www.habr.com