Есеп кейбір DevOps тәжірибелері туралы айтады, бірақ әзірлеушінің көзқарасы бойынша. Әдетте, DevOps-қа қосылатын барлық инженерлердің бірнеше жылдық әкімшілік тәжірибесі бар. Бірақ бұл әзірлеушіге бұл жерде орын жоқ дегенді білдірмейді. Көбінесе әзірлеушілер «күннің келесі шұғыл маңызды қатесін» түзетумен айналысады және оларда DevOps өрісін жылдам қарап шығуға уақыттары болмайды. Автордың түсінігі бойынша, DevOps - бұл, біріншіден, ақылға қонымды. Екіншіден, бұл тиімдірек болу мүмкіндігі. Егер сіз әзірлеуші болсаңыз, ақылға қонымды болсаңыз және команда ойыншысы ретінде тиімдірек болғыңыз келсе, бұл есеп сізге арналған.
Өзімді таныстырып өтейін, бөлмеде мені танымайтын адамдар бар екенін толық мойындаймын. Менің атым Антон Бойко, мен Microsoft Azure MVPмін. MVP дегеніміз не? Бұл модель-көрініс-баяндамашы. Модель-көрініс-баяндамашы - дәл мен.
Сонымен қатар, мен қазір Циклумда шешім сәулетшісі қызметін атқарамын. Жақында мен өзіме осындай әдемі домен сатып алдым және мен әдетте презентацияларда көрсететін электрондық поштамды жаңарттым. Сіз маған мына мекенжайға жаза аласыз: me [dog] byokoant.pro. Сіз маған сұрақтарыңызды электронды пошта арқылы жібере аласыз. Мен әдетте оларға жауап беремін. Жалғыз нәрсе, мен екі тақырыпқа қатысты сұрақтарды электрондық пошта арқылы алғым келмейді: саясат және дін. Сіз маған барлық басқа нәрселер туралы электрондық пошта арқылы жаза аласыз. Біраз уақыт өтеді, жауап беремін.
Өзім туралы бірнеше сөз:
- Бұл салада жүргеніме 10 жыл болды.
- Мен Microsoft-та жұмыс істедім.
- Мен 2014 жылы бір жерде негізін қалаған украиналық Azure қауымдастығының негізін қалаушы әкемін. Ал бізде әлі де бар және оны дамытып жатырмыз.
- Мен Украинада өтіп жатқан Azure конференциясының негізін қалаушының әкесімін.
- Мен Киевте Global Azure Bootcamp ұйымдастыруға көмектесемін.
- Мен айтқанымдай, мен Microsoft Azure MVP-мін.
- Мен конференцияларда жиі сөйлеймін. Мен конференцияларда сөйлегенді жақсы көремін. Соңғы бір жылда мен 40-қа жуық рет өнер көрсеттім. Егер сіз Украина, Беларусь, Польша, Болгария, Швеция, Дания, Нидерланды, Испания арқылы өтсеңіз немесе Еуропадағы басқа елге берсеңіз немесе алсаңыз, онда бұлтты тақырыбы бар конференцияға барған кезде, Сіз мені спикерлер тізімінде көре аласыз.
- Мен де Star Trek жанкүйерімін.
Күн тәртібі туралы аздап сөйлесейік. Біздің күн тәртібіміз өте қарапайым:
- Біз DevOps деген не екенін айтатын боламыз. Бұл неліктен маңызды екенін айтайық. Бұрын DevOps түйіндемеңізге жазған және бірден +500 доллар жалақы алатын кілт сөз болды. Енді айлығыңызға +500 доллар алу үшін түйіндемеңізге мысалы блокчейн жазуыңыз керек.
- Содан кейін, бұл не екенін аздап түсінген кезде, біз DevOps тәжірибесінің не екенін айтатын боламыз. Бірақ жалпы DevOps контекстінде емес, әзірлеушілерді қызықтыруы мүмкін DevOps тәжірибелері туралы. Неліктен олар сізді қызықтыруы мүмкін екенін айтамын. Неліктен мұны істеу керек екенін және бұл ауырсынуды азайтуға қалай көмектесетінін айтамын.
Көптеген адамдар көрсететін дәстүрлі сурет. Бұл көптеген жобаларда орын алады. Бұл біздің бағдарламалық жасақтамаға қолдау көрсететін әзірлеу және операциялық бөлімдеріміз бар кезде. Ал бұл бөлімдер бір-бірімен байланыспайды.
Мүмкін, егер сіз оны DevOps және операциялық бөлімдерде соншалықты анық сезіне алмасаңыз, Dev және QA бөлімдеріне ұқсастық жасай аласыз. Бағдарламалық жасақтаманы әзірлейтін адамдар бар және әзірлеушілердің көзқарасы бойынша нашар QA адамдары бар. Мысалы, мен өзімнің керемет кодымды репозиторийге тапсырамын, сонда бір арамза отыр, ол маған осы кодты қайтарып, сіздің кодыңыз нашар деп айтады.
Мұның бәрі адамдар бір-бірімен байланыспағандықтан болады. Және олар кейбір пакеттерді, кейбір қосымшаларды бір-біріне түсінбеушілік қабырғасы арқылы лақтырып, олармен бірдеңе жасауға тырысады.
Дәл осы қабырға DevOps мәдениетін жоюға арналған, яғни. адамдарды бір-бірімен қарым-қатынас жасауға мәжбүрлеу және кем дегенде жобадағы әртүрлі адамдар не істейтінін және олардың жұмысының неге маңызды екенін түсіну.
Біз DevOps туралы айтатын болсақ, біреу сізге DevOps жобаның үздіксіз интеграциясы болған кезде екенін айтады; біреу, егер жоба «инфрақұрылым код ретінде» тәжірибесін жүзеге асырса, DevOps деп айтады; біреу DevOps-қа бірінші қадам мүмкіндіктерді тармақтау, мүмкіндік жалаулары деп айтады.
Негізінде, мұның бәрі өзінше шындық. Бірақ бұл бізде бар соңғы тәжірибелер ғана. Осы тәжірибелерге көшпес бұрын мен өз жобаңызда, компанияңызда Dev-Ops әдіснамасын енгізудің 3 кезеңін көрсететін осы слайдты қарауды ұсынамын.
Бұл слайдтың екінші бейресми атауы да бар. DevOps-тің 3 мушкетері қандай екенін білу үшін онлайн іздеуге болады. Бұл мақаланы табуыңыз мүмкін. Неліктен 3 мушкетер? Оның астында былай делінген: адамдар, процестер және өнімдер, т.б. PPP – Портос, Портос және Портос. Міне, DevOps-тің 3 мушкетері. Бұл мақалада бұл неліктен маңызды және нені қажет ететіні егжей-тегжейлі сипатталған.
DevOps мәдениетін енгізуді бастағанда, оның келесі тәртіпте жүзеге асырылуы өте маңызды.
Бастапқыда адамдармен сөйлесу керек. Ал сіз адамдарға оның не екенін және одан қандай да бір пайда алуға болатынын түсіндіруіңіз керек.
Біздің конференция DotNet Fest деп аталады. Ұйымдастырушылардың айтуынша, біз мұнда негізінен әзірлеушілер аудиториясын шақырдық, сондықтан залдағы адамдардың көпшілігі әзірлеуге қатысады деп үміттенемін.
Біз адамдар туралы сөйлесеміз, әзірлеушілер күн сайын не істегісі келетіні туралы сөйлесеміз. Олар нені көбірек қалайды? Олар жаңа код жазғысы келеді, жаңа фреймворктерді қолданып, жаңа мүмкіндіктер жасағысы келеді. Әзірлеушілер ең аз нені қалайды? Ескі қателерді түзетіңіз. Менімен келісесіз деп үміттенемін. Әзірлеушілер осыны қалайды. Олар жаңа мүмкіндіктерді жазғысы келеді, қателерді түзеткісі келмейді.
Белгілі бір әзірлеуші шығаратын қателердің саны оның қолының қаншалықты түзу екеніне және олардың бөксе қалтасынан емес, иығынан қаншалықты өсетініне байланысты. Бірақ соған қарамастан, бізде үлкен жоба болған кезде, кейде бәрін бақылап отыру мүмкін болмай қалады, сондықтан бізге тұрақты және жоғары сапалы код жазуға көмектесетін кейбір тәсілдерді қолданғанымыз жақсы болар еді.
QA ең көп нені қалайды? Олардың залда бар-жоғын білмеймін. Мен QA алғым келеді деп айту қиын, өйткені мен ешқашан болған емеспін. Жігіттерге ренжімеңіз, мен ешқашан болмайды деп үміттенемін деп айтылады. Бірақ мен олардың жұмысын мағынасыз және пайдасыз деп санайтындықтан емес, өзімді бұл жұмысты тиімді атқара алатын адам деп есептемейтіндіктен, мен оны жасауға тырыспаймын да. Бірақ менің түсінігім бойынша, QA ең ұнатпайтын нәрсе таңертең жұмыс істейді, үнемі қандай да бір регрессия сынақтарын жүргізеді, олар әзірлеушілерге 3 спринт бұрын хабарлаған қателерді басып, былай дейді: «Сіз қашан келесіз. , Д Артаньян мырза, мына қатені түзетіңіз. Д'Артаньян мырза оған: «Иә, иә, иә, мен оны жөндеп қойдым», - деп жауап береді. Мен бір қатені түзетіп, жол бойы 5 жасадым.
Өндірісте бұл шешімді қолдайтын адамдар бұл шешімнің қатесіз жұмыс істеуін қалайды, осылайша олар әр жұмада, барлық қарапайым адамдар барға барғанда, серверді қайта жүктеудің қажеті жоқ. Әзірлеушілер жұмада орналастырылды, әкімшілер сенбіге дейін отырады, бұл орналастыруды орнатуға және түзетуге тырысады.
Адамдарға олардың бірдей мәселелерді шешуге бағытталғанын түсіндіргенде, сіз процестерді рәсімдеуге көшуге болады. Бұл өте маңызды. Неліктен? Өйткені біз «ресмилеу» деп айтқанда, сіз үшін ең болмағанда майлықтың бір жерінде сіздің процестеріңіз қалай болатынын сипаттау маңызды. Сіз, мысалы, QA ортасына немесе өндіріс ортасына орналастырсаңыз, ол әрқашан осы ретпен болатынын түсінуіңіз керек; бұл кезеңдерде біз, мысалы, автоматты блок сынақтары мен UI сынақтарын орындаймыз. Орналастырудан кейін біз орналастырудың жақсы немесе нашар болғанын тексереміз. Бірақ сізде өндіріске енгізген кезде қайта-қайта қайталанатын әрекеттердің нақты тізімі бар.
Процестеріңіз рәсімделген кезде ғана сіз осы процестерді автоматтандыруға көмектесетін өнімдерді таңдауды бастайсыз.
Өкінішке орай, мен мұның керісінше болатынын жиі көремін. Біреу «DevOps» сөзін естіген бойда олар бірден Дженкинсті орнатуды ұсынады, өйткені олар Дженкинсті орнатқаннан кейін оларда DevOps болады деп сенеді. Олар Дженкинсті орнатты, Дженкинс веб-сайтындағы «Қалай істеу керек» мақалаларын оқыды, осы «Қалай істеу керек» мақалаларына процестерді енгізуге тырысты, содан кейін адамдарға келіп, кітапта мұны осылай істеу керек екенін айтты, сондықтан біз мұны осылай жасаймыз.
Дженкинс жаман құрал емес. Мен мұны қандай да бір жолмен айтқым келмейді. Бірақ бұл өнімдердің бірі ғана. Қай өнімді пайдалану сіздің соңғы шешіміңіз болуы керек және сіздің бірінші шешіміңіз емес. Сіздің өніміңіз мәдениет пен тәсілдерді жүзеге асырумен қозғалмауы керек. Мұны түсіну өте маңызды, сондықтан мен бұл слайдқа көп уақыт жұмсаймын және мұның бәрін ұзақ түсіндіремін.
Жалпы DevOps тәжірибесі туралы сөйлесейік. Олар не? Қандай айырмашылық бар? Оларды қалай киіп көру керек? Неліктен олар маңызды?
Сіз естіген бірінші тәжірибе Үздіксіз интеграция деп аталады. Мүмкін жобадағы біреуде Үздіксіз интеграция (CI) бар.
Ең үлкен мәселе, мен жиі адамнан: «Сізде жобада CI бар ма?» деп сұрағанымда. және ол: «Иә» дейді, содан кейін мен оның не істейтінін сұрағанымда, ол маған автоматтандыру процесін толығымен сипаттайды. Бұл мүлдем дұрыс емес.
Шын мәнінде, CI тәжірибесі әртүрлі адамдар жазатын кодты бір кодтық базаға біріктіруге бағытталған. Осымен болды.
CI-мен қатар, әдетте, үздіксіз орналастыру, шығаруды басқару сияқты басқа тәжірибелер бар, бірақ біз бұл туралы кейінірек айтатын боламыз.
CI өзі бізге әртүрлі адамдар код жазатынын және бұл код үздіксіз бір кодтық базаға біріктірілуі керек екенін айтады.
Бұл бізге не береді және неліктен маңызды? Егер бізде DotNet болса, онда бұл жақсы, бұл құрастырылған тіл, біз өз қосымшамызды құрастыра аламыз. Егер ол құрастырылса, бұл қазірдің өзінде жақсы белгі. Бұл әлі ештеңені білдірмейді, бірақ бұл кем дегенде құрастыра алатын алғашқы жақсы белгі.
Содан кейін біз кейбір сынақтарды орындай аламыз, бұл да бөлек тәжірибе. Тесттердің барлығы жасыл – бұл екінші жақсы белгі. Бірақ тағы да, бұл ештеңені білдірмейді.
Бірақ неге мұны істейсің? Мен бүгін айтатын барлық тәжірибелер шамамен бірдей мәнге ие, яғни шамамен бірдей артықшылықтарға ие және шамамен бірдей өлшенеді.
Біріншіден, бұл жеткізуді жылдамдатуға мүмкіндік береді. Бұл жеткізуді тездетуге қалай мүмкіндік береді? Біз кодтық базамызға жаңа өзгерістер енгізген кезде, біз бірден осы кодпен бірдеңе жасауға тырысамыз. Біз бейсенбінің келуін күтпейміз, өйткені бейсенбіде біз оны QA Environment-қа шығарамыз, біз мұны дәл осы жерде және дәл осы жерде жасаймыз.
Мен сізге өз өмірімнен бір қайғылы оқиғаны айтып беремін. Бұл баяғыда, менің әлі жас, сымбатты кезім еді. Қазір мен жаспын, әдемі, ақылды және қарапайыммын. Біраз уақыт бұрын жобада болдым. Бізде шамамен 30 әзірлеушілерден тұратын үлкен команда болды. Бізде 10 жылға жуық әзірленген үлкен, үлкен Enterprise жобасы болды. Ал бізде әртүрлі филиалдар болды. Репозиторийде бізде әзірлеушілер жүретін филиал болды. Өндірістегі код нұсқасын көрсететін филиал болды.
Өндіріс саласы әзірлеушілерге қолжетімді филиалдан 3 айға артта қалды. Бұл нені білдіреді? Бұл дегеніміз, әзірлеушілердің кінәсінен өндіріске баратын бір жерде қате пайда болған кезде, олар бұған рұқсат бергендіктен және QA кінәсінен, олар қарағандықтан, бұл менде өндіруге арналған түзетуге арналған тапсырма, содан кейін 3 ай бұрын код өзгерістерін кері қайтаруым керек. Мен 3 ай бұрын болған нәрсені есіме түсіріп, оны сол жерде түзетуге тырысуым керек.
Егер сізде әлі мұндай тәжірибе болмаса, оны үй жобаңызда қолданып көруге болады. Ең бастысы, оны коммерциялық мақсатта қолданбаңыз. Кодтың бірнеше жолын жазыңыз, оларды алты ай бойы ұмытыңыз, содан кейін қайтып оралыңыз және бұл код жолдарының не туралы екенін және оларды қалай түзетуге немесе оңтайландыруға болатынын жылдам түсіндіруге тырысыңыз. Бұл өте қызықты тәжірибе.
Егер бізде Үздіксіз интеграция тәжірибесі болса, онда бұл кодты жазғаннан кейін оны дәл осы жерде және дәл қазір бірқатар автоматтандырылған құралдармен тексеруге мүмкіндік береді. Бұл маған толық суретті бермеуі мүмкін, бірақ соған қарамастан ол тәуекелдердің кейбірін жояды. Егер қандай да бір ықтимал қате болса, мен бұл туралы дәл қазір, яғни бір-екі минуттан кейін білемін. Маған 3 айға кері қайтару қажет емес. Маған тек 2 минут артқа оралу керек. Жақсы кофе машинасының кофені 2 минутта қайнатуға уақыты да болмайды, сондықтан бұл өте керемет.
Бұл әрбір жобада қайталанатын мәнге ие, яғни. сіз орнатқаныңыз ғана емес. Сіз тәжірибенің өзін де қайталай аласыз және жобаға енгізген әрбір жаңа өзгеріс үшін CI өзі қайталанады. Бұл ресурстарды оңтайландыруға мүмкіндік береді, себебі сіздің командаңыз тиімдірек жұмыс істейді. Енді 3 ай бұрын жұмыс істеген кодтан қате пайда болатын жағдай болмайды. Сіз отырғанда және бірдеңені түзетуді бастамас бұрын, сол кезде не болғанын түсінуге және контексттің мәнін түсінуге тырысып, алғашқы екі сағатты жұмсаған кезде контекстті ауыстыру мүмкіндігі болмайды.
Бұл тәжірибенің сәтті немесе сәтсіздігін қалай өлшеуге болады? Егер сіз үлкен бастыққа CI жобасында жүзеге асырғанымыз туралы есеп берсеңіз, ол бла бла бла естиді. Біз оны жүзеге асырдық, жарайды, бірақ неге, ол бізге не әкелді, оны қалай өлшейміз, қаншалықты дұрыс немесе дұрыс емес жүзеге асырып жатырмыз?
Біріншісі, CI арқасында біз жиірек және жиі орналастыра аламыз, өйткені біздің кодымыз тұрақтырақ. Сол сияқты, қатені табу уақыты қысқарады және бұл қатені түзету уақыты дәл осы жерде және дәл қазір жүйеден кодымызда не дұрыс емес деген жауап алатындықтан қысқарады.
Бізде бар тағы бір тәжірибе – автоматтандыруды тестілеу тәжірибесі, ол көбінесе CI тәжірибесімен бірге келеді. Олар қол ұстасып жүреді.
Бұл жерде нені түсіну маңызды? Біздің сынақтарымыз әртүрлі екенін түсіну маңызды. Ал әрбір автоматтандырылған тест өз мәселелерін шешуге бағытталған. Бізде, мысалы, модульді бөлек тексеруге мүмкіндік беретін бірлік сынақтары бар, яғни. Ол вакуумда қалай жұмыс істейді? Бұл жақсы.
Бізде әртүрлі модульдердің бір-бірімен қалай интеграцияланатынын түсінуге мүмкіндік беретін интеграциялық сынақтар да бар. Бұл да жақсы.
Бізде пайдаланушы интерфейсімен жұмыстың тұтынушы қойған белгілі талаптарға қаншалықты сәйкес келетінін тексеруге мүмкіндік беретін UI автоматтандыру сынақтары болуы мүмкін.
Сіз орындайтын арнайы сынақтар оларды қаншалықты жиі орындайтыныңызға әсер етуі мүмкін. Бірлік сынақтары әдетте қысқа және шағын түрде жазылады. Және оларды жүйелі түрде іске қосуға болады.
Егер біз UI автоматтандыру сынақтары туралы айтатын болсақ, сіздің жобаңыз кішкентай болса жақсы. UI автоматтандыру сынақтары жеткілікті уақытты алуы мүмкін. Бірақ әдетте UI автоматтандыру сынағы үлкен жобада бірнеше сағатты алатын нәрсе. Және бұл бірнеше сағат болса жақсы. Жалғыз нәрсе, оларды әрбір құрылыс үшін іске қосудың қажеті жоқ. Оларды түнде жүргізу мағынасы бар. Таңертең барлығы жұмысқа келгенде: тестерлер де, әзірлеушілер де, біз түнде UI автотестін өткізгеніміз және осы нәтижелерге қол жеткізгеніміз туралы қандай да бір есеп алды. Ал мұнда сіздің өніміңіздің кейбір талаптарға сай екенін тексеретін сервердің бір сағат жұмысы, тамақ пен алғыс үшін жұмыс істейтін кіші QA инженері болса да, сол QA инженерінің бір сағаттық жұмысынан әлдеқайда арзан болады. Бәрібір, машинаның бір сағат жұмысы арзанырақ болады. Сондықтан оған инвестиция салудың мәні бар.
Менде жұмыс істеп жатқан тағы бір жоба бар. Бұл жоба бойынша бізде екі апталық спринт болды. Жоба ауқымды болды, қаржы секторы үшін маңызды болды, қателік жіберуге болмайды. Ал екі апталық спринттен кейін даму циклі тестілеу процесімен жалғасты, оған тағы 4 апта қажет болды. Қайғылы оқиғаның ауқымын елестетіп көріңіз. Біз екі апта бойы код жазамыз, содан кейін оны CodeFreeze жасаймыз, оны қолданбаның жаңа нұсқасына жинаймыз және оны тестерлерге таратамыз. Тестілеушілер оны тағы 4 апта бойы тексереді, яғни. Олар оны сынап жатқанда, біз оларға тағы екі нұсқаны дайындап үлгердік. Бұл өте өкінішті жағдай.
Біз оларға, егер сіз өнімдірек болғыңыз келсе, сізге Автоматтандырылған тестілеу тәжірибесін енгізу мағынасы бар екенін айттық, өйткені дәл қазір дәл осы жерде сізді ренжітетін нәрсе.
Үздіксіз орналастыруды үйреніңіз. Керемет, сіз құрылысты аяқтадыңыз. Бұл қазірдің өзінде жақсы. Сіздің кодыңыз құрастырылды. Енді бұл құрылымды кейбір ортаға орналастыру жақсы болар еді. Әзірлеушілерге арналған ортада делік.
Неліктен маңызды? Біріншіден, сіз орналастыру процесінің өзімен қаншалықты сәтті екеніңізді көре аласыз. Мен осындай жобаларды кездестірдім: «Қолданбаның жаңа нұсқасын қалай қолданасыз?» Деген кезде, жігіттер маған: «Біз оны жинап, zip мұрағатына жинаймыз. Админге пошта арқылы жібереміз. Әкімші бұл мұрағатты жүктеп алып, кеңейтеді. Бүкіл кеңсе сервер жаңа нұсқаны алуы үшін дұға ете бастайды ».
Қарапайым нәрседен бастайық. Мысалы, олар CSS-ті мұрағатқа қоюды ұмытты немесе java-скрипт файлының атауындағы хэштегті өзгертуді ұмытты. Ал біз серверге сұраныс жасағанда, браузерде осы java-скрипт файлы бар деп ойлайды және оны жүктеп алмауды шешеді. Ал ескі нұсқасы болды, бірдеңе жетіспейді. Жалпы, көптеген мәселелер болуы мүмкін. Сондықтан, Үздіксіз орналастыру тәжірибесі, кем дегенде, егер сіз таза анықтамалық кескінді алып, оны толығымен таза жаңа ортаға жүктеп салсаңыз, не болатынын тексеруге мүмкіндік береді. Мұның қайда апаратынын көруге болады.
Сондай-ақ, кодты бір-біріңізбен біріктірген кезде, яғни. пәрмен арасында, бұл сонымен қатар оның UI-де қалай көрінетінін көруге мүмкіндік береді.
Ванильді java-скрипті көп пайдаланылған кезде туындайтын мәселелердің бірі екі әзірлеушінің терезе нысанында бірдей атпен айнымалы мәнді асығыс жариялауы болып табылады. Содан кейін, сіздің сәттілікке байланысты. Кімнің java-скрипт файлы екінші шығарылса, екіншісінің өзгертулерін қайта жазады. Бұл да өте қызықты. Сіз кіресіз: бір нәрсе біреу үшін жұмыс істейді, екіншісі басқа үшін жұмыс істемейді. Мұның бәрі өндірісте пайда болған кезде «керемет».
Бізде келесі тәжірибе - Автоматты қалпына келтіру тәжірибесі, атап айтқанда қолданбаның алдыңғы нұсқасына оралу.
Неліктен бұл әзірлеушілер үшін маңызды? Сонау, сонау 90-шы жылдарды, компьютерлер үлкен, ал бағдарламалар шағын болған кезді әлі де еске алатындар бар. Ал веб-әзірлеудің жалғыз жолы PHP арқылы болды. Бұл PHP нашар тіл емес, бірақ солай болса да.
Бірақ мәселе басқаша болды. Біз PHP сайтымыздың жаңа нұсқасын орналастырған кезде, оны қалай орналастырдық? Көбінесе біз Far Manager немесе басқа нәрсені аштық. Және бұл файлдарды FTP-ге жүктеп салды. Біз кенеттен бізде кішкентай, кішкентай қате бар екенін түсіндік, мысалы, нүктелі үтірді қоюды ұмытып кеттік немесе деректер қорының құпия сөзін өзгертуді ұмытып кеттік, ал жергілікті хостта орналасқан деректер қорының құпия сөзі бар. Біз FTP-ге жылдам қосылуды және файлдарды дәл сол жерде өңдеуді шешеміз. Бұл жай ғана от! Бұл 90-жылдары танымал болды.
Бірақ, егер сіз күнтізбені қарамасаңыз, 90-шы жылдар шамамен 30 жыл бұрын болды. Қазір бәрі сәл басқаша болып жатыр. Олар сізге: «Біз өндіріске қостық, бірақ ол жерде бірдеңе дұрыс болмады. Міне, сіздің FTP логиніңіз бен құпия сөзіңіз, өндіріске қосылыңыз және оны сол жерде тез түзетіңіз. Егер сіз Чак Норрис болсаңыз, бұл жұмыс істейді. Әйтпесе, сіз бір қатені түзетсеңіз, тағы 10 қате жасайсыз деп қауіптенесіз. Дәл осы себепті алдыңғы нұсқаға қайта оралу тәжірибесі көп нәрсеге қол жеткізуге мүмкіндік береді.
Тіпті бір жерде қандай да бір жаман нәрсе пайда болса да, бұл жаман, бірақ өлімге әкелмейді. Бұрынғы нұсқаға оралуға болады. Бұл терминологияда оны қабылдау оңай болса, оны сақтық көшірме деп атаңыз. Осы алдыңғы нұсқаға оралуға болады және пайдаланушылар әлі де өніміңізбен жұмыс істей алады және сізде жеткілікті буфер уақыты болады. Сіз сабырмен, асықпай, мұның бәрін қабылдап, жергілікті жерде сынап, түзетіп, жаңа нұсқасын жүктей аласыз. Мұны істеу шынымен мағынасы бар.
Енді бұрынғы екі тәжірибені қандай да бір жолмен біріктіруге тырысайық. Біз Release Management деп аталатын үшіншісін аламыз.
Үздіксіз орналастыру туралы оның классикалық түрінде айтқан кезде, біз репозиторийден қандай да бір тармақтан кодты алып, оны құрастырып, орналастыруымыз керек деп айтамыз. Ортамыз бірдей болса жақсы. Егер бізде бірнеше орта болса, бұл кодты әр уақытта, тіпті бір міндеттемеден де алуымыз керек дегенді білдіреді. Біз оны әр уақытта шығарамыз, біз оны әр уақытта жасаймыз және оны жаңа ортаға орналастырамыз. Біріншіден, бұл уақыт, өйткені егер сізде үлкен жоба болса және 90-шы жылдардан бері келсе, онда бірнеше сағат қажет болуы мүмкін.
Оның үстіне тағы бір мұң бар. Сіз құрастырған кезде, тіпті бір машинада болса да, сіз бірдей көздерді жасайсыз, бірақ бұл машинаның соңғы құрастыру кезіндегідей күйде екеніне әлі де кепілдік жоқ.
Біреу кіріп, сіз үшін DotNet-ті жаңартты делік немесе керісінше, біреу бір нәрсені жоюды шешті. Содан кейін сізде когнитивті диссонанс бар, бұл міндеттемеден екі апта бұрын біз құрылыс салып жатырмыз және бәрі жақсы болды, бірақ қазір біз құрастыруға тырысатын сол машина, сол міндеттеме, сол код сияқты көрінеді, бірақ ол жұмыс істемейді. . Сіз бұл мәселемен ұзақ уақыт айналысасыз және сіз оны анықтайтын факт емес. Ең болмаса жүйкеңізді көп бұзасыз.
Сондықтан шығарылымдарды басқару тәжірибесі артефакт репозиторийі немесе галерея немесе кітапхана деп аталатын қосымша абстракцияны енгізуді ұсынады. Сіз оны қалағаныңызша атай аласыз.
Негізгі идея - бізде қандай да бір міндеттеме болған кезде, айталық, біз әртүрлі орталарға орналастыруға дайын филиалда, біз осы міндеттемеден қосымшаларды және осы қолданбаға қажет нәрсенің бәрін жинаймыз, біз оны жинаймыз. zip мұрағатына салып, оны кейбір сенімді жадта сақтаңыз. Бұл қоймадан біз бұл zip мұрағатын кез келген уақытта ала аламыз.
Содан кейін біз оны алып, оны автоматты түрде әзірлеуші ортасына орналастырамыз. Біз сонда жарысамыз, егер бәрі жақсы болса, біз сахнаға шығамыз. Егер бәрі жақсы болса, біз өндіріске бірдей мұрағатты, дәл бір рет құрастырылған бірдей екілік файлдарды орналастырамыз.
Бұған қоса, бізде осындай галерея болған кезде, ол алдыңғы нұсқаға кері қайтару туралы сөйлескен кезде соңғы слайдта қарастырған тәуекелдерді шешуге көмектеседі. Кездейсоқ бірдеңені дұрыс қолданбасаңыз, әрқашан осы галереядан кез келген басқа алдыңғы нұсқаны алып, оны осы орталарға бірдей етіп шығаруға болады. Бұл бірдеңе дұрыс болмаса, алдыңғы нұсқаға оңай оралуға мүмкіндік береді.
Тағы бір керемет тәжірибе бар. Сіз және біз бәріміз түсінеміз, біз қолданбаларды алдыңғы нұсқаға қайтарған кезде, бұл бізге алдыңғы нұсқаның инфрақұрылымы да қажет екенін білдіруі мүмкін.
Виртуалды инфрақұрылым туралы айтатын болсақ, көптеген адамдар бұл әкімшілер орнатқан нәрсе деп ойлайды. Егер сізге, айталық, қолданбаның жаңа нұсқасын сынағыңыз келетін жаңа серверді алу қажет болса, әкімшілерге немесе devops-қа билет жазуыңыз керек. Бұл үшін Devops 3 апта алады. Ал 3 аптадан кейін олар сізге бір ядросы, екі гигабайт жедел жады және DotNet жоқ Windows сервері бар виртуалды машинаны орнатқанымызды айтады. Сіз: «Бірақ мен DotNet-ті қалаймын» дейсіз. Олар: «Жарайды, 3 аптадан кейін оралыңыз».
Идея мынада: Инфрақұрылымды код тәжірибесі ретінде пайдалану арқылы виртуалды инфрақұрылымды басқа ресурс ретінде қарастыруға болады.
Мүмкін, егер сіздердің кез келгеніңіз DotNet-те қолданбаларды жасап жатсаңыз, Entity Framework деп аталатын кітапхана туралы естіген боларсыз. Сіз Entity Framework Microsoft белсенді түрде итермелейтін тәсілдердің бірі екенін естіген боларсыз. Дерекқормен жұмыс істеу үшін бұл Code First деп аталатын тәсіл. Бұл дерекқордың қалай көрінетінін кодта сипаттайтын кезде. Содан кейін қолданбаны орналастырасыз. Ол мәліметтер қорына қосылады, ол қандай кестелер бар және қандай кестелер жоқ екенін өзі анықтайды және сізге қажет нәрсенің бәрін жасайды.
Сіз өзіңіздің инфрақұрылымыңызбен де солай істей аласыз. Жоба үшін дерекқор қажет пе немесе жоба үшін Windows сервері қажет пе арасында ешқандай айырмашылық жоқ. Бұл жай ғана ресурс. Және бұл ресурсты құруды автоматтандыруға болады, бұл ресурстың конфигурациясын автоматтандыруға болады. Тиісінше, сіз қандай да бір жаңа тұжырымдаманы, қандай да бір жаңа тәсілді сынағыңыз келген сайын, devops-қа билет жазудың қажеті жоқ, сіз жай ғана дайын үлгілерден, дайын сценарийлерден оқшауланған инфрақұрылымды орналастырып, оны жүзеге асыра аласыз. сонда сіздің барлық эксперименттеріңіз. Мұны жоюға, кейбір нәтижелерді алуға және бұл туралы қосымша хабарлауға болады.
Бар және маңызды, бірақ аз адамдар қолданатын келесі тәжірибе қолданба өнімділігін бақылау болып табылады.
Қолданба өнімділігін бақылау туралы бір ғана нәрсе айтқым келді. Бұл тәжірибеде ең маңыздысы не? Бұл қолданба өнімділігін бақылау пәтерді жөндеумен бірдей. Бұл соңғы күй емес, бұл процесс. Сіз мұны үнемі жасауыңыз керек.
Жақсы мағынада, әрбір дерлік құрастыруда Қолданба өнімділігін бақылауды жүзеге асырған дұрыс болар еді, дегенмен, сіз түсінгендей, бұл әрқашан мүмкін емес. Бірақ, кем дегенде, оны әрбір шығарылым үшін орындау керек.
Неліктен маңызды? Өйткені, егер сіз кенеттен өнімділіктің төмендеуін байқасаңыз, оның себебін нақты түсінуіңіз керек. Егер сіздің командаңыз, айталық, екі апталық спринттерге ие болса, онда кем дегенде екі аптада бір рет қолданбаңызды нақты бекітілген процессор, жедел жады, дискілер және т.б. бар бөлек серверге орналастыруыңыз керек. Және сол өнімділік сынақтарын орындаңыз. . Сіз нәтиже аласыз. Оның алдыңғы спринттен қалай өзгергенін қараңыз.
Егер сіз төмендеу бір жерде күрт төмендегенін білсеңіз, бұл соңғы екі аптада болған өзгерістерге байланысты болғанын білдіреді. Бұл мәселені тезірек анықтауға және шешуге мүмкіндік береді. Тағы да, бұл сіздің қаншалықты сәтті орындағаныңызды өлшеуге болатын шамамен бірдей көрсеткіштер.
Бізде келесі тәжірибе конфигурацияны басқару тәжірибесі болып табылады. Мұны байыппен қабылдайтындар өте аз. Бірақ маған сеніңіз, бұл шын мәнінде өте маңызды нәрсе.
Жақында бір қызық оқиға болды. Жігіттер маған келіп: «Біздің өтінішімізге қауіпсіздік аудитін жүргізуге көмектесіңіз», - деді. Біз кодты ұзақ уақыт бойы бірге қарадық, олар маған қосымша туралы айтты, диаграммалар сызды. Және плюс немесе минус бәрі логикалық, түсінікті, қауіпсіз болды, бірақ бір БІРАҚ болды! Олардың бастапқы басқаруында конфигурация файлдары болды, соның ішінде IP дерекқорымен өндірістен, осы дерекқорларға қосылуға арналған логиндер мен парольдер және т.б.
Мен айтамын: «Жігіттер, жарайды, сіз өзіңіздің өндірістік ортаңызды брандмауэрмен жаптыңыз, бірақ сізде өндірістік дерекқорға арналған логин мен құпия сөздің бастапқы басқару элементінде болуы және кез келген әзірлеуші оны оқи алатыны - бұл үлкен қауіпсіздік қаупі. . Қолданбаңыз код тұрғысынан қаншалықты қауіпсіз болса да, егер сіз оны бастапқы бақылауда қалдырсаңыз, сіз ешқашан ешбір жерде аудиттен өтпейсіз. Менің айтып отырғаным осы.
Конфигурацияны басқару. Бізде әртүрлі орталарда әртүрлі конфигурациялар болуы мүмкін. Мысалы, бізде QA, демонстрация, өндіріс ортасы және т.б. үшін дерекқорларға арналған әртүрлі логиндер мен құпия сөздер болуы мүмкін.
Бұл конфигурацияны автоматтандыруға да болады. Ол әрқашан қолданбаның өзінен бөлек болуы керек. Неліктен? Қолданбаны бір рет құрастырғандықтан, содан кейін қолданба SQL серверіне анау-мынау IP немесе осындай IP арқылы қосылғаныңызға мән бермейді, ол бірдей жұмыс істеуі керек. Сондықтан, егер кенеттен біреуіңіз әлі де кодтағы қосылым жолын қатты кодтаса, мен сізді бір жобада тапсаңыз, мен сізді табатынымды және жазалайтынымды есте сақтаңыз. Бұл әрқашан бөлек конфигурацияда, мысалы, web.config ішінде орналастырылады.
Және бұл конфигурация қазірдің өзінде бөлек басқарылады, яғни әзірлеуші мен әкімші бір бөлмеге келіп отыра алатын дәл осы сәт. Ал әзірлеуші былай деп айта алады: «Міне, менің қосымшамның екілік файлдары. Олар жұмыс істейді. Қолданба жұмыс істеу үшін дерекқор қажет. Мұнда екілік файлдардың жанында файл бар. Бұл файлда бұл өріс логин үшін жауапты, бұл пароль үшін, бұл IP үшін. Оны кез келген жерде орналастырыңыз ». Бұл әкімшіге қарапайым және түсінікті. Ол осы конфигурацияны басқару арқылы оны шынымен кез келген жерде орналастыра алады.
Ал мен айтқым келетін соңғы тәжірибе бұлттарға өте, өте жақын тәжірибе. Бұлтта жұмыс жасасаңыз, ол максималды нәтиже береді. Бұл сіздің ортаңызды автоматты түрде жою.
Мен бұл конференцияда мен жұмыс істейтін командалардан бірнеше адам бар екенін білемін. Мен жұмыс істейтін барлық командалармен біз бұл тәжірибені қолданамыз.
Неліктен? Әрине, әрбір әзірлеушіде тәулік бойы жұмыс істейтін виртуалды машина болса, жақсы болар еді. Бірақ бұл сіз үшін жаңалық болуы мүмкін, сіз назар аудармаған шығарсыз, бірақ әзірлеушінің өзі тәулік бойы жұмыс істемейді. Әзірлеуші әдетте күніне 24 сағат жұмыс істейді. Жұмысқа ерте келсе де, үлкен түскі ас ішіп, жаттығу залына барады. Әзірлеуші осы ресурстарды нақты пайдаланған кезде күніне 7 сағат болсын. Біздің заңнамаға сәйкес, бізде аптаның 24 күнінің 7-і жұмыс күні болып саналады.
Тиісінше, жұмыс күндері бұл машина 24 сағат емес, тек 12 сағат жұмыс істеуі керек, ал демалыс күндері бұл машина мүлдем жұмыс істемеуі керек. Барлығы өте қарапайым болып көрінеді, бірақ бұл жерде не айту керек? Осы қарапайым тәжірибені осы негізгі кестеде енгізу арқылы ол осы орталарды ұстау құнын 70%-ға төмендетуге мүмкіндік береді, яғни сіз әзірлеуші бағасын, QA, демонстрацияны, ортаны алып, оны 3-ке бөлдіңіз.
Мәселе мынада: қалған ақшаны не істеу керек? Мысалы, әзірлеушілер ReSharper сатып алмаған болса керек. Немесе коктейльді тойлаңыз. Бұрын сізде әзірлеуші де, QA да жайылған бір орта болса, енді сіз оқшауланатын 3 түрлі ортаны жасай аласыз және адамдар бір-біріне кедергі жасамайды.
Үздіксіз өнімділікті өлшейтін слайдқа келетін болсақ, егер жобадағы дерекқорда 1 жазба болса, екі айдан кейін миллион болса, өнімділікті қалай салыстыруға болады? Неліктен және өнімділікті өлшеудің мәні неде екенін қалай түсінуге болады?
Бұл жақсы сұрақ, себебі сіз әрқашан бірдей ресурстардағы өнімділікті өлшеуіңіз керек. Яғни, сіз жаңа кодты шығарасыз, өнімділікті жаңа кодта өлшейсіз. Мысалы, әртүрлі өнімділік сценарийлерін тексеру керек, 1 пайдаланушы бар және дерекқор өлшемі 000 гигабайт болатын жеңіл жүктемеде қолданбаның қалай жұмыс істейтінін тексергіңіз келеді делік. Сіз оны өлшеп, сандарды алдыңыз. Әрі қарай біз басқа сценарийді аламыз. Мысалы, 5 пайдаланушы, деректер қорының көлемі 5 терабайт. Нәтижесін алып, есте сақтадық.
Мұнда не маңызды? Мұнда маңызды нәрсе сценарийге, деректер көлеміне, бір уақытта пайдаланушылар санына және т.б. байланысты белгілі бір шектеулерге тап болуыңыз мүмкін. Мысалы, желілік картаның шегіне немесе қатты дискінің шегіне немесе процессор мүмкіндіктерінің шегіне дейін. Бұл сізге түсіну үшін маңызды. Әртүрлі сценарийлерде сіз белгілі бір шектеулерге тап боласыз. Және сандарды соққанда түсіну керек.
Біз арнайы сынақ ортасында өнімділікті өлшеу туралы айтып отырмыз ба? Яғни, бұл өндіріс емес пе?
Иә, бұл өндіріс емес, бұл алдыңғы өлшемдермен салыстыру үшін әрқашан бірдей болатын сынақ ортасы.
Түсіндім рахмет!
Сұрақтар болмаса, аяқтаймыз деп ойлаймын. Рақмет сізге!
Ақпарат көзі: www.habr.com