CI хэрэгслүүд болон CI нь яагаад огт өөр зүйл болохыг ярилцъя.
CI нь ямар өвдөлтийг шийдэхийг зорьдог вэ, энэ санаа хаанаас ирсэн бэ, энэ нь ажилладаг гэсэн хамгийн сүүлийн үеийн баталгаа юу вэ, та зөвхөн Женкинс суулгаагүй дадлага туршлагатай гэдгээ хэрхэн ойлгох вэ.
Тасралтгүй интеграцийн тухай тайлан гаргах санаа жилийн өмнө ярилцлаганд орж, ажил хайж байх үед гарч ирсэн. Би 10-15 компанитай ярилцсаны зөвхөн нэг нь л CI гэж юу болох талаар тодорхой хариулж, өөрт нь байхгүй гэдгээ хэрхэн ойлгосноо тайлбарлаж чадсан. Бусад нь Женкинсийн талаар ойлгомжгүй дэмий юм ярьж байсан :) За, манайд Женкинс байгаа, тэр бүтээдэг, CI! Тайлангийн үеэр би Тасралтгүй интеграци гэж юу болох, Женкинс болон түүнтэй төстэй хэрэгслүүд яагаад үүнтэй маш сул холбоотой болохыг тайлбарлахыг хичээх болно.
Тэгэхээр CI гэдэг үгийг сонсоход юу санаанд орж ирдэг вэ? Ихэнх хүмүүс Женкинс, Гитлаб CI, Травис гэх мэтийг бодох болно.
Бид үүнийг google-ээс хайж байсан ч энэ нь бидэнд эдгээр хэрэгслүүдийг өгөх болно.
Хэрэв та асуух аргыг мэддэг бол хэрэглүүрүүдийг жагсаасан даруйд тэд танд CI гэдэг нь Татгалзах хүсэлтэд тест хийж, ажиллуулах үед танд хэлэх болно.
Тасралтгүй интеграци нь багаж хэрэгслийн тухай биш, салбар дахь тест бүхий угсралтын тухай биш юм! Тасралтгүй интеграци гэдэг нь шинэ кодыг маш олон удаа нэгтгэх практик бөгөөд үүнийг ашиглахын тулд Женкинс, GitLab гэх мэтийг хаах шаардлагагүй юм.
Бүрэн эрхт CI ямар байдгийг олж мэдэхийн өмнө эхлээд үүнийг гаргаж ирсэн хүмүүсийн нөхцөл байдалд шумбаж, тэдний шийдвэрлэх гэж оролдож байсан өвдөлтийг мэдэрцгээе.
Мөн тэд нэг баг болж ажиллахын зовлонг тайлсан!
Хөгжүүлэгчид багаар ажиллахад тулгардаг бэрхшээлүүдийн жишээг харцгаая. Энд бид төсөл, git дэх мастер салбар, хоёр хөгжүүлэгчтэй байна.
Тэгээд тэд бүгд эртнээс дассан шигээ ажилдаа оров. Бид том схемийн дагуу даалгавар авч, функцын салбар үүсгэж, кодыг бичсэн.
Нэг нь функцийг хурдан дуусгаж, мастерт нэгтгэв.
Хоёр дахь нь илүү цаг хугацаа шаардаж, сүүлдээ нийлж, зөрчилдөөнтэй болсон. Одоо хөгжүүлэгч нь бизнест хэрэгтэй шинж чанаруудыг бичихийн оронд зөрчилдөөнийг шийдвэрлэхэд цаг хугацаа, эрч хүчээ зарцуулдаг.
Таны онцлогийг нийтлэг мастертай хослуулах нь илүү хэцүү байх тусам бид үүнд илүү их цаг зарцуулдаг. Би үүнийг маш энгийн жишээгээр харуулсан. Энэ бол ердөө 2 хөгжүүлэгч байдгийн жишээ юм.Нэг агуулахад нэг компанид 10, 15 эсвэл 100 хүн бичдэг гэж төсөөлөөд үз дээ. Та эдгээр бүх зөрчлийг шийдвэрлэхийн тулд галзуурна.
Харин арай өөр тохиолдол бий. Бидэнд мастер, зарим хөгжүүлэгчид ямар нэг зүйл хийдэг.
Тэд мөчир бүтээжээ.
Нэг нь нас барсан, бүх зүйл сайхан байсан, тэр даалгавраа давсан.
Энэ хооронд хоёр дахь хөгжүүлэгч даалгавраа хүлээлгэн өглөө. Тэр үүнийг хянуулахаар явуулсан гэж бодъё. Олон компанид тойм гэж нэрлэгддэг практик байдаг. Энэ бясалгалын хувьд нэг талаасаа сайн, ашигтай, нөгөө талаас биднийг олон талаар удаашруулдаг. Бид үүнд орохгүй, гэхдээ шүүмжийн түүх юунд хүргэж болохыг харуулсан гайхалтай жишээ энд байна. Та хянуулахаар татах хүсэлт гаргасан байна. Хөгжүүлэгчээс өөр хийх зүйл байхгүй. Тэр юу хийж эхэлдэг вэ? Тэрээр бусад ажлуудыг хийж эхэлдэг.
Энэ хугацаанд хоёр дахь хөгжүүлэгч өөр зүйл хийсэн.
Эхнийх нь гурав дахь даалгавраа гүйцэтгэсэн.
Хэсэг хугацааны дараа түүний тоймыг туршиж үзсэн бөгөөд тэрээр эвлэрэхийг хичээж байна. Тэгэхээр юу болоод байна? Энэ нь асар олон тооны зөрчилдөөнийг барьдаг. Яагаад? Учир нь түүний татах хүсэлтийг хянаж байх хооронд кодонд олон зүйл аль хэдийн өөрчлөгдсөн байв.
Зөрчилдөөнтэй түүхээс гадна харилцаа холбоо бүхий түүх бий. Таны утас хянагдаж байх үед, ямар нэгэн зүйл хүлээж байх зуур, та функц дээр удаан хугацаагаар ажиллаж байх үед та үйлчилгээнийхээ кодын санд өөр юу өөрчлөгдөж байгааг хянахаа болино. Магадгүй таны одоо шийдэх гэж байгаа зүйл өчигдөр аль хэдийн шийдэгдсэн байж магадгүй, та ямар нэгэн арга аваад дахин ашиглах боломжтой. Гэхдээ та дандаа хуучирсан салбартай ажилладаг учраас үүнийг харахгүй. Мөн энэ хуучирсан салбар таныг нэгтгэх зөрчлийг шийдвэрлэхэд үргэлж хүргэдэг.
Хэрэв бид нэг баг болж ажиллах юм бол, өөрөөр хэлбэл, нэг хүн биш, харин 5-10 хүн хадгалдаг бол бид кодоо мастерт нэмэхгүй байх тусам эцэст нь бидэнд хэрэгтэй учраас илүү их зовж шаналах болно. ямар нэг зүйл дараа нь нэгтгэнэ. Бид хэр их зөрчилдөөнтэй, хуучин хувилбартай ажиллах тусам илүү олон асуудал тулгардаг.
Хамтдаа ямар нэг зүйл хийх нь зовлонтой! Бид үргэлж бие биенийхээ замд саад болдог.
Энэ асуудал 20 гаруй жилийн өмнө ажиглагдсан. Би Extreme Programming дахь тасралтгүй интеграцийн практикийн тухай анхны дурдлагыг олсон.
Extreme Programming бол анхны agile framework юм. Энэ хуудас 96 онд гарч ирсэн. Мөн аливаа програмчлалын практик, төлөвлөлт болон бусад зүйлийг ашиглах санаа нь хөгжүүлэлт нь аль болох уян хатан байх бөгөөд ингэснээр бид үйлчлүүлэгчдийнхээ аливаа өөрчлөлт, шаардлагад хурдан хариу өгөх боломжтой болно. Мөн тэд 24 жилийн өмнөөс, хэрэв та ямар нэг зүйлийг маш удаан, хажуугаар нь хийвэл зөрчилдөөнтэй байдаг тул түүнд илүү их цаг зарцуулдаг гэсэн үүнтэй тулгарч эхэлсэн.
Одоо бид "Тасралтгүй интеграци" гэсэн хэллэгийг тусад нь шинжлэх болно. Хэрэв бид үүнийг шууд орчуулбал бид тасралтгүй интеграцид ордог. Гэхдээ энэ нь хэр зэрэг үргэлжилдэг нь тийм ч тодорхой биш, маш тасархай юм. Гэхдээ энэ нь хэр их интеграцитай вэ гэдэг нь тийм ч тодорхой биш юм.
Тийм учраас би та бүхэнд Extreme Programming-аас эшлэл хүргэж байна. Мөн бид хоёр үгийг тусад нь шинжлэх болно.
Интеграци - Би аль хэдийн хэлсэнчлэн, бид инженер бүр кодын хамгийн сүүлийн үеийн хувилбартай ажиллахыг хичээдэг бөгөөд ингэснээр тэр өөрийн кодыг нийтлэг салбар руу аль болох олон удаа нэмж оруулахыг хичээдэг, ингэснээр эдгээр нь жижиг салбарууд байх болно. Учир нь хэрэв тэд том бол бид долоо хоногийн турш нэгтгэх зөрчилдөөнд амархан гацах болно. Хэрэв бид хүрхрээ гэх мэт урт хугацааны хөгжлийн мөчлөгтэй бол энэ нь ялангуяа үнэн бөгөөд хөгжүүлэгч нь асар том функцийг багасгахын тулд нэг сарын турш явсан. Тэгээд тэр интеграцийн үе шатанд маш удаан хугацаанд гацах болно.
Интеграци гэдэг нь бид салбараа аваад мастертай нэгтгэх, нэгтгэх явдал юм. Бид трансбааз хөгжүүлэгч бол ямар ч нэмэлт салбаргүйгээр мастер руу шууд бичихийг эрмэлздэг эцсийн сонголт байдаг.
Ерөнхийдөө интеграцчилал гэдэг нь кодоо аваад мастер руу чирнэ гэсэн үг.
Энд "тасралтгүй" гэдэг үг юу гэсэн үг вэ, юуг тасралтгүй гэж нэрлэдэг вэ? Дадлага нь хөгжүүлэгч өөрийн кодыг аль болох хурдан нэгтгэхийг хичээдэг гэсэн үг юм. Энэ бол аливаа ажлыг гүйцэтгэхдээ түүний зорилго юм - кодоо аль болох хурдан мастер болгох. Тохиромжтой ертөнцөд хөгжүүлэгчид үүнийг хэдхэн цаг тутамд хийдэг. Өөрөөр хэлбэл, та жижиг асуудлыг авч, мастерт нэгтгэнэ. Бүх зүйл гайхалтай. Энэ бол таны хичээж байгаа зүйл юм. Мөн үүнийг тасралтгүй хийх ёстой. Та ямар нэгэн зүйл хийснийхээ дараа шууд мастерт оруулдаг.
Мөн ямар нэг зүйлийг бүтээж буй хөгжүүлэгч нь түүнийг ажиллуулахын тулд юу хийсэн бэ гэдгээ хариуцаж, юу ч эвдэхгүй. Туршилтын түүх энд ихэвчлэн гарч ирдэг. Энэ нь ажиллаж байгаа эсэхийг шалгахын тулд бид үүрэг хариуцлагаа нэгтгэхдээ хэд хэдэн туршилт хийхийг хүсч байна. Энд Женкинс танд тусалж чадна.
Гэхдээ түүхүүдийн хувьд: өөрчлөлтүүдийг жижиг болгоцгооё, даалгавраа жижиг болгоцгооё, асуудал гаргаад тэр даруйдаа ямар нэгэн байдлаар мастерт оруулахыг хичээцгээе - энд ямар ч Женкинс туслахгүй. Учир нь Женкинс танд зөвхөн шалгалт өгөхөд туслах болно.
Та тэдэнгүйгээр хийж болно. Энэ нь таныг огтхон ч гэмтээхгүй. Учир нь практикийн зорилго нь ирээдүйд аливаа зөрчилдөөнд асар их цаг хугацаа алдахгүйн тулд аль болох олон удаа хэмжих явдал юм.
Ямар нэг шалтгааны улмаас бид 2020 онд интернетгүй байна гэж төсөөлөөд үз дээ. Мөн бид орон нутагт ажилладаг. Бидэнд Женкинс байхгүй. Энэ зүгээр. Та орон нутгийн салбараа үргэлжлүүлж болно. Та үүнд код бичсэн. Бид даалгавраа 3-4 цагийн дотор гүйцэтгэсэн. Бид мастер руу шилжиж, git pull хийж, тэнд салбараа нэгтгэсэн. Бэлэн. Хэрэв та үүнийг байнга хийдэг бол баяр хүргэе, та тасралтгүй интеграцитай болно!
Орчин үеийн ертөнцөд эрчим хүчээ зарцуулах нь зүйтэй гэсэн ямар нотолгоо байдаг вэ? Учир нь ерөнхийдөө хэцүү байдаг. Хэрэв та ингэж ажиллахыг оролдвол зарим төлөвлөлтөд нөлөөлнө гэдгийг ойлгох болно, та даалгавраа задлахад илүү их цаг зарцуулах хэрэгтэй болно. Учир нь хэрэв та хүн ..., тэгвэл та хурдан эвлэрэх боломжгүй бөгөөд үүний дагуу асуудалд орох болно. Та дадлага хийхээ болино.
Мөн энэ нь үнэтэй байх болно. Тасралтгүй интеграци ашиглан маргаашнаас шууд ажиллах боломжгүй болно. Та бүгд үүнд дасахад маш их хугацаа шаардагдах болно, даалгавраа задлахад дасахад маш их хугацаа шаардагдах болно, хэрэв танд байгаа бол дахин давтах дадлага хийхэд маш удаан хугацаа шаардагдах болно. . Учир нь бидний зорилго өнөөдөр түүнийг хайлуулах явдал юм. Хэрэв та гурван өдрийн дотор дүгнэлт хийвэл танд асуудал байгаа бөгөөд Тасралтгүй интеграци нь танд тохирохгүй байна.
Гэхдээ яг одоо бидэнд энэ практикт хөрөнгө оруулах нь утга учиртай гэсэн холбогдох нотолгоо байгаа юу?
Миний санаанд хамгийн түрүүнд орж ирсэн зүйл бол State of DevOps. Энэ бол залуусын 7 жил хийсэн судалгаа юм. Одоо тэд үүнийг бие даасан байгууллагаар хийдэг, гэхдээ Google-ийн дор.
Мөн тэдний 2018 оны судалгаагаар хурдан нэгдэж, байнга нэгддэг, мэдээллийн технологийн гүйцэтгэлийн үзүүлэлтүүд нь илүү сайн байдаг богино хугацааны салбаруудыг ашиглахыг хичээдэг компаниудын хоорондын хамаарлыг харуулсан.
Эдгээр үзүүлэлтүүд юу вэ? Эдгээр нь бүх компаниудаас санал асуулгадаа авдаг 4 хэмжигдэхүүн юм: байршуулах давтамж, өөрчлөлт хийх хугацаа, үйлчилгээг сэргээх хугацаа, өөрчлөлтийн бүтэлгүйтлийн түвшин.
Нэгдүгээрт, ийм хамаарал байдаг бөгөөд байнга хэмждэг компаниуд илүү сайн хэмжүүртэй байдаг гэдгийг бид мэднэ. Тэд компаниудыг хэд хэдэн ангилалд хуваадаг: эдгээр нь удаан, дунд зэргийн гүйцэтгэлтэй, өндөр гүйцэтгэлтэй, элит үйлдвэрлэдэг удаан компаниуд юм. Элит нь Netflix, Amazon, супер хурдан, бүх зүйлийг хурдан, үзэсгэлэнтэй, үр дүнтэй хийдэг.
Сарын өмнө болсон хоёр дахь түүх. Технологийн радар нь Gitflow-ийн тухай гайхалтай нийтлэлтэй. Gitflow нь салбарууд нь урт насалдаг гэдгээрээ бусдаас ялгаатай. Удаан хугацаагаар амьдардаг суллах мөчрүүд байдаг бөгөөд мөн урт хугацаанд амьдардаг салбарууд байдаг. Технологийн радар дээрх энэ дадлага HOLD руу шилжсэн. Яагаад? Учир нь хүмүүс нэгдэхийн зовлонтой тулгардаг.
Хэрэв танай салбар маш удаан амьдардаг бол энэ нь гацаж, ялзарч, бид түүнд ямар нэгэн өөрчлөлт хийхийг оролдоход илүү их цаг зарцуулж эхэлдэг.
Саяхан Gitflow-ийн зохиогч хэрэв таны зорилго бол Тасралтгүй интеграци бол таны зорилго бол аль болох олон удаа өнхрөхийг хүсч байвал Gitflow бол муу санаа юм гэж хэлсэн. Хэрэв танд үүний төлөө хичээх боломжтой арын хэсэг байвал Gitflow танд илүүдэхгүй, учир нь Gitflow таныг удаашруулж, Gitflow нь интеграцид асуудал үүсгэх болно гэж тэр тусад нь нийтлэлд нэмж хэлэв.
Энэ нь Gitflow муу, ашиглах ёсгүй гэсэн үг биш юм. Энэ нь бусад тохиолдлуудад зориулагдсан. Жишээлбэл, та үйлчилгээ эсвэл програмын хэд хэдэн хувилбарыг дэмжих шаардлагатай үед, өөрөөр хэлбэл танд удаан хугацааны туршид дэмжлэг хэрэгтэй.
Харин ийм үйлчилгээг дэмждэг хүмүүстэй яривал энэ хувилбар нь 3.2 сарын өмнө 4 байсан ч энэ засвар дотор нь ороогүй байсан, одоо үүнийг хийхийн тулд, та хэд хэдэн өөрчлөлт хийх хэрэгтэй. Одоо тэд дахин гацсан бөгөөд одоо тэд долоо хоногийн турш шинэ функцийг хэрэгжүүлэх гэж оролдож байна.
Александр Ковалев чат дээр зөв тэмдэглэснээр корреляци нь учир шалтгаантай адил биш юм. Энэ бол үнэн. Өөрөөр хэлбэл, хэрэв та тасралтгүй интеграцитай бол бүх хэмжүүрүүд гайхалтай байх болно гэсэн шууд холбоо байхгүй. Гэхдээ хэрэв нэг нь нэг бол нөгөө нь бас байх магадлалтай гэсэн эерэг хамаарал байдаг. Баримт биш, гэхдээ хамгийн их магадлалтай. Энэ бол зүгээр л хамаарал юм.
Бид аль хэдийн ямар нэгэн зүйл хийж байгаа юм шиг байна, бид аль хэдийн нэгдэж байгаа юм шиг санагдаж байна, гэхдээ бид үргэлжилсэн интеграцитай хэвээр байгааг, нэлээд олон удаа нэгдэж байгааг юу гэж ойлгох вэ?
Жез Хумбл нь гарын авлага, Accelerate, Continuous Delivery вэбсайт, Continuous Delivery номын зохиогч юм. Тэрээр энэ туршилтыг санал болгож байна:
- Инженерийн код өдөр бүр мастерт ирдэг.
- Амлалт бүрийн хувьд та нэгжийн тестийг ажиллуулдаг.
- Мастер дахь барилга унасан, 10 минутын дотор зассан.
Тэр танд хангалттай дадлага хийж байгаа эсэхийг шалгахын тулд иймэрхүү тестийг ашиглахыг зөвлөж байна.
Сүүлийнх нь бага зэрэг маргаантай санагдаж байна. Өөрөөр хэлбэл, хэрэв та үүнийг 10 минутын дотор засаж чадвал Та тасралтгүй интеграцитай болно, энэ нь миний бодлоор бага зэрэг хачирхалтай сонсогдож байгаа ч энэ нь утга учиртай юм. Яагаад? Учир нь та байнга хөлддөг бол энэ нь таны өөрчлөлт бага байна гэсэн үг юм. Хэрэв жижиг өөрчлөлт нь таны мастер бүтэц эвдэрсэн гэсэн үг бол өөрчлөлт нь бага байгаа тул та жишээг хурдан олох боломжтой. Энд та жижиг нийлүүлэлт хийсэн, 20-30 мөр өөрчлөгдсөн. Үүний дагуу та шалтгаан нь юу болохыг хурдан ойлгож чадна, учир нь өөрчлөлтүүд нь өчүүхэн тул та асуудлыг хайхад маш бага талбайтай болно.
Гаргасны дараа бидний бүтээгдэхүүн задарч унасан ч, хэрэв бид тасралтгүй интеграцийн дадлагатай бол өөрчлөлтүүд нь өчүүхэн байдаг тул ажиллахад илүү хялбар болно. Тийм ээ, энэ нь төлөвлөлтөд нөлөөлнө. Энэ нь өвдөх болно. Магадгүй энэ практикт хамгийн хэцүү зүйл бол даалгавруудыг задалж дасгах, өөрөөр хэлбэл үүнийг яаж хийх вэ, ингэснээр та ямар нэг зүйлийг аваад хэдэн цагийн дотор хийж, нэгэн зэрэг хянан үзэх боломжтой болно. чамд нэг байна. Хяналт нь тусдаа өвдөлт юм.
Нэгжийн тест нь таны интеграцчлал амжилттай болсон эсэх, юу ч эвдэрсэн эсэхийг ойлгоход туслах туслах хэрэгсэл юм. Миний бодлоор энэ нь бас заавал байх албагүй, учир нь энэ бол дадлага хийх зүйл биш юм.
Энэ бол тасралтгүй интеграцийн товч танилцуулга юм. Энэ бясалгалын хувьд ердөө л ийм байна. Би асуулт асуухад бэлэн байна.
Би дахин товчхон дүгнэж хэлье:
- Тасралтгүй интеграци бол Женкинс биш, Гитлаб биш юм.
- Энэ бол хэрэгсэл биш, бид кодоо аль болох олон удаа мастерт нэгтгэдэг практик юм.
- Ирээдүйд нэгдэх үед үүсэх асар их өвдөлтөөс зайлсхийхийн тулд бид үүнийг хийдэг, өөрөөр хэлбэл ирээдүйд илүү их өвдөлтийг мэдрэхгүйн тулд одоо бага зэрэг өвдөлтийг мэдэрдэг. Энэ бол бүх зүйл.
- Хажуу талд нь кодоор дамжуулан харилцаа холбоо байдаг, гэхдээ би үүнийг маш ховор хардаг, гэхдээ энэ нь бас зориулагдсан зүйл юм.
Асуултууд
Задардаггүй ажлуудыг яах вэ?
Задарна. Асуудал юу вэ? Даалгавар байгаа, задардаггүй жишээг та хэлж чадах уу?
"Бүрэн" гэсэн үгнээс салгаж болохгүй, жишээлбэл, маш гүнзгий мэдлэг шаарддаг, шингэц сайтай үр дүнд хүрэхийн тулд нэг сарын хугацаанд шийдэж болох ажлууд байдаг.
Хэрэв би таныг зөв ойлгож байгаа бол үр дүн нь зөвхөн сарын дараа л харагдах том бөгөөд төвөгтэй ажил байна уу?
Тиймээ зөв. Тийм ээ, үр дүнг нэг сараас өмнө үнэлэх боломжтой болно.
Сайн байна. Ерөнхийдөө энэ бол асуудал биш юм. Яагаад? Учир нь энэ тохиолдолд мөчрийн тухай ярихдаа онцлогтой мөчрийн тухай ярихгүй. Онцлогууд нь том, төвөгтэй байж болно. Тэд олон тооны бүрэлдэхүүн хэсгүүдэд нөлөөлж болно. Магадгүй бид тэдгээрийг нэг салбарт бүрэн хийж чадахгүй байх. Энэ зүгээр. Бид энэ түүхийг задлах л хэрэгтэй. Хэрэв функц бүрэн бэлэн болоогүй бол энэ нь түүний кодын зарим хэсгийг нэгтгэх боломжгүй гэсэн үг биш юм. Та шилжих хөдөлгөөнийг нэмсэн бөгөөд функц дотор зарим үе шатууд байдаг. Танд үе шат байна гэж бодъё - шилжих хөдөлгөөн хийх, шинэ арга нэмэх. Мөн та эдгээр зүйлсийг өдөр бүр хэмжиж болно.
Сайн байна. Тэгвэл ямар учиртай юм бэ?
Өдөр болгон өчүүхэн зүйл алах нь ямар учиртай юм бэ?
Тиймээ.
Хэрэв тэд ямар нэг зүйлийг эвдвэл та үүнийг шууд хардаг. Танд ямар нэг зүйл эвдэрсэн жижиг хэсэг байгаа тул засах нь танд илүү хялбар болно. Гол нь одоо жижиг хэсгийг нэгтгэх нь хэдэн долоо хоногийн дотор том зүйлийг нэгтгэхээс хамаагүй хялбар юм. Гурав дахь зүйл бол бусад инженерүүд кодын одоогийн хувилбартай ажиллах болно. Тэд энд зарим шилжилт хөдөлгөөн нэмэгдсэнийг харах болно, дараа нь тэд бас ашиглахыг хүсч болох арга зам гарч ирэв. Таны кодонд юу болж байгааг бүгд харах болно. Энэ гурван зүйлийн төлөө л дадлага хийдэг.
Баярлалаа, асуудал хаагдсан!
(Олег Сорока) Би нэмж болох уу? Та бүх зүйлийг зөв хэлсэн, би нэг хэллэг нэмэхийг хүсч байна.
Ийм байна
Continuous Integration-ийн тусламжтайгаар кодыг функц бүрэн бэлэн болсон үед биш харин угсралт тасрахаа больсон үед нийтлэг салбар болгон нэгтгэдэг. Мөн та өдөрт хэдэн ч удаа хүссэнээрээ аюулгүйгээр эзэмшиж чадна. Хоёрдахь тал нь хэрэв та ямар нэг шалтгааны улмаас сарын даалгавраа дор хаяж гурван өдрийн турш ажил болгон хувааж чадахгүй бол би гурван цаг орчим чимээгүй байгаа бол танд маш том асуудал байна. Мөн та тасралтгүй интеграци байхгүй байгаа нь эдгээр бэрхшээлүүдийн хамгийн бага нь юм. Энэ нь танд архитектур, тэг инженерийн практикт асуудал байна гэсэн үг юм. Учир нь энэ нь судалгаа байсан ч ямар ч тохиолдолд таамаглал эсвэл мөчлөг хэлбэрээр томъёологдох ёстой.
Бид амжилттай компаниудыг хоцрогдсон компаниудаас ялгах 4 үзүүлэлтийн талаар ярилцлаа. Эдгээр 4 хэмжигдэхүүнийг харахын тулд бид амьдрах ёстой. Хэрэв таны дундаж ажил нэг сар дуусах юм бол би эхлээд энэ хэмжүүр дээр анхаарлаа хандуулах болно. Би эхлээд 3 хоног хүртэл бууруулна. Үүний дараа би Continous-ийн талаар бодож эхэлсэн.
Ер нь аливаа ажлыг нэг сараар дуусгахад инженерийн практикт хөрөнгө оруулалт хийх нь утгагүй гэж бодож байгааг би зөв ойлгосон уу?
Та тасралтгүй интеграцитай. Мөн 10 минутын дотор та засч залруулах эсвэл буцааж эргүүлэх боломжтой ийм сэдэв байдаг. Та үүнийг гаргасан гэж төсөөлөөд үз дээ. Түүгээр ч зогсохгүй, та тасралтгүй байршуулалттай, та үүнийг үйлдвэрлэхийн тулд гаргаж авсан бөгөөд дараа нь ямар нэг зүйл буруу болсныг анзаарсан. Та үүнийг буцаах хэрэгтэй, гэхдээ та аль хэдийн мэдээллийн санг шилжүүлсэн байна. Танд дараагийн хувилбарын мэдээллийн сангийн схем байгаа бөгөөд үүнээс гадна танд ямар нэгэн нөөц хуулбар байсан бөгөөд өгөгдлийг тэнд бичсэн болно.
Мөн танд өөр ямар сонголт байна вэ? Хэрэв та кодыг буцааж авбал энэ шинэчлэгдсэн мэдээллийн сантай ажиллах боломжгүй болно.
Суурь нь зөвхөн урагшилдаг, тийм ээ.
Инженерийн дадлага муутай хүмүүс ... тухай зузаан номыг уншаагүй байх магадлалтай. Нөөцөөр юу хийх вэ? Хэрэв та нөөцлөлтөөс сэргээсэн бол тухайн үед хуримтлагдсан мэдээллээ алддаг гэсэн үг юм. Жишээлбэл, бид мэдээллийн сангийн шинэ хувилбар, тэнд бүртгүүлсэн хэрэглэгчидтэй гурван цаг ажилласан. Схем нь шинэ хувилбартай ажиллахгүй байгаа тул та хуучин нөөцлөлтөөс татгалзаж байгаа тул эдгээр хэрэглэгчдийг алдсан байна. Тэгээд тэд сэтгэл хангалуун бус байна, тэд харааж байна.
Тасралтгүй интеграци болон тасралтгүй хүргэлтийг дэмждэг бүх төрлийн дадлыг эзэмшихийн тулд зөвхөн хэрхэн бичиж сурах нь хангалтгүй юм.... Нэгдүгээрт, тэдгээр нь маш олон байж болно, энэ нь практик биш байх болно. Дээрээс нь Шинжлэх ухааны гэх мэт бусад олон практик байдаг. Ийм практик байдаг, GitHub үүнийг нэгэн зэрэг дэлгэрүүлсэн. Энэ нь та хуучин код болон шинэ кодыг нэгэн зэрэг ажиллуулж байх үед юм. Энэ нь та дуусаагүй функцийг хийх үед юм, гэхдээ энэ нь ямар нэг утгыг буцаах боломжтой: функц эсвэл Rest API болгон. Та шинэ код болон хуучин кодыг хоёуланг нь ажиллуулж, тэдгээрийн ялгааг харьцуулна уу. Хэрэв ялгаа байгаа бол та энэ үйл явдлыг бүртгэ. Ингэснээр та энэ хоёрын хооронд тодорхой хугацаанд зөрүү гараагүй бол хуучин функц дээр гарч ирэхэд бэлэн болсон шинэ боломж байгааг мэдэж болно.
Ийм олон зуун дадал байдаг. Би трансбааз хөгжүүлэлтээс эхлэхийг санал болгож байна. Тэр 100% Тасралтгүй Интеграцчлалд хамрагддаггүй, гэхдээ дадлага нь адилхан, нэг нь нөгөөгүйгээр сайхан амьдарч чадахгүй.
Та практикийг харж болох жишээ болгон бааз дамнасан бүтээн байгуулалтыг өгсөн үү эсвэл хүмүүст суурь дамнасан хөгжүүлэлтийг ашиглаж эхлэхийг санал болгож байна уу?
Хараарай, учир нь тэд үүнийг ашиглах боломжгүй болно. Тэдгээрийг ашиглахын тулд та маш их унших хэрэгтэй. Тэгээд хүн: "Сарын хугацаа шаардагдах функцийг яах вэ, энэ нь трансбааз хөгжүүлэх талаар уншаагүй гэсэн үг юм." Би үүнийг одоохондоо зөвлөхгүй. Би зөвхөн том даалгавруудыг архитектурын хувьд хэрхэн зөв задлах вэ гэсэн сэдэвт анхаарлаа хандуулахыг зөвлөж байна. Энэ бол задралын мөн чанар юм.
Задаргаа бол архитекторын нэг хэрэгсэл юм. Бид эхлээд анализ, дараа нь задрал, дараа нь синтез, дараа нь интеграци хийдэг. Ингээд л бүх зүйл бидний хувьд бүтдэг. Мөн бид задралын замаар тасралтгүй интеграцид өсөх шаардлагатай хэвээр байна. Эхний шатанд асуултууд гарч ирдэг бөгөөд бид дөрөв дэх үе шатыг аль хэдийн ярьж байна, өөрөөр хэлбэл бид интеграцийг илүү олон удаа хийх тусам сайн. Үүнийг хийхэд эрт байна, эхлээд цул чулуугаа таслах нь сайхан байх болно.
Та зарим диаграм дээр хэд хэдэн сум, дөрвөлжин зурах хэрэгтэй. Одоо би шинэ програмын архитектурын диаграммыг үзүүлж, дотор нь програмын ногоон товчлуур байгаа нэг квадратыг харуулна гэж та хэлж чадахгүй. Ямар ч тохиолдолд дөрвөлжин, сум илүү их байх болно. Миний харсан диаграм бүр нэгээс олон байсан. График дүрслэлийн түвшинд ч гэсэн задрал аль хэдийн явагдаж байна. Тиймээс квадратуудыг бие даасан байдлаар хийж болно. Хэрэв үгүй бол архитектороос том асуулт байна.
Чатаас асуулт байна: "Хэрэв хянан үзэх нь заавал байх ёстой бөгөөд удаан хугацаа шаардагддаг, магадгүй нэг өдөр эсвэл түүнээс дээш хугацаа шаардагддаг уу?"
Танд дадлага хийхэд асуудал байна. Шалгалт нэг өдөр ба түүнээс дээш үргэлжлэх ёсгүй. Энэ бол өмнөх асуулттай ижил түүх, зөвхөн арай зөөлөн. Хяналт нэг өдрийн турш үргэлжилбэл энэ тойм нь маш том өөрчлөлттэй байх магадлалтай. Энэ нь жижиг болгох шаардлагатай гэсэн үг юм. Олегийн зөвлөсөн трансбааз хөгжүүлэхэд тасралтгүй хянан үзэх гэсэн түүх байдаг. Түүний санаа бол бид байнга, бага багаар нэгдэхийг хичээдэг тул бид зориуд ийм жижиг татах хүсэлт гаргадаг. Тиймээс татах хүсэлт нь нэг хийсвэр буюу 10 мөрийг өөрчилдөг. Энэхүү үнэлгээний ачаар бидэнд хэдхэн минут зарцуулагдана.
Шалгалтад нэг ба түүнээс дээш хоног зарцуулагдсан бол ямар нэг зүйл буруу байна. Нэгдүгээрт, архитектуртай холбоотой зарим асуудал гарч ирж магадгүй юм. Эсвэл энэ бол том хэмжээний код, жишээлбэл, 1 мөр. Эсвэл танай архитектур маш нарийн төвөгтэй тул хүн үүнийг ойлгохгүй байх болно. Энэ нь бага зэрэг хажуугийн асуудал боловч үүнийг шийдвэрлэх шаардлагатай болно. Магадгүй хянан шалгах шаардлагагүй байх. Бид ч гэсэн энэ талаар бодох хэрэгтэй. Хяналт нь таныг удаашруулдаг зүйл юм. Энэ нь ерөнхийдөө давуу талтай боловч яагаад үүнийг хийж байгаагаа ойлгох хэрэгтэй. Энэ нь танд мэдээллийг хурдан дамжуулах арга уу, энэ нь дотооддоо ямар нэг стандарт тогтоох арга уу эсвэл юу вэ? Энэ яагаад танд хэрэгтэй байна вэ? Учир нь шалгалтыг маш хурдан хийх эсвэл бүрмөсөн цуцлах шаардлагатай. Энэ нь трансбаазын хөгжүүлэлттэй адил юм - түүх нь маш үзэсгэлэнтэй, гэхдээ зөвхөн насанд хүрсэн залууст зориулагдсан.
4 хэмжүүрийн тухайд энэ нь юунд хүргэж байгааг ойлгохын тулд тэдгээрийг арилгахыг зөвлөж байна. Тоонуудыг хар, зургийг хар, бүх зүйл ямар муухай байна.
(Дмитрий) Би тантай энэ талаар ярилцахад бэлэн байна. Тоонууд болон хэмжүүрүүд бүгд гайхалтай, дасгалууд нь гайхалтай. Гэхдээ бизнест хэрэгтэй эсэхийг ойлгох хэрэгтэй. Ийм хурдыг өөрчлөх шаардлагагүй бизнесүүд байдаг. 15 минут тутамд өөрчлөлт хийх боломжгүй компаниудыг би мэднэ. Тэд маш муу учраас биш. Энэ бол ийм амьдралын мөчлөг юм. Мөн салбаруудыг онцлог, сэлгэх функцтэй болгохын тулд танд гүн гүнзгий мэдлэг хэрэгтэй.
Энэ бол хэцүү. Хэрэв та сэлгэх функцийн тухай түүхийг илүү дэлгэрэнгүй уншихыг хүсвэл би үүнийг маш их зөвлөж байна . Мартин Фаулерын сэлгэх функцуудын тухай гайхалтай нийтлэл байдаг: ямар төрлүүд байдаг, амьдралын мөчлөг гэх мэт. Сэлгэх функц нь төвөгтэй юм.
Та "Женкинс хэрэгтэй юу, үгүй юу?" Гэсэн асуултад хариулаагүй байна.
Женкинс үнэхээр ямар ч тохиолдолд хэрэггүй. Үнэнийг хэлэхэд, хэрэгслүүд: Женкинс, Гитлаб танд тав тухыг авчрах болно. Угсралт нь угсарсан эсвэл угсардаггүй гэдгийг та харах болно. Тэд танд тусалж чадна, гэхдээ тэд танд дасгал хийхгүй. Тэд танд зөвхөн тойрог өгөх боломжтой - Ок биш, Ок биш. Тэгээд дараа нь, хэрэв та бас тест бичвэл, учир нь тест байхгүй бол энэ нь бараг утгагүй болно. Тиймээс, энэ нь илүү тохиромжтой тул шаардлагатай байдаг, гэхдээ ерөнхийдөө та үүнгүйгээр амьдарч чадна, та их зүйлийг алдахгүй.
Өөрөөр хэлбэл, хэрэв танд дадлага байгаа бол энэ нь танд хэрэггүй гэсэн үг үү?
Яг зөв. Би Jez Humble тестийг санал болгож байна. Тэнд би сүүлчийн зүйлд хоёрдмол хандлагатай байна. Гэхдээ ерөнхийдөө, хэрэв танд гурван зүйл байгаа бол та байнга нийлдэг, мастер дээр үүрэг даалгаварууд дээр туршилт хийдэг, мастер дахь бүтцийг хурдан засдаг, тэгвэл танд өөр зүйл хэрэггүй байж магадгүй юм.
Оролцогчдын асуултыг хүлээж байх хооронд надад нэг асуулт байна. Бид зүгээр л бүтээгдэхүүний кодын тухай ярьж байсан. Та үүнийг дэд бүтцийн кодонд ашигласан уу? Энэ нь ижил код уу, ижил зарчимтай, ижил амьдралын мөчлөгтэй юу, эсвэл өөр өөр амьдралын мөчлөг, зарчим байдаг уу? Ихэвчлэн хүн бүр Тасралтгүй интеграци, хөгжлийн тухай ярихад дэд бүтцийн код байдаг гэдгийг бүгд мартдаг. Мөн сүүлийн үед энэ нь улам бүр нэмэгдсээр байна. Энэ бүх дүрмийг тэнд авчрах ёстой юу?
Энэ нь тийм байх ёстой биш ч гэсэн энэ нь амьдралыг ижил аргаар хөнгөвчлөх учраас гайхалтай байх болно. Бид bash скриптээр биш кодтой ажиллахад л энгийн кодтой болсон.
Stop, stop, bash скрипт нь бас код юм. Миний хуучин хайранд битгий хүр.
За, би чиний дурсамжийг уландаа гишгэхгүй. Би bash-д дургүй байдаг. Энэ нь үргэлж муухай, аймшигтай эвдэрдэг. Энэ нь ихэвчлэн урьдчилан таамаглах аргагүй эвдэрдэг тул би үүнд дургүй байдаг. Гэхдээ зүгээр, танд bash код байна гэж бодъё. Магадгүй би үнэхээр ойлгохгүй байгаа бөгөөд тэнд ердийн тестийн хүрээ байдаг. Би зүгээр л мэдэхгүй байна. Мөн бид ижил үр өгөөжийг хүртдэг.
Бид дэд бүтэцтэй код болгон ажиллахад л хөгжүүлэгчидтэй адил асуудал гардаг. Хэдэн сарын өмнө нэг хамт олон надад bash-д 1 мөр татах хүсэлт илгээсэн нөхцөл байдалтай тулгарсан. Тэгээд та 000 цаг тойм дээр өнждөг. Үүнтэй ижил асуудлууд гарч ирдэг. Энэ нь код хэвээр байна. Мөн энэ нь хамтын ажиллагаа хэвээр байна. Бид татах хүсэлтэд гацаж, жишээ нь нэг bash дээр ижил нэгтгэх зөрчлийг шийдэж байгаадаа гацдаг.
Би одоо хамгийн үзэсгэлэнтэй инфра програмчлал дээр энэ бүх зүйлийг маш идэвхтэй харж байна. Би одоо Пулумиг дэд бүтцэд оруулсан. Энэ бол хамгийн цэвэр хэлбэрээр програмчлал юм. Тэнд энэ нь бүр ч сайхан, учир нь надад програмчлалын хэлний бүх чадвар байгаа, өөрөөр хэлбэл, би ижил ifs-ийн тусламжтай сайхан унтраалга хийсэн бөгөөд бүх зүйл зүгээр. Энэ нь миний өөрчлөлт аль хэдийн мастерт байгаа гэсэн үг юм. Хүн бүр түүнийг аль хэдийн харж болно. Бусад инженерүүд үүнийг мэддэг. Тэнд аль хэдийн ямар нэг зүйл нөлөөлсөн. Гэсэн хэдий ч бүх дэд бүтцэд үүнийг идэвхжүүлээгүй. Энэ нь жишээ нь миний туршилтын вандан дээр асаалттай байсан. Тиймээс, таны асуултанд дахин хариулах шаардлагатай байна. Энэ нь кодтой ажилладаг инженерүүдийн хувьд бидний амьдралыг нэгэн адил хялбар болгодог.
Хэрэв өөр хэн нэгэн асуулт байвал?
Надад асуулт байна. Би Олегтэй яриагаа үргэлжлүүлэхийг хүсч байна. Ер нь таны зөв гэж бодож байна, хэрэв нэг ажил XNUMX сарын хугацаа шаардагдах юм бол архитектурын асуудал, дүн шинжилгээ, задрал, төлөвлөлт гэх мэт асуудалтай тулгардаг. Гэхдээ хэрэв та эхлүүлбэл надад ийм мэдрэмж төрж байна. Тасралтгүй интеграцийн дагуу амьдрахыг хичээвэл та өвдөлтийг төлөвлөх замаар засч эхлэх болно, учир нь та үүнээс өөр хаана ч холдохгүй.
(Олег) Тийм ээ, тийм. Энэ бясалгалын хүчин чармайлтын хувьд соёлыг өөрчилдөг бусад аливаа ноцтой дадлагатай харьцуулж болно. Үүнийг даван туулахад хамгийн хэцүү зүйл бол зуршил, ялангуяа муу зуршлууд юм. Хэрэв энэ практикийг хэрэгжүүлэхийн тулд таны эргэн тойронд байгаа хүмүүсийн зуршилд ноцтой өөрчлөлт шаардлагатай бол: хөгжүүлэгчид, удирдлага, үйлдвэрлэлийн менежерүүд таныг гэнэтийн бэлэг хүлээж байна.
Ямар гэнэтийн зүйл байж болох вэ? Та илүү олон удаа нэгтгэхээр шийдсэн гэж бодъё. Танд интеграцид холбогдсон бусад зүйлс, жишээлбэл, олдворууд бий. Жишээлбэл, танай компанид олдвор бүрийг ямар нэгэн байдлаар олдвор хадгалах системд бүртгэх ёстой гэсэн бодлого байдаг. Тэгээд хэсэг хугацаа шаардагдана. Тухайн хүн уг олдворыг үйлдвэрлэлд гаргахад бэлэн эсэхийг шалгахын тулд хувилбарын менежерийн хувьд туршиж үзсэн хайрцгийг шалгах хэрэгтэй. Хэрэв 5-10-15 минут зарцуулдаг ч долоо хоногт нэг удаа макет хийдэг бол долоо хоногт нэг удаа хагас цаг зарцуулах нь бага хэмжээний татвар болно.
Хэрэв та өдөрт 10 удаа тасралтгүй интеграцчилал хийвэл 10 удаа 30 минутаар үржих шаардлагатай. Энэ нь энэ хувилбарын менежерийн ажиллах хугацаанаас хэтэрсэн байна. Тэр зүгээр л үүнийг хийхээс залхдаг. Зарим практикт тогтмол зардал гардаг. Тэгээд л болоо.
Мөн та ийм хог хаягдал хийхээ болихын тулд энэ дүрмийг цуцлах хэрэгтэй, өөрөөр хэлбэл та ямар нэгэн зүйлд тохирох зэрэглэлийг гараар олгохгүй байх хэрэгтэй. Та зарим нэг автоматжуулсан бэлэн байдлын шалгалтанд бүрэн найдаж байна.
Хэрэв танд хэн нэгнээс нотлох баримт хэрэгтэй бол дарга гарын үсэг зурж, Вася зөвшөөрөөгүй гэх мэтээр үйлдвэрлэлд орохгүй бол энэ бүх утгагүй зүйл эмчийн ажилд саад болно. Яагаад гэвэл татвартай холбоотой зарим үйл ажиллагаа байвал бүх зүйл 100 дахин нэмэгддэг. Тиймээс энэ ээлжийг хүн бүр баяр хөөрөөр угтдаггүй. Учир нь хүмүүсийн зуршлыг өөрчлөхөд хэцүү байдаг.
Хүн ердийн ажлаа хийхдээ юу ч бодолгүй шахам хийдэг. Түүний танин мэдэхүйн ачаалал тэг байна. Тэр зүгээр л үүнтэй тоглодог, түүний толгойд хяналтын хуудас байгаа, тэр үүнийг мянга дахин хийсэн. Та ирээд түүнд: "Энэ бясалгалаа цуцалж, Даваа гарагаас эхлэн шинэ дасгал хийцгээе" гэж хэлвэл энэ нь түүний хувьд танин мэдэхүйн хүчтэй ачаалал болно. Мөн энэ нь хүн бүрт нэг дор ирдэг.
Тиймээс, хамгийн энгийн зүйл бол хүн бүр ийм тансаг байдлыг төлж чадахгүй ч миний үргэлж хийдэг зүйл бол дараахь зүйл юм. Хэрэв шинэ төсөл эхлэх юм бол ихэвчлэн шалгагдаагүй бүх туршлагыг энэ төсөлд нэн даруй оруулдаг. Төсөл залуу байгаа ч бид юу ч эрсдэлд оруулахгүй. Одоогоор Prod байхгүй, устгах зүйл алга. Тиймээс үүнийг сургалт болгон ашиглаж болно. Энэ арга нь ажилладаг. Гэхдээ ийм төслийг байнга эхлүүлэх боломж бүх компаниудад байдаггүй. Хэдийгээр энэ нь бас бага зэрэг хачирхалтай боловч одоо бүрэн дижитал хувиргалт явагдаж байгаа тул хүн бүр өрсөлдөгчөө гүйцэхийн тулд туршилт хийх ёстой.
Эндээс та эхлээд юу хийх ёстойгоо ойлгох ёстой гэсэн дүгнэлтэд хүрч байна. Дэлхий ертөнц тийм ч тохиромжтой биш, бүтээгдэхүүн нь ч тийм ч тохиромжтой биш юм.
Тиймээ, эдгээр зүйлүүд хоорондоо холбоотой.
Бизнесүүд ч гэсэн ийм замаар явах хэрэгтэй гэдгээ тэр бүр ойлгодоггүй.
Ямар ч өөрчлөлт хийх боломжгүй нөхцөл байдал бий. Энэ нь багт илүү их дарамт учруулж байгаа нөхцөл байдал юм. Баг аль хэдийн нэлээд шатсан. Түүнд ямар ч туршилт хийх чөлөөт цаг байдаггүй. Тэд өглөөнөөс орой хүртэл функцууд дээр ажилладаг. Мөн менежмент нь цөөн, цөөхөн шинж чанартай байдаг. Илүү ихийг шаардаж байна. Ийм нөхцөлд ямар ч өөрчлөлт хийх боломжгүй. Маргааш бид өчигдрийнхтэй адил зүйлийг хийх болно, бид зүгээр л бага зэрэг олон функцийг хийх хэрэгтэй гэж багийнханд хэлж болно. Энэ утгаараа аливаа практикт шилжих боломжгүй. Энэ бол сүхийг хурцлах цаг байхгүй, модыг огтлох шаардлагатай байдаг тул уйтгартай сүхээр таслах сонгодог нөхцөл байдал юм. Энд энгийн зөвлөгөө байхгүй байна.
(Дмитрий) Би чатаас тодруулга унших болно: "Гэхдээ бидэнд янз бүрийн түвшний шалгалтын хамрах хүрээ их хэрэгтэй байна. Шинжилгээнд хэр их цаг зарцуулдаг вэ? Энэ нь бага зэрэг үнэтэй бөгөөд маш их цаг хугацаа шаарддаг."
(Олег) Энэ бол сонгодог буруу ойлголт юм. Өөртөө итгэлтэй байхын тулд хангалттай тест байх ёстой. Тасралтгүй интеграци гэдэг нь эхлээд тестийн 100% хийгдэж, дараа нь та энэ дадлагаа хэрэгжүүлж эхэлдэг зүйл биш юм. Тасралтгүй интеграци нь таны нүдээр харж буй өөрчлөлт бүр нь ямар нэг зүйлийг эвдэх эсэхийг ойлгоход маш тодорхой байдаг тул таны танин мэдэхүйн ачааллыг бууруулдаг. Өөрчлөлт бага байгаа тул та үүнийг толгойдоо хурдан шалгаж болно. Хэдийгээр танд зөвхөн гарын авлагын шалгагч байгаа ч энэ нь тэдэнд илүү хялбар байдаг. Та өнхрөөд: "Хараач, ямар нэг зүйл эвдэрсэн үү?" Тэд шалгаад “Үгүй ээ, эвдэрсэн зүйл байхгүй” гэж хэлсэн. Учир нь шалгагч хаанаас хайхаа мэддэг. Танд нэг кодтой холбоотой нэг үүрэг байна. Үүнийг тодорхой зан үйлээр ашигладаг.
Энд та мэдээжийн хэрэг чимэглэсэн.
(Дмитрий) Би энд санал нийлэхгүй байна. Туршилтад суурилсан хөгжүүлэлт байдаг бөгөөд энэ нь таныг үүнээс аврах болно.
(Олег) За, би одоохондоо тийм хэмжээнд хүрээгүй байна. Эхний хуурмаг зүйл бол та тестийн 100% бичих шаардлагатай эсвэл Тасралтгүй интеграцийг огт хийх шаардлагагүй болно. Энэ үнэн биш. Эдгээр нь хоёр зэрэгцээ дадлага юм. Мөн тэд шууд хамааралтай биш юм. Таны тестийн хамрах хүрээ оновчтой байх ёстой. Оновчтой - энэ нь таны мастерын үүрэг хүлээсний дараа үлдсэн мастерын чанар нь согтуу баасан гарагийн орой "Байршуулах" товчийг итгэлтэйгээр дарах боломжийг танд олгоно гэдэгт итгэлтэй байна гэсэн үг юм. Та үүнд хэрхэн хүрэх вэ? Хяналт, хамрах хүрээ, сайн хяналтаар дамжуулан.
Сайн хяналт нь тестээс ялгагдахгүй. Хэрэв та урьдчилсан бүтээгдэхүүн дээр нэг удаа тест хийвэл тэд таны бүх хэрэглэгчийн скриптийг нэг удаа шалгадаг. Хэрэв та тэдгээрийг эцэс төгсгөлгүй давталтаар ажиллуулбал энэ нь таны суурилуулсан хяналтын систем бөгөөд осолдсон эсэхээс үл хамааран бүх зүйлийг эцэс төгсгөлгүй шалгадаг. Энэ тохиолдолд цорын ганц ялгаа нь нэг эсвэл хоёр удаа хийгдсэн эсэхээс үл хамаарна. Маш сайн тестийн багц... эцэс төгсгөлгүй ажилладаг, энэ бол хяналт юм. Тэгээд зохих хяналт нь ийм байх ёстой.
Тиймээс та баасан гарагийн орой бэлдэж, гэртээ харихдаа яг яаж ийм байдалд хүрэх вэ гэдэг өөр асуудал юм. Магадгүй чи зүгээр л нэг зоримог новш байх.
Тасралтгүй интеграци руу жаахан буцаж орцгооё. Бид арай өөр нарийн төвөгтэй дасгал руу зугтсан.
Хоёрдахь хуурмаг зүйл бол MVP-ийг хурдан хийх хэрэгтэй гэж тэд хэлж байгаа тул тэнд шалгалт огт хэрэггүй. Мэдээж тийм биш. Үнэн хэрэгтээ та MVP-д хэрэглэгчийн түүхийг бичихдээ үүнийг бөмбөг дээр боловсруулж болно, өөрөөр хэлбэл та ямар нэгэн хэрэглэгчийн түүх байгааг сонсоод тэр даруй кодлох гэж гүйж, эсвэл TDD ашиглан ажиллах боломжтой. TDD-ийн хэлснээр, практикээс харахад энэ нь удаан хугацаа шаарддаггүй, өөрөөр хэлбэл туршилтууд нь гаж нөлөө юм. TDD-ийн практик нь тест хийх тухай биш юм. Туршилтад суурилсан хөгжил гэж нэрлэгддэг хэдий ч энэ нь тестийн тухай огт биш юм. Энэ нь бас архитектурын хандлага юм. Энэ нь яг хэрэгтэйг нь бичиж, хэрэггүйг нь бичихгүй байх арга юм. Энэ нь хэрэглээний архитектурыг бий болгох үүднээс таны сэтгэлгээний дараагийн давталт дээр анхаарлаа төвлөрүүлэх практик юм.
Тиймээс эдгээр хуурмаг байдлаас ангижрах нь тийм ч хялбар биш юм. MVP болон тестүүд хоорондоо зөрчилддөггүй. Тэр ч байтугай эсрэгээр, хэрэв та TDD дасгалыг ашиглан MVP хийвэл үүнийг огт дасгалгүйгээр, бөмбөг дээр хийснээс илүү сайн бөгөөд хурдан хийх болно.
Энэ бол маш тодорхой бус, төвөгтэй санаа юм. Одоо би илүү олон тест бичиж, тэр үед илүү хурдан зүйл хийх болно гэдгийг сонсоход энэ нь үнэхээр хангалтгүй сонсогдож байна.
(Дмитри) Эндхийн олон хүмүүс MVP гэж дуудахад хүмүүс ердийн зүйл бичихээс залхуурдаг. Мөн эдгээр нь өөр өөр зүйл хэвээр байна. MVP-г ажиллахгүй муу зүйл болгон хувиргах шаардлагагүй.
Тийм ээ, тийм, чиний зөв.
Тэгээд гэнэт бүтээгдэхүүнд MVP.
Үүрд мөнхөд.
Таныг тест бичиж, илүү их ажил хийж байгаа мэт санагдахыг сонсоход TDD нь маш ер бусын сонсогддог. Энэ нь маш хачирхалтай сонсогдож байгаа ч үнэн хэрэгтээ энэ нь илүү хурдан бөгөөд илүү үзэсгэлэнтэй болж хувирдаг. Та тест бичихдээ ямар код, хэрхэн дуудагдах, мөн үүнээс ямар зан авир хүлээж байгаа талаар толгойдоо аль хэдийн их боддог. Та зүгээр л би ямар нэг функц бичсэн, энэ нь ямар нэг зүйл хийдэг гэж хэлэхгүй. Эхэндээ чи тэр эмэгтэйг ийм тийм нөхцөлтэй, ийм ийм байдлаар дуудна гэж бодсон. Та үүнийг тестээр хамрах ба үүнээс таны интерфэйс таны код дотор хэрхэн харагдахыг ойлгох болно. Энэ нь архитектурт асар их нөлөө үзүүлдэг. Таны код автоматаар илүү модульчлагдсан болно, учир нь та эхлээд үүнийг хэрхэн шалгахаа ойлгохыг хичээж, дараа нь бичнэ үү.
TDD-тэй холбоотой надад тохиолдсон зүйл бол би Ruby програмист байхдаа хэзээ нэгэн цагт Ruby-н зөвлөх хөлсөлсөн юм. Тэгээд тэр: "Үүнийг TDD-ийн дагуу хийцгээе." Би: "Хараал ид, би одоо нэмэлт зүйл бичих хэрэгтэй байна" гэж бодсон. Тэгээд бид хоёр долоо хоногийн дотор TDD ашиглан Python дээр ажиллах бүх кодыг бичихээр тохиролцсон. Хоёр долоо хоногийн дараа би буцаж очихыг хүсэхгүй байгаагаа ойлгосон. Хоёр долоо хоногийн турш үүнийг хаа сайгүй хэрэгжүүлэх гэж оролдсоны дараа та зүгээр л бодоход хичнээн хялбар болсныг та ойлгож байна. Гэхдээ энэ нь тодорхой биш байгаа тул хэрэв танд TDD нь хэцүү, цаг хугацаа их шаарддаг, шаардлагагүй юм шиг санагдаж байвал хоёр долоо хоногийн турш үүнийг хийхийг зөвлөж байна. Хоёр нь надад хангалттай байсан.
(Дмитрий) Бид дэд бүтцийн үйл ажиллагааны үүднээс энэ санааг өргөжүүлж чадна. Бид ямар нэгэн шинэ зүйлийг эхлүүлэхийн өмнө хяналт тавьж, дараа нь эхлүүлнэ. Энэ тохиолдолд хяналт нь бидний хувьд ердийн туршилт болдог. Мөн хяналт тавих замаар хөгжил бий. Гэхдээ бараг бүх хүн урт байна, би залхуу байна, би түр зуурын төсөл хийсэн гэж хэлдэг. Хэрэв бид ердийн хяналтыг хийсэн бол CI системийн төлөвийг ойлгодог. Мөн CI систем нь маш их хяналттай байдаг. Бид системийн төлөв байдлыг ойлгож, дотор нь юу байгааг ойлгодог. Мөн хөгжүүлэлтийн явцад бид зүгээр л системийг хүссэн төлөвт нь хүргэж байна.
Эдгээр практик нь удаан хугацааны туршид мэдэгдэж байсан. Бид энэ талаар 4 жилийн өмнө ярилцсан. Гэвч 4 жилийн хугацаанд бараг юу ч өөрчлөгдөөгүй.
Гэхдээ энэ тэмдэглэл дээр би албан ёсны хэлэлцүүлгийг дуусгахыг санал болгож байна.
Видео (медиа элемент болгон оруулсан боловч зарим шалтгааны улмаас ажиллахгүй):
Эх сурвалж: www.habr.com