Энэхүү тайланд DevOps-ийн зарим практикийн талаар ярих боловч хөгжүүлэгчийн үүднээс авч үзэх болно. Ерөнхийдөө DevOps-т элссэн бүх инженерүүд хэдэн жилийн турш захиргааны туршлагатай байдаг. Гэхдээ энэ нь хөгжүүлэгч энд байхгүй гэсэн үг биш юм. Ихэнхдээ хөгжүүлэгчид "өнөөгийн яаралтай чухал алдааг" засах завгүй байдаг бөгөөд DevOps талбарыг хурдан харах цаг ч байдаггүй. Зохиогчийн ойлголтоор бол DevOps бол нэгдүгээрт, нийтлэг ойлголт юм. Хоёрдугаарт, энэ нь илүү үр дүнтэй байх боломж юм. Хэрэв та хөгжүүлэгч бол эрүүл саруул ухаантай, багийн тоглогчийн хувьд илүү үр дүнтэй байхыг хүсч байвал энэ тайлан танд зориулагдсан болно.
Би өөрийгөө танилцуулъя, өрөөнд намайг танихгүй хүмүүс байгааг би бүрэн хүлээн зөвшөөрч байна. Намайг Антон Бойко гэдэг, би Microsoft Azure MVP. MVP гэж юу вэ? Энэ бол Model-View-Presenter юм. Загвар өмсөгч-үзэгч-хөтлөгч бол яг би.
Нэмж дурдахад би одоо Ciklum-д шийдлийн архитектороор ажиллаж байна. Саяхан би өөртөө ийм сайхан домэйн худалдаж авсан бөгөөд би ихэвчлэн танилцуулга дээр харуулдаг имэйлээ шинэчилсэн. Та надад хаягаар бичиж болно: me [dog] byokoant.pro. Та надад асуултаа имэйлээр илгээж болно. Би ихэвчлэн тэдэнд хариулдаг. Ганц зүйл бол би улс төр, шашин гэсэн хоёр сэдэвтэй холбоотой асуултуудыг имэйлээр хүлээж авахыг хүсэхгүй байна. Та надад бусад бүх зүйлийн талаар имэйлээр бичиж болно. Хэсэг хугацаа өнгөрөх болно, би хариулах болно.
Өөрийнхөө тухай хэдэн үг:
- Би энэ салбарт ажиллаад 10 жил болж байна.
- Би Microsoft-д ажиллаж байсан.
- Би бол 2014 онд хаа нэгтээ байгуулсан Украйны Азур нийгэмлэгийн үүсгэн байгуулагч. Тэгээд ч манайд байгаа, хөгжүүлсээр л байна.
- Би бас Украйнд зохион байгуулж буй Azure чуулганыг үүсгэн байгуулагчийн аав.
- Би бас Киевт Global Azure Bootcamp зохион байгуулахад тусалдаг.
- Миний хэлсэнчлэн би Microsoft Azure-ийн үнэ цэнэтэй тоглогч.
- Би чуулган дээр байнга ярьдаг. Би чуулган дээр үг хэлэх үнэхээр дуртай. Өнгөрсөн нэг жилийн хугацаанд би 40 орчим удаа тоглолт хийж чадсан. Хэрэв та Украйн, Беларусь, Польш, Болгар, Швед, Дани, Нидерланд, Испанийн хажуугаар өнгөрвөл эсвэл Европын өөр улсыг өгөх эсвэл авах юм бол үүлний сэдэвтэй бага хуралд оролцохдоо, Та намайг илтгэгчдийн жагсаалтаас харж магадгүй.
- Би бас Star Trek-ийн шүтэн бишрэгч.
Хэлэлцэх асуудлын талаар бага зэрэг яръя. Бидний мөрийн хөтөлбөр маш энгийн:
- DevOps гэж юу болох талаар бид ярилцах болно. Энэ яагаад чухал болохыг ярилцъя. Өмнө нь DevOps нь таны анкет дээр бичсэн түлхүүр үг байсан бөгөөд тэр даруйдаа +500 долларын цалин авдаг байсан. Одоо та цалиндаа +500 доллар авахын тулд жишээлбэл анкет дээрээ блокчэйн гэж бичих хэрэгтэй.
- Дараа нь бид энэ юу болохыг бага зэрэг ойлгосны дараа бид DevOps практик гэж юу болох талаар ярих болно. Гэхдээ ерөнхийдөө DevOps-ийн хүрээнд биш, харин хөгжүүлэгчдэд сонирхолтой байж болох DevOps практикийн талаар. Тэд яагаад танд сонирхолтой байж болохыг би танд хэлье. Та яагаад үүнийг хийх ёстойг, мөн энэ нь өвдөлтийг бага мэдрэхэд хэрхэн тусалж болохыг танд хэлэх болно.
Олон хүмүүсийн үзүүлдэг уламжлалт зураг. Энэ нь олон төслүүдэд тохиолддог. Энэ бол манай програм хангамжийг дэмждэг хөгжүүлэлт, үйл ажиллагааны хэлтэстэй болсон үе юм. Мөн эдгээр хэлтэс нь хоорондоо харилцдаггүй.
Магадгүй, хэрэв та DevOps болон үйл ажиллагааны хэлтэст үүнийг тийм ч тодорхой мэдэрч чадаагүй бол Dev болон QA хэлтэстэй адилтгаж болно. Програм хангамж хөгжүүлдэг хүмүүс байдаг, хөгжүүлэгчдийн үзэл бодлоос муу чанарын хяналттай хүмүүс байдаг. Жишээ нь би өөрийнхөө гайхалтай кодыг хадгалах газарт даатгадаг, тэнд сууж байсан нэг новш надад энэ кодыг буцааж өгөөд таны код муу байна гэж хэлдэг.
Энэ бүхэн нь хүмүүс хоорондоо харилцдаггүйгээс болдог. Мөн тэд үл ойлголцлын ханаар бие биедээ зарим багц, зарим програм шидэж, тэдэнтэй ямар нэгэн зүйл хийхийг оролддог.
DevOps соёл нь яг энэ ханыг устгах зорилготой юм, өөрөөр хэлбэл. хүмүүсийг бие биетэйгээ харилцахыг албадаж, ядаж төслийн өөр өөр хүмүүс юу хийдэг, тэдний ажил яагаад чухал болохыг ойлгох.
Бид DevOps-ийн талаар ярихад хэн нэгэн танд DevOps бол төсөл тасралтгүй интеграцитай байх үед гэдгийг хэлэх болно; Хэрэв төсөл нь "дэд бүтцийг код болгон" практикийг хэрэгжүүлбэл DevOps гэж хэн нэгэн хэлэх болно; Хэн нэгэн DevOps-ийн эхний алхам бол функцийг салбарлах, функцийн тугнууд гэж хэлэх болно.
Үндсэндээ энэ бүхэн өөрийнхөөрөө үнэн юм. Гэхдээ эдгээр нь зөвхөн бидэнд байгаа эцсийн дадлага юм. Эдгээр практикт шилжихээсээ өмнө Dev-Ops аргачлалыг төсөлдөө, танай компанид хэрэгжүүлэх 3 үе шатыг харуулсан энэхүү слайдыг үзэхийг санал болгож байна.
Энэ слайд бас хоёр дахь албан бус нэртэй байна. Та DevOps-ийн 3 шадар цэрэг гэж юу болохыг онлайнаар хайж олох боломжтой. Та энэ нийтлэлийг олох боломжтой. Яагаад 3 мушкетёр гэж? Үүний доор: хүмүүс, үйл явц, бүтээгдэхүүн, i.e. PPP - Портос, Портос, Портос. Энд DevOps-ийн 3 мушкетер байна. Энэ нийтлэл нь яагаад чухал, юунд хүргэдэг талаар илүү дэлгэрэнгүй тайлбарласан болно.
DevOps соёлыг хэрэгжүүлж эхлэхэд үүнийг дараах дарааллаар хэрэгжүүлэх нь маш чухал юм.
Эхлээд та хүмүүстэй ярилцах хэрэгтэй. Мөн та хүмүүст энэ нь юу вэ, тэд үүнээс ямар нэг ашиг тусыг хэрхэн хүртэх талаар тайлбарлах хэрэгтэй.
Манай хурлыг DotNet Fest гэж нэрлэдэг. Зохион байгуулагчдын хэлснээр бид энд голчлон хөгжүүлэгчдийн үзэгчдийг урьсан тул танхимд байгаа хүмүүсийн ихэнх нь бүтээн байгуулалтад оролцож байгаа гэж найдаж байна.
Бид хүмүүсийн тухай ярих болно, хөгжүүлэгчид өдөр бүр юу хийхийг хүсдэг талаар ярих болно. Тэд юуг хамгийн их хүсдэг вэ? Тэд шинэ код бичих, шинэ бүтэц ашиглах, шинэ боломжуудыг бий болгохыг хүсч байна. Хөгжүүлэгчид хамгийн багадаа юу хүсдэг вэ? Хуучин алдаануудыг засах. Та надтай санал нэг байна гэж найдаж байна. Үүнийг хөгжүүлэгчид хүсч байна. Тэд шинэ боломжуудыг бичихийг хүсдэг, алдаа засахыг хүсдэггүй.
Тухайн хөгжүүлэгчийн гаргадаг алдааны тоо нь өгзөгнийх нь халааснаас биш харин гар нь хэр шулуун, мөрнөөс нь хэр их ургадаг зэргээс шалтгаална. Гэсэн хэдий ч бид томоохон төсөлтэй байх үед заримдаа бүх зүйлийг хянах боломжгүй байдаг тул илүү тогтвортой, илүү чанартай код бичихэд туслах зарим аргыг ашиглах нь бидэнд сайхан байх болно.
QA-ууд юуг хамгийн их хүсдэг вэ? Тэд танхимд байгаа эсэхийг мэдэхгүй. Хэзээ ч байгаагүй учраас би QA хүсч байна гэж хэлэхэд хэцүү байна. Залуусыг гомдоох хэрэггүй, би хэзээ ч тэгэхгүй гэж найдаж байна гэж хэлэх болно. Гэхдээ би тэдний ажлыг утга учиргүй, ашиггүй гэж үзсэндээ биш, харин өөрийгөө энэ ажлыг үр дүнтэй хийж чадах хүн гэж боддоггүй учраас хийх гэж оролдох ч үгүй. Гэхдээ миний ойлгож байгаагаар QA-д хамгийн их таалагддаггүй зүйл бол өглөө ажилдаа явж, ямар нэгэн регрессийн тестийг байнга явуулж, 3 спринтийн өмнө хөгжүүлэгчдэд мэдээлсэн алдаанууд дээр гишгэж, "Та хэзээ вэ" гэж хэлдэг. "Эрхэм Д Артаньян, энэ алдааг засаарай." Ноён Д'Артаньян түүнд "Тийм ээ, тийм ээ, би үүнийг аль хэдийн зассан" гэж хариулав. Тэгээд яаж нэг алдаа засаад, замдаа 5 хийсэн.
Үйлдвэрлэлд энэ шийдлийг дэмждэг хүмүүс энэ шийдлийг алдаагүй ажиллахыг хүсдэг бөгөөд ингэснээр бүх энгийн хүмүүс баар руу явах баасан гариг бүр серверээ дахин ачаалах шаардлагагүй болно. Хөгжүүлэгчид баасан гарагт ашиглалтад орсон бол админууд нь бямба гараг хүртэл сууж, энэ байршуулалтыг засварлахыг хичээдэг.
Хүмүүс ижил асуудлыг шийдвэрлэхэд чиглэгдсэн гэдгийг тайлбарлавал та үйл явцыг албан ёсны болгоход шилжиж болно. Энэ нь маш чухал юм. Яагаад? Учир нь бид "албан ёсны болгох" гэж хэлэхэд та өөрийн үйл явц хэрхэн явагддагийг наад зах нь салфетка дээр дүрслэх нь чухал юм. Хэрэв та жишээлбэл, QA орчин эсвэл үйлдвэрлэлийн орчинд байршуулах юм бол энэ нь үргэлж ийм дарааллаар явагддаг гэдгийг ойлгох хэрэгтэй; эдгээр үе шатанд бид автомат нэгжийн туршилт, UI тестийг ажиллуулдаг. Байрлуулсны дараа бид байршуулалт сайн эсвэл муу болсон эсэхийг шалгадаг. Гэхдээ та үйлдвэрлэлд нэвтрүүлэхдээ дахин дахин давтагдах ёстой үйлдлүүдийн тодорхой жагсаалттай болсон байна.
Зөвхөн таны үйл явц албан ёсны болсон үед та эдгээр үйл явцыг автоматжуулахад туслах бүтээгдэхүүнийг сонгож эхэлдэг.
Харамсалтай нь, энэ нь эсрэгээрээ тохиолддогийг би маш олон удаа хардаг. Хэн нэгэн "DevOps" гэсэн үгийг сонсмогц тэд шууд Jenkins суулгахыг санал болгож байна, учир нь тэд Jenkins-г суулгасны дараа тэд DevOps-тэй болно гэдэгт итгэдэг. Тэд Женкинсийг суулгаж, Женкинсийн вэб сайт дээрх "Хэрхэн хийх вэ" гэсэн нийтлэлүүдийг уншиж, "Хэрхэн хийх вэ" гэсэн нийтлэлд үйл явцыг оруулахыг оролдсон бөгөөд дараа нь хүмүүс дээр ирж, номонд үүнийг ингэж хийх хэрэгтэй гэж хэлсэн гэж хүмүүсийг нугалав. Тиймээс бид үүнийг ингэж хийдэг.
Энэ нь Женкинс бол муу хэрэгсэл биш юм. Би үүнийг ямар нэгэн байдлаар хэлэх гэсэнгүй. Гэхдээ энэ бол зөвхөн нэг бүтээгдэхүүн юм. Ямар бүтээгдэхүүн хэрэглэх нь таны сүүлчийн шийдвэр байх ёстой бөгөөд таны анхны шийдвэр байх ёсгүй. Таны бүтээгдэхүүн соёл, арга барилын хэрэгжилтэд хөтлөгдөх ёсгүй. Үүнийг ойлгох нь маш чухал бөгөөд яагаад би энэ слайд дээр маш их цаг зарцуулж, энэ бүгдийг удаан тайлбарлаж байна.
DevOps практикийн талаар ерөнхийд нь ярилцъя. Тэд юу вэ? Ялгаа нь юу вэ? Тэдгээрийг хэрхэн туршиж үзэх вэ? Тэд яагаад чухал вэ?
Таны сонссон анхны дадлага бол тасралтгүй интеграцчлал юм. Төсөлд хамрагдаж буй хэн нэгэн нь тасралтгүй интеграци (CI)-тэй байж магадгүй юм.
Хамгийн том асуудал бол би хүнээс ихэвчлэн "Та төсөл дээр CI-тэй юу?" гэж асуухад байдаг. Тэгээд тэр: "Тийм ээ" гэж хэлэхэд би юу хийдэгийг нь асуухад тэр надад автоматжуулалтын үйл явцыг бүхэлд нь дүрсэлсэн. Энэ нь бүхэлдээ үнэн биш юм.
Үнэн хэрэгтээ CI-ийн практик нь өөр өөр хүмүүсийн бичсэн кодыг ямар нэгэн төрлийн нэг кодын суурь болгон нэгтгэх зорилготой юм. Тэгээд л болоо.
CI-ийн хажуугаар ихэвчлэн бусад практикууд байдаг - тухайлбал Тасралтгүй байршуулалт, хувилбарын менежмент, гэхдээ бид дараа нь энэ тухай ярих болно.
CI өөрөө бидэнд өөр өөр хүмүүс код бичдэг бөгөөд энэ кодыг нэг кодын баазад тасралтгүй нэгтгэх ёстой гэж хэлдэг.
Энэ нь бидэнд юу өгдөг вэ, яагаад чухал вэ? Хэрэв бидэнд DotNet байгаа бол энэ нь сайн хэрэг, хөрвүүлсэн хэл, бид програмаа эмхэтгэж болно. Хэрэв энэ нь эмхэтгэсэн бол энэ нь аль хэдийн сайн шинж тэмдэг юм. Энэ нь одоохондоо юу ч гэсэн үг биш, гэхдээ бид ядаж эмхэтгэж болох анхны сайн шинж тэмдэг юм.
Дараа нь бид хэд хэдэн тест хийж болно, энэ нь бас тусдаа дадлага юм. Туршилтууд бүгд ногоон өнгөтэй - энэ бол хоёр дахь сайн шинж тэмдэг юм. Гэхдээ дахин хэлэхэд энэ нь юу ч гэсэн үг биш юм.
Гэхдээ та яагаад үүнийг хийх гэж байгаа юм бэ? Өнөөдөр миний ярих бүх дадал зуршил нь ойролцоогоор ижил утгатай, өөрөөр хэлбэл ойролцоогоор ижил ашиг тустай бөгөөд ойролцоогоор ижил аргаар хэмжигддэг.
Нэгдүгээрт, энэ нь хүргэлтийг хурдасгах боломжийг танд олгоно. Энэ нь хүргэлтийг хурдасгах боломжийг танд хэрхэн олгодог вэ? Бид кодын баазад зарим шинэ өөрчлөлт хийх үед тэр даруй энэ кодоор ямар нэгэн зүйл хийхийг оролдож болно. Пүрэв гарагт бид үүнийг QA Environment-д гаргадаг тул бид пүрэв гараг ирэхийг хүлээхгүй, бид үүнийг яг энд, энд хийдэг.
Би та нарт амьдралынхаа нэг гунигтай түүхийг ярих болно. Энэ бол эрт дээр үед, намайг залуухан, царайлаг байсан. Одоо би аль хэдийн залуу, үзэсгэлэнтэй, ухаалаг, даруухан болсон. Хэсэг хугацааны өмнө би нэг төсөлд хамрагдаж байсан. Бид 30 орчим хөгжүүлэгчээс бүрдсэн том багтай байсан. Мөн бид 10 орчим жил боловсруулсан том, том Энтерпрайз төсөлтэй байсан. Тэгээд бид өөр өөр салбартай байсан. Хадгалах газарт бид хөгжүүлэгчид алхдаг салбартай байсан. Мөн үйлдвэрлэж байгаа кодын хувилбарыг харуулсан салбар байсан.
Үйлдвэрлэлийн салбар нь хөгжүүлэгчдэд боломжтой байсан салбараас 3 сарын хоцорч байсан. Энэ юу гэсэн үг вэ? Энэ нь хөгжүүлэгчдийн буруугаас, тэд үүнийг зөвшөөрсөн учраас, QA-ын буруугаас болж, тэд үүнийг харсан учраас би хаа нэгтээ алдаа гармагц, хэрэв би алдаа хүлээн авлаа гэсэн үг юм. Үйлдвэрлэлд зориулсан засварын даалгавар бол би 3 сарын өмнө кодын өөрчлөлтөө буцаах ёстой. Би 3 сарын өмнө юу байснаа санаж, тэндээ засах гэж оролдох ёстой.
Хэрэв та ийм туршлага хараахан амжаагүй бол гэрийн төсөл дээрээ туршиж үзэх боломжтой. Хамгийн гол нь үүнийг арилжааны хэлбэрээр бүү оролдоорой. Хэдэн мөр код бичээд, зургаан сарын турш мартаад, дараа нь буцаж ирээд, эдгээр кодын мөрүүд юуны тухай, тэдгээрийг хэрхэн засах, оновчтой болгох талаар хурдан тайлбарлахыг хичээ. Энэ бол маш их сэтгэл хөдөлгөм туршлага юм.
Хэрэв бид тасралтгүй интеграцийн дадлагатай бол энэ нь намайг код бичиж дуусмагц хэд хэдэн автоматжуулсан хэрэгслээр шалгах боломжийг бидэнд олгодог. Энэ нь надад бүрэн дүр зургийг өгөхгүй байж болох ч энэ нь дор хаяж зарим эрсдлийг арилгах болно. Хэрэв ямар нэгэн алдаа гарвал би энэ тухай яг одоо, өөрөөр хэлбэл хэдхэн минутын дараа мэдэх болно. Би 3 сарыг буцаах шаардлагагүй болно. Би ердөө 2 минут буцаахад л хангалттай. Сайн кофены машинд 2 минутын дотор кофе чанаж амжихгүй тул үнэхээр сайхан байна.
Энэ нь төсөл бүр дээр дахин давтагдах боломжтой, өөрөөр хэлбэл. зөвхөн таны тохируулсан зүйл биш. Та практикийг өөрөө давтаж болно, мөн төсөлд хийсэн шинэ өөрчлөлт болгонд CI өөрөө давтагдах болно. Энэ нь танай баг илүү үр дүнтэй ажилладаг тул нөөцийг оновчтой болгох боломжийг танд олгоно. Та 3 сарын өмнө хамтран ажиллаж байсан кодоос тань алдаа гарах нөхцөл байдал байхгүй болно. Та ямар нэг зүйлийг засаж эхлэхээсээ өмнө юу болсныг ойлгохын тулд эхний хоёр цагийг сууж, контекстийн мөн чанарыг ойлгохыг хичээх үед контекст сэлгэх боломжгүй болно.
Энэ бясалгалын амжилт эсвэл алдааг бид хэрхэн хэмжих вэ? Хэрэв та CI төсөл дээр бидний хэрэгжүүлсэн зүйлийг том даргад тайлагнавал тэр бла бла бла сонсоно. Бид хэрэгжүүлсэн, за, гэхдээ яагаад, энэ нь бидэнд юу авчирсан бэ, бид үүнийг хэрхэн хэмжих вэ, бид үүнийг хэр зөв эсвэл буруу хэрэгжүүлж байна вэ?
Эхнийх нь, CI-ийн ачаар бид илүү олон удаа, илүү нарийвчлалтай байршуулах боломжтой болсон, учир нь бидний код илүү тогтвортой байдаг. Яг үүнтэй адил бид системээс яг эндээс, яг одоо кодын алдаа юу байна вэ гэсэн хариултыг хүлээн авч байгаа тул алдааг олох цаг багасч, энэ алдааг засах цаг ч яг багасдаг.
Бидэнд байгаа өөр нэг дадлага бол Автоматжуулалтын туршилтын дадлага бөгөөд энэ нь ихэвчлэн CI дадлагатай хамт ирдэг. Тэд хөтлөлцөн явдаг.
Энд юуг ойлгох нь чухал вэ? Бидний тестүүд өөр гэдгийг ойлгох нь чухал. Мөн автоматжуулсан тест бүр өөрийн асуудлыг шийдвэрлэхэд чиглэгддэг. Жишээлбэл, бид модулийг тусад нь турших боломжийг олгодог нэгж тестүүдтэй, i.e. Энэ нь вакуум орчинд хэрхэн ажилладаг вэ? Энэ сайн байна.
Бидэнд өөр өөр модулиуд хоорондоо хэрхэн уялдаж байгааг ойлгох боломжийг олгодог нэгтгэх тестүүд байдаг. Энэ нь бас сайн байна.
Бид хэрэглэгчийн интерфэйстэй ажиллах нь хэрэглэгчийн тавьсан тодорхой шаардлагад хэр нийцэж байгааг шалгах боломжийг олгодог UI автоматжуулалтын туршилтуудтай байж болно.
Таны ажиллуулж буй тусгай тестүүд нь таны хэр олон удаа ажиллуулахад нөлөөлж болно. Нэгжийн тестийг ихэвчлэн богино, жижиг хэлбэрээр бичдэг. Мөн тэдгээрийг тогтмол ажиллуулж болно.
Хэрэв бид UI автоматжуулалтын туршилтын тухай ярьж байгаа бол таны төсөл жижиг бол сайн хэрэг. Таны UI автоматжуулалтын туршилтууд хангалттай хугацаа шаардагдана. Гэхдээ ихэвчлэн UI автоматжуулалтын тест нь томоохон төсөл дээр хэдэн цаг зарцуулдаг зүйл юм. Тэгээд хэдхэн цаг байвал сайн. Цорын ганц зүйл бол тэдгээрийг бүтээх бүрт ажиллуулах нь утгагүй юм. Тэднийг шөнийн цагаар ажиллуулах нь утга учиртай. Өглөө хүн бүр ажилдаа ирэхэд: шалгагч, хөгжүүлэгчид хоёулаа бид шөнийн цагаар UI автомат тестийг ажиллуулж, эдгээр үр дүнг авсан гэсэн тайланг хүлээн авсан. Энд, таны бүтээгдэхүүн зарим шаардлагад нийцэж байгаа эсэхийг шалгах серверийн нэг цаг ажиллах нь ижил чанарын хяналтын инженерийн нэг цаг ажиллахаас хамаагүй хямд байх болно, тэр нь хоол хүнс, талархалын төлөө ажилладаг бага чанарын инженер байсан ч гэсэн. Үүний зэрэгцээ машиныг нэг цаг ажиллуулах нь хямд байх болно. Тийм учраас үүнд хөрөнгө оруулах нь зүйтэй юм.
Надад өөр нэг төсөл бий. Бид энэ төсөл дээр хоёр долоо хоногийн спринт хийсэн. Төсөл том, санхүүгийн салбарт чухал ач холбогдолтой, алдаа гаргах боломжгүй байсан. Хоёр долоо хоног үргэлжилсэн спринтийн дараа хөгжлийн мөчлөгийн дараа дахин 4 долоо хоног үргэлжилсэн туршилтын процесс явагдсан. Эмгэнэлт явдлын цар хүрээг төсөөлөхийг хичээ. Бид хоёр долоо хоногийн турш код бичиж, дараа нь CodeFreeze програмыг хийж, програмын шинэ хувилбарт багцалж, шалгагчдад түгээдэг. Тестчид үүнийг дахин 4 долоо хоног туршина, өөрөөр хэлбэл. Тэднийг туршиж байх хооронд бидэнд өөр хоёр хувилбарыг бэлтгэх цаг байна. Энэ бол үнэхээр харамсалтай хэрэг.
Хэрэв та илүү бүтээмжтэй байхыг хүсч байвал автоматжуулсан туршилтын практикийг хэрэгжүүлэх нь зүйтэй гэж бид тэдэнд хэлсэн, учир нь энэ нь яг одоо таныг өвтгөж байна.
Тасралтгүй байршуулах дадлага хийх. Гайхалтай, та бүтээж дууслаа. Энэ аль хэдийн сайн байна. Таны кодыг эмхэтгэсэн. Одоо энэ бүтээн байгуулалтыг зарим орчинд байрлуулах нь сайхан байх болно. Хөгжүүлэгчдийн орчинд гэж хэлье.
Яагаад чухал вэ? Эхлээд та байршуулах үйл явцын тусламжтайгаар хэр амжилттай байгаагаа харж болно. Би ийм төслүүдтэй таарч, "Та програмын шинэ хувилбарыг хэрхэн ашиглах вэ?" гэж асуухад залуус надад: "Бид үүнийг угсарч, зип архивт хийдэг. Бид админ руу шуудангаар илгээдэг. Админ энэ архивыг татаж аваад өргөжүүлдэг. Мөн бүх оффис сервер шинэ хувилбарыг авахын төлөө залбирч эхэлдэг."
Энгийн зүйлээс эхэлцгээе. Жишээлбэл, тэд CSS-г архивт оруулахаа мартсан эсвэл java-скрипт файлын нэр дэх hashtag-ыг өөрчлөхөө мартсан байна. Бид серверт хүсэлт гаргахад хөтөч нь энэ java-скрипт файлтай байна гэж бодоод татаж авахгүй байхаар шийддэг. Тэгээд хуучин хувилбар байсан, ямар нэг зүйл дутуу байсан. Ерөнхийдөө олон асуудал гарч ирж болно. Тиймээс, Тасралтгүй байршуулалтын дадлага нь та цэвэр лавлагаа зураг авч, түүнийг цоо цэвэр шинэ орчинд байршуулсан бол юу тохиолдохыг ядаж шалгах боломжийг олгодог. Энэ нь хаашаа хөтөлж байгааг харж болно.
Түүнчлэн, та кодыг хооронд нь нэгтгэх үед, i.e. командын хооронд энэ нь UI дээр хэрхэн харагдахыг харах боломжийг танд олгоно.
Олон тооны ванилийн java-скрипт ашиглахад тохиолддог бэрхшээлүүдийн нэг бол хоёр хөгжүүлэгч цонхны объектод ижил нэртэй хувьсагчийг санамсаргүйгээр зарласан явдал юм. Дараа нь таны азаас хамаарна. Хэний java-скрипт файлыг хоёр дахь удаагаа татаж авбал нөгөөгийнх нь өөрчлөлтийг дарж бичнэ. Энэ нь бас их сэтгэл хөдөлгөм юм. Та орж ирдэг: нэг зүйл нэг хүнд тусалдаг, нөгөө нь нөгөөд тохирохгүй. Энэ бүхэн үйлдвэрлэлд гарч ирэхэд энэ нь "гайхалтай" юм.
Бидэнд байгаа дараагийн дадлага бол автоматаар сэргээх, тухайлбал програмын өмнөх хувилбар руу буцах явдал юм.
Энэ нь яагаад хөгжүүлэгчдэд чухал вэ? Компьютер том, программ нь жижиг байсан алс холын 90-ээд оны үеийг санаж байгаа хүмүүс одоо ч байдаг. Мөн вэб хөгжүүлэх цорын ганц арга зам нь PHP байсан. Энэ нь PHP нь муу хэл биш ч гэсэн тийм ч муу хэл юм.
Гэхдээ асуудал өөр байсан. Бид php сайтынхаа шинэ хувилбарыг байрлуулахдаа үүнийг хэрхэн байршуулсан бэ? Ихэнхдээ бид Far Manager эсвэл өөр зүйлийг нээдэг. Мөн эдгээр файлуудыг FTP рүү байршуулсан. Бидэнд жижиг, жижиг алдаа байгааг гэнэт ойлгосон, жишээлбэл, цэг таслал тавихаа мартсан эсвэл мэдээллийн сангийн нууц үгийг өөрчлөхөө мартсан, мөн мэдээллийн сангийн нууц үг байдаг бөгөөд энэ нь локал хост дээр байдаг. Мөн бид FTP-тэй хурдан холбогдож, тэнд байгаа файлуудыг засахаар шийдсэн. Энэ бол зүгээр л гал! Энэ бол 90-ээд оны үед алдартай байсан зүйл юм.
Гэхдээ, хэрэв та хуанли харж амжаагүй бол 90-ээд он бараг 30 жилийн өмнө байсан. Одоо бүх зүйл арай өөрөөр болж байна. Тэд танд хэлэхдээ: "Бид үйлдвэрлэлд очсон боловч ямар нэг зүйл буруу болсон. Энд таны FTP нэвтрэлт болон нууц үг байна, үйлдвэрлэлд холбогдож, тэнд хурдан засаарай." Хэрэв та Чак Норрис бол энэ нь ажиллах болно. Хэрэв тийм биш бол та нэг алдаа засвал дахиад 10 алдаа гаргах эрсдэлтэй.Тиймээс л өмнөх хувилбар руугаа буцах дадлага нь танд маш их зүйлийг хийх боломжийг олгодог.
Хэдийгээр ямар нэгэн муу зүйл хаа нэгтээ гарсан ч энэ нь муу, гэхдээ үхэлд хүргэхгүй. Та өмнөх хувилбар руугаа буцах боломжтой. Хэрэв энэ нэр томъёонд үүнийг ойлгоход хялбар бол үүнийг нөөц гэж нэрлэнэ үү. Та өмнөх хувилбар руугаа буцах боломжтой бөгөөд хэрэглэгчид таны бүтээгдэхүүнтэй ажиллах боломжтой хэвээр байх бөгөөд танд хангалттай буфер хугацаа байх болно. Та тайвнаар, яарахгүйгээр, энэ бүгдийг авч, дотооддоо туршиж, засч, дараа нь шинэ хувилбарыг байршуулж болно. Үүнийг хийх нь үнэхээр утга учиртай юм.
Одоо өмнөх хоёр дадлыг ямар нэгэн байдлаар нэгтгэхийг хичээцгээе. Бид Release Management нэртэй гурав дахь хувилбарыг авах болно.
Бид Continuous Deployment-ийн тухай сонгодог хэлбэрээр ярихдаа бид репозитороос аль нэг салбараас код татаж аваад, эмхэтгэж, байршуулах ёстой гэж хэлдэг. Бид ижил орчинтой байвал сайн. Хэрэв бидэнд хэд хэдэн орчин байгаа бол энэ нь бид нэг амлалтаас ч гэсэн кодыг байнга татах ёстой гэсэн үг юм. Бид тэр болгонд нь татаж, бүр барьж, шинэ орчинд байрлуулна. Нэгдүгээрт, энэ бол цаг хугацаа, учир нь хэрэв та том төсөлтэй, 90-ээд оноос хойш ирсэн бол хэдэн цаг зарцуулж болно.
Үүнээс гадна бас нэг гунигтай зүйл бий. Та нэг машин дээр бүтээж байхдаа ч гэсэн ижил эх үүсвэрийг бүтээх болно, гэхдээ энэ машин сүүлийн үеийн үеийнхтэй ижил төлөвт байна гэсэн баталгаа байхгүй хэвээр байна.
Хэн нэгэн орж ирээд DotNet-ийг танд зориулж шинэчилсэн эсвэл эсрэгээр хэн нэгэн ямар нэг зүйлийг устгахаар шийдсэн гэж бодъё. Дараа нь та хоёр долоо хоногийн өмнө энэ үйлдлээс хойш бид барилга барьж байсан бөгөөд бүх зүйл сайхан байсан гэж танин мэдэхүйн зөрчилтэй байна, гэхдээ одоо бидний бүтээх гэж байгаа машин, ижил үүрэг, код шиг санагдаж байна, гэхдээ энэ нь ажиллахгүй байна. . Та үүнтэй удаан хугацаанд харьцах болно, гэхдээ та үүнийг олж мэдэх нь үнэн биш юм. Ядаж л мэдрэлээ маш их эвдэх болно.
Тиймээс Release Management практик нь олдворын агуулах эсвэл галерей эсвэл номын сан гэж нэрлэгддэг нэмэлт хийсвэрлэлийг нэвтрүүлэхийг санал болгож байна. Та үүнийг хүссэнээрээ дуудаж болно.
Гол санаа нь бид өөр өөр орчинд ашиглахад бэлэн байгаа салбартаа ямар нэгэн үүрэг хүлээсэн даруйдаа бид энэ амлалтаас програмуудыг цуглуулж, энэ програмд хэрэгтэй бүх зүйлээ цуглуулдаг. зип архив руу оруулаад найдвартай хадгалах санд хадгалаарай. Мөн энэ сангаас бид энэ зип архивыг хүссэн үедээ авах боломжтой.
Дараа нь бид үүнийг авч, автоматаар хөгжүүлэлтийн орчинд байрлуулна. Бид тэнд уралддаг, хэрэв бүх зүйл сайн байвал бид дэвжээнд гарна. Хэрэв бүх зүйл сайн байвал бид яг нэг удаа эмхэтгэсэн ижил хоёртын файлуудыг үйлдвэрлэлд байрлуулна.
Нэмж дурдахад, ийм галерейтай бол энэ нь өмнөх хувилбар руу буцах тухай ярихдаа сүүлчийн слайд дээр дурдсан эрсдлүүдийг шийдвэрлэхэд тусалдаг. Хэрэв та санамсаргүйгээр ямар нэг зүйл буруу байршуулсан бол энэ галерейгаас өмнөх хувилбарыг нь авч, ижил аргаар эдгээр орчинд байршуулах боломжтой. Энэ нь ямар нэг зүйл буруу болвол өмнөх хувилбар руугаа амархан буцах боломжийг олгоно.
Өөр нэг гайхалтай дасгал байна. Бид програмуудаа өмнөх хувилбар руу буцаах үед өмнөх хувилбарын дэд бүтэц хэрэгтэй болно гэдгийг та бид бүгд ойлгож байна.
Виртуал дэд бүтцийн талаар ярихад олон хүмүүс үүнийг админуудын тохируулсан зүйл гэж боддог. Хэрэв танд програмынхаа шинэ хувилбарыг туршиж үзэхийг хүсч буй шинэ сервер авах шаардлагатай бол админ эсвэл devops руу тасалбар бичих ёстой. Девопууд үүнд 3 долоо хоног шаардагдана. Тэгээд 3 долоо хоногийн дараа тэд танд нэг цөм, хоёр гигабайт RAM, DotNet-гүй Windows сервер бүхий виртуал машин суулгасан гэж хэлэх болно. Та: "Гэхдээ би DotNet-ийг хүссэн." Тэд: "За, 3 долоо хоногийн дараа ирээрэй."
Гол санаа нь Дэд бүтцийг кодын практик болгон ашигласнаар та виртуал дэд бүтцээ өөр нэг нөөц гэж үзэх боломжтой.
Магадгүй, хэрэв та нарын хэн нэгэн нь DotNet дээр програм хөгжүүлж байгаа бол та Entity Framework нэртэй номын сангийн талаар сонссон байх. Entity Framework нь Майкрософт идэвхтэй шахаж байгаа аргуудын нэг гэдгийг та сонссон байх. Өгөгдлийн сантай ажиллахын тулд энэ нь Code First гэж нэрлэгддэг арга юм. Энэ нь та өгөгдлийн сангаа хэрхэн харуулахыг хүсч байгаагаа кодоор тайлбарлах явдал юм. Дараа нь та програмыг байрлуулна. Энэ нь мэдээллийн сантай холбогдож, аль хүснэгт байгаа, аль хүснэгт байхгүй байгааг өөрөө тодорхойлж, танд хэрэгтэй бүх зүйлийг бий болгодог.
Та дэд бүтцээ ч мөн адил хийж болно. Төсөлд өгөгдлийн сан хэрэгтэй юу эсвэл төсөлд Windows сервер хэрэгтэй юу гэдэг ялгаа байхгүй. Энэ бол зүгээр л нөөц юм. Мөн та энэ нөөцийг үүсгэхийг автоматжуулж болно, та энэ нөөцийн тохиргоог автоматжуулж болно. Үүний дагуу та ямар нэгэн шинэ үзэл баримтлал, шинэ хандлагыг туршиж үзэхийг хүсэх бүртээ devops руу тасалбар бичих шаардлагагүй бөгөөд бэлэн загварууд, бэлэн скриптүүдээс тусгаарлагдсан дэд бүтцийг байрлуулж, хэрэгжүүлэх боломжтой. Таны бүх туршилтууд энд байна. Та үүнийг устгаж, зарим илэрц авч, энэ талаар дэлгэрэнгүй мэдээлэх боломжтой.
Одоо байгаа бөгөөд бас чухал боловч цөөхөн хүн ашигладаг дараагийн дадлага бол Хэрэглээний гүйцэтгэлийн хяналт юм.
Програмын гүйцэтгэлийн хяналтын талаар би ганцхан зүйлийг хэлэхийг хүссэн. Энэ практикт хамгийн чухал нь юу вэ? Хэрэглээний гүйцэтгэлийн хяналт нь орон сууцыг засахтай ижил төстэй зүйл юм. Энэ бол эцсийн төлөв биш, энэ бол үйл явц юм. Та үүнийг тогтмол хийх хэрэгтэй.
Нэг ёсондоо програмын гүйцэтгэлийн хяналтыг бараг бүх бүтэц дээр хийх нь сайн хэрэг байх болно, гэхдээ таны ойлгож байгаагаар энэ нь үргэлж боломжгүй байдаг. Гэхдээ хамгийн багадаа үүнийг хувилбар бүрт хийх шаардлагатай.
Яагаад чухал вэ? Учир нь хэрэв та гүйцэтгэл гэнэт уналтанд орвол яагаад гэдгийг тодорхой ойлгох хэрэгтэй. Хэрэв танай баг хоёр долоо хоногийн спринт хийдэг бол ядаж хоёр долоо хоногт нэг удаа та програмаа тодорхой тогтсон процессор, RAM, диск гэх мэт тусдаа серверт байршуулах хэрэгтэй. Мөн тэдгээртэй ижил гүйцэтгэлийн тестийг ажиллуул. . Та үр дүнг авна. Өмнөх спринтээс хэрхэн өөрчлөгдсөнийг хараарай.
Хэрэв та бууралт хаа нэгтээ огцом буурсаныг олж мэдвэл энэ нь зөвхөн сүүлийн хоёр долоо хоногт гарсан өөрчлөлтийн улмаас болсон гэсэн үг юм. Энэ нь асуудлыг илүү хурдан тодорхойлж, засах боломжийг танд олгоно. Дахин хэлэхэд эдгээр нь та үүнийг хэр амжилттай хийснийг хэмжих боломжтой ижил хэмжүүрүүд юм.
Бидэнд байгаа дараагийн дадлага бол Тохиргооны удирдлагын дадлага юм. Үүнийг нухацтай авч үзэх хүн тун цөөхөн. Гэхдээ надад итгээрэй, энэ бол үнэхээр ноцтой зүйл юм.
Саяхан нэг хөгжилтэй түүх гарсан. Залуус над дээр ирээд: "Бидэнд манай өргөдлийн аюулгүй байдлын шалгалт хийхэд туслаач." Бид хамтдаа кодыг удаан хугацаанд харсан, тэд надад програмын талаар хэлж, диаграмм зурсан. Мөн нэмэх эсвэл хасах бүх зүйл логик, ойлгомжтой, аюулгүй байсан, гэхдээ нэг ГЭХДЭЭ! Тэдгээрийн эх сурвалжийн удирдлагад IP мэдээллийн сантай үйлдвэрлэлийн файлууд, эдгээр мэдээллийн сантай холбогдох нэвтрэх нэр, нууц үг гэх мэт тохиргооны файлууд байсан.
Тэгээд би: "Залуус аа, та нар үйлдвэрлэлийн орчноо галт ханаар хаасан байна, гэхдээ та үйлдвэрлэлийн мэдээллийн сангийн нэвтрэх, нууц үг нь эх сурвалжийн удирдлагад байгаа бөгөөд ямар ч хөгжүүлэгч үүнийг унших боломжтой байгаа нь аюулгүй байдлын асар том эрсдэл юм. . Таны програм код талаасаа хэчнээн аюулгүй байсан ч, хэрэв та үүнийг эх сурвалжийн хяналтад үлдээвэл та хэзээ ч хаана ч шалгалт өгөхгүй." Би үүнийг чинь л яриад байгаа юм шүү дээ.
Тохиргооны удирдлага. Бид өөр өөр орчинд өөр өөр тохиргоотой байж болно. Жишээлбэл, бид QA, демо, үйлдвэрлэлийн орчин гэх мэт мэдээллийн санд өөр өөр нэвтрэх нэр, нууц үгтэй байж болно.
Энэ тохиргоог бас автоматжуулж болно. Энэ нь үргэлж програмаас тусдаа байх ёстой. Яагаад? Учир нь та програмыг нэг удаа бүтээж, дараа нь SQL серверт ийм IP, ийм IP хаягаар холбогдсон эсэхээс үл хамааран програм нь адилхан ажиллах ёстой. Тиймээс, хэрэв гэнэт та нарын хэн нэг нь кодын холболтын мөрийг хатуу кодлосон хэвээр байвал би чамайг олж, надтай нэг төсөлд хамрагдах юм бол шийтгэх болно гэдгийг санаарай. Үүнийг үргэлж тусдаа тохиргоонд, жишээлбэл, web.config дээр байрлуулдаг.
Мөн энэ тохиргоог аль хэдийн тусад нь удирддаг, өөрөөр хэлбэл хөгжүүлэгч, администратор хоёр нэг өрөөнд ирж сууж болох яг тэр мөч юм. Хөгжүүлэгч нь: "Хараач, миний програмын хоёртын файлууд энд байна. Тэд ажилладаг. Аппликешн ажиллахын тулд мэдээллийн сан хэрэгтэй. Энд хоёртын файлын хажууд файл байна. Энэ файлд энэ талбар нь нэвтрэх, энэ нь нууц үг, энэ нь IP хаягийг хариуцна. Үүнийг хаана ч байрлуул." Энэ нь админд энгийн бөгөөд ойлгомжтой. Тэр энэ тохиргоог удирдаж, хаана ч байрлуулж чадна.
Миний ярихыг хүсч буй сүүлчийн дасгал бол үүлтэй маш их холбоотой дасгал юм. Хэрэв та үүлэн дээр ажилладаг бол энэ нь хамгийн их үр нөлөөг авчирдаг. Энэ бол таны орчныг автоматаар устгах явдал юм.
Энэ хуралд миний ажилладаг багуудаас хэд хэдэн хүн байгааг би мэднэ. Мөн надтай хамтран ажилладаг бүх багуудын хувьд бид энэ дадлагыг ашигладаг.
Яагаад? Мэдээж хэрэг, хөгжүүлэгч бүр 24/7 ажиллах виртуал машинтай бол үнэхээр сайхан байх болно. Гэхдээ энэ нь таны хувьд мэдээ байж магадгүй, та анхаарлаа хандуулаагүй байж магадгүй, гэхдээ хөгжүүлэгч өөрөө 24/7 ажилладаггүй. Хөгжүүлэгч ихэвчлэн өдөрт 8 цаг ажилладаг. Тэр ажилдаа эрт ирсэн ч том өдрийн хоол иддэг бөгөөд энэ үеэр фитнесст явдаг. Хөгжүүлэгч эдгээр нөөцийг үнэхээр ашигладаг бол өдөрт 12 цаг байг. Манай хууль тогтоомжийн дагуу долоо хоногт 5 хоногийн 7 нь ажлын өдөр гэж тооцогддог.
Үүний дагуу ажлын өдрүүдэд энэ машин 24 цаг ажиллахгүй, зөвхөн 12 цаг ажиллах ёстой бөгөөд амралтын өдрүүдэд энэ машин огт ажиллахгүй байх ёстой. Бүх зүйл маш энгийн юм шиг санагдаж байна, гэхдээ энд юу хэлэх нь чухал вэ? Энэхүү энгийн практикийг энэхүү үндсэн хуваарь дээр хэрэгжүүлснээр эдгээр орчныг арчлах зардлыг 70%-иар бууруулах, өөрөөр хэлбэл та өөрийн төхөөрөмж, QA, demo, орчны үнийг аваад 3-т хуваана.
Үлдсэн мөнгөө юу хийх вэ гэдэг асуулт гарч ирнэ. Жишээлбэл, хөгжүүлэгчид ReSharper худалдаж аваагүй бол худалдаж авах хэрэгтэй. Эсвэл коктейль үдэшлэг хий. Хэрэв та өмнө нь хөгжүүлэгч болон QA аль аль нь бэлчдэг байсан нэг орчинтой байсан бол одоо та 3 өөр орчинг тусгаарлах боломжтой бөгөөд хүмүүс бие биедээ саад болохгүй.
Тасралтгүй гүйцэтгэлийн хэмжилт бүхий слайдын тухайд, хэрэв бид төслийн мэдээллийн санд 1 бүртгэлтэй байсан бол хоёр сарын дараа нэг сая байгаа бол гүйцэтгэлийг хэрхэн харьцуулах вэ? Яагаад гэдгийг яаж ойлгох вэ, гүйцэтгэлийг хэмжих нь ямар учиртай вэ?
Энэ бол сайн асуулт, учир нь та гүйцэтгэлийг ижил нөөц дээр үргэлж хэмжих хэрэгтэй. Өөрөөр хэлбэл, та шинэ код гаргаж, гүйцэтгэлийг шинэ код дээр хэмждэг. Жишээлбэл, та өөр өөр гүйцэтгэлийн хувилбаруудыг туршиж үзэх хэрэгтэй, 1 хэрэглэгчтэй, өгөгдлийн сангийн хэмжээ 000 гигабайт байдаг хөнгөн ачаалал дээр програм хэрхэн ажилладагийг шалгахыг хүсч байна гэж бодъё. Та үүнийг хэмжиж, тоонуудыг авсан. Дараа нь бид өөр хувилбарыг авч үзье. Жишээлбэл, 5 хэрэглэгч, мэдээллийн сангийн хэмжээ 5 терабайт. Бид үр дүнг нь авч, санаж байна.
Энд юу чухал вэ? Энд хамгийн чухал зүйл бол хувилбар, өгөгдлийн хэмжээ, нэгэн зэрэг хэрэглэгчдийн тоо гэх мэт зэргээс шалтгаалан та тодорхой хязгаарт хүрч болзошгүй юм. Жишээлбэл, сүлжээний картын хязгаар, хатуу дискний хязгаар, процессорын чадамжийн хязгаар хүртэл. Энэ бол таны ойлгоход чухал ач холбогдолтой зүйл юм. Өөр өөр хувилбаруудад та тодорхой хязгаарлалттай тулгардаг. Мөн та тэдгээрийг цохихдоо тоог ойлгох хэрэгтэй.
Бид тусгай туршилтын орчинд гүйцэтгэлийг хэмжих талаар ярьж байна уу? Энэ нь үйлдвэрлэл биш гэсэн үг үү?
Тийм ээ, энэ бол үйлдвэрлэл биш, энэ бол туршилтын орчин бөгөөд өмнөх хэмжилтүүдтэй харьцуулах боломжтой үргэлж ижил байдаг.
Ойлголоо баярлалаа!
Хэрэв асуулт байхгүй бол дуусгах боломжтой гэж бодож байна. Баярлалаа!
Эх сурвалж: www.habr.com