У дакладзе будзе расказана аб некаторых DevOps практыках, але з пункту гледжання распрацоўшчыка. Звычайна ўсе інжынеры, якія прыходзяць у DevOps, ужо маюць за плячыма некалькі гадоў досведу адміністравання. Але гэта не азначае, што распрацоўніку тут няма месца. Часцей за ўсё распрацоўшчыкі занятыя тым, што выпраўляюць "чарговы тэрмінова-крытычны баг дня", і ў іх няма часу нават адным вочкам зірнуць на DevOps сферу. У разуменні аўтара DevOps – гэта, па-першае, разумны сэнс. Па-другое - гэта магчымасць быць больш эфектыўным. Калі вы распрацоўшчык, валодаеце разумным сэнсам і хочаце быць больш эфектыўным як камандны гулец - даклад для вас.
Уявлюся, я суцэль дапушчаю, што ў зале ёсць людзі, якія мяне не ведаюць. Зваць мяне Антон Бойка, я з'яўляюся Microsoft Azure MVP. Што такое MVP? Гэта Model-View-Presenter. Model-View-Presenter гэта менавіта я.
Акрамя таго, я зараз займаю пасаду solution architect у кампаніі Ciklum. І літаральна нядаўна купіў сабе вось такі прыгожы дамен, і ў мяне абнавіўся мой email, які я звычайна паказваю на прэзентацыях. Можаце пісаць мне на: me [сабака] byokoant.pro. Мне на пошту можна пісаць пытанні. Я звычайна на іх адказваю. Адзінае, я не хацеў бы атрымліваць пытанні на пошту, якія адносяцца да дзвюх тэмаў: гэта палітыка і рэлігія. Пра ўсё астатняе можаце пісаць мне на пошту. Пройдзе нейкі час, я адкажу.
Пару слоў пра сябе:
- Ужо 10 год я ў гэтай сферы.
- Я працаваў у Microsoft.
- Я бацька-заснавальнік украінскай Azure-супольнасці, якую мы заснавалі недзе ў 2014-ым годзе. І да гэтага часу яно ў нас ёсць і развіваецца.
- Я таксама бацька заснавальнік Azure-канферэнцыі, якая ў нас праходзіць ва Ўкраіне.
- Таксама я дапамагаю арганізаваць Global Azure Bootcamp у Кіеве.
- Як я ўжо сказаў, я - Microsoft Azure MVP.
- Я часта выступаю на канферэнцыях. Я вельмі люблю выступаць на канферэнцыях. За мінулы год у мяне атрымалася выступіць каля 40 разоў. Калі будзеце прабягаць міма Украіны, Беларусі, Польшчы, Балгарыі, Швецыі, Даніі, Нідэрландаў, Іспаніі ці плюс-мінус іншай краіны ў Еўропе, то цалкам магчыма, што, заходзячы на канферэнцыю, якая мае тэму аблокаў у сябе ў патоку, вы можаце ўбачыць мяне ў спісе дакладчыкаў.
- А яшчэ я фанат Star Trek.
Давайце крыху пагаворым пра Agenda. Agenda у нас вельмі простая:
- Мы пагаворым, што такое DevOps. Пагаворым, чаму гэта так важна. Раней DevOps - гэта было ключавое слова, якое вы пісалі ў рэзюмэ і атрымлівалі адразу +500 даляраў да зарплаты. Цяпер трэба пісаць, напрыклад, blockchain у рэзюмэ, каб атрымаць +500 даляраў да заробку.
- А потым, калі мы трошкі разбяромся, што з сябе гэта ўяўляе, мы пагаворым аб тым, якія ёсць DevOps-практыкі. Але не гэтулькі ў кантэксце DevOps у цэлым, а пра тыя DevOps-практыкі, якія маглі б быць цікавыя распрацоўнікам. Я раскажу, чаму яны маглі б быць вам цікавыя. Раскажу, навошта наогул гэта рабіць і як гэта можа вам дапамагчы адчуваць менш болі.
Традыцыйная карцінка, якія паказваюць многія. Гэта тое, што адбываецца ў шматлікіх праектах. Гэта калі ў нас ёсць аддзелы распрацоўкі і operations, якія падтрымліваюць наш софт. І гэтыя аддзелы паміж сабой не маюць зносіны.
Магчыма, калі вы не настолькі ярка змаглі прачуць менавіта на аддзелах DevOps і operations, вы можаце правесці аналогію з аддзеламі Dev і QA. Ёсць людзі, якія распрацоўваюць софт і ёсць QA, якія дрэнныя з пункту гледжання распрацоўшчыкаў. Напрыклад, я камічу ў рэпазітар свой выдатны код, а там сядзіць нейкі нягоднік, які мне гэты код вяртае і кажа, што ваш код дрэнны.
Гэта ўсё адбываецца па тым чынніку, што людзі паміж сабой не маюць зносіны. І яны праз нейкую сцяну непаразумення перакідаюць адзін аднаму нейкія пакеты, нейкі дадатак і спрабуюць нешта з імі з рабіць.
Якраз разбурыць гэтую сцяну і заклікана DevOps-культура, г.зн. прымусіць людзей паміж сабой мець зносіны і хаця б разумець, чым наогул займаюцца розныя людзі ў праекце і чаму іх праца важная.
І калі мы гаворым пра DevOps, то нехта вам скажа, што DevOps – гэта калі ў праекце ёсць continuous integration; хтосьці скажа, што DevOps - гэта калі ў праекце рэалізавана практыка "інфраструктура як код"; хтосьці скажа, што першы крок да DevOps - гэта feature branching, feature flags.
Па сутнасці, гэта ўсё па-свойму праўда. Але гэта ўсяго толькі канчатковыя практыкі, якія ў нас ёсць. Перад тым, як пераходзіць да гэтых практыкаў, я прапаную паглядзець на гэты слайд, які паказвае 3 этапы ўкаранення Dev-Ops метадалогіі ў вашым праекце, у вашай кампаніі.
Гэты слайд носіць яшчэ другую неафіцыйную назву. Вы можаце пашукаць у інтэрнэце, што такое 3 мушкецёры DevOps. Цалкам магчыма, вы знойдзеце гэты артыкул. Чаму 3 мушкецёры? Унізе напісана: людзі, працэсы і прадукты, г.зн. PPP - Портас, Портас і Портос. Вось вам 3 мушкецёры DevOps. У гэтым артыкуле апісваецца больш разгорнута, чаму гэта важна і што гэта пад сабой нясе.
Калі вы пачынаеце ўкараняць DevOps-культуру, вельмі важна, каб яна ўкаранялася ў наступным парадку.
Першапачаткова вам трэба размаўляць з людзьмі. І вам трэба растлумачыць людзям, што гэта такое і як яны змогуць атрымаць ад гэтага нейкія перавагі.
Канферэнцыя ў нас называецца DotNet Fest. І як мне сказалі арганізатары, што сюды ў нас у асноўным была запрошана аўдыторыя распрацоўшчыкаў, таму я спадзяюся, што большасць людзей у зале займаюцца распрацоўкай.
Мы пагаворым пра людзей, пагаворым аб тым, што распрацоўшчыкі хочуць рабіць кожны дзень. Чаго яны жадаюць больш за ўсё? Яны хочуць пісаць нейкі новы код, выкарыстоўваць навамодныя фрэймворкі, пілаваць новыя фічы. Чаго распрацоўшчыкі хочуць менш за ўсё? Фіксіць старыя багі. Я спадзяюся, вы са мной пагадзіцеся. Гэта тое, што хочуць распрацоўшчыкі. Яны жадаюць пісаць новыя фічы, яны не жадаюць фіксаваць багі.
Колькасць багаў, якія вырабляе той ці іншы распрацоўшчык, залежыць ад таго, наколькі ў яго прамыя рукі і наколькі яны растуць з плячэй, а не з кішэняў на попе. Але тым не менш, калі праект у нас вялікі, часам бывае так, што за ўсім усачыць немагчыма, таму нам было б нядрэнна выкарыстоўваць нейкія падыходы, якія дапамогуць пісаць больш стабільны і больш якасны код.
Што больш за ўсё жадаецца QA? Ня ведаю, ці ёсьць яны ў залі. Мне цяжка казаць, што жадаецца QA, таму што я ніколі ім не быў. І не ў крыўду хлопцам будзе сказана, што ніколі, спадзяюся, не буду. Але не з той прычыны, што лічу іх працу бессэнсоўнай і бескарыснай, а таму што я не лічу сябе чалавекам, які змог бы гэтую працу выконваць якасна, таму я нават не буду спрабаваць гэта рабіць. Але з таго, што я разумею, QA больш за ўсё не падабаецца выходзіць раніцай на працу, ганяць увесь час нейкія regression tests, наступаць на тыя ж самыя багі, якія яны зарэпартавалі распрацоўнікам 3 спрынту назад і казаць: «Калі ж вы, месье Д 'Артаньян, пафіксіце гэты баг». А месье Д'Артаньян яму адказвае: «Так-так-так, я ўжо яго пафіксіў». І як гэта бывае, што адзін баг пафіксіў, 5 па дарозе зрабіў.
Людзі, якія займаюцца падтрымкай гэтага рашэння на production, хочуць, каб гэтае рашэнне працавала без багаў, каб ім не даводзілася пераўздымаць сервер кожную пятніцу, калі ўсе нармальныя людзі ідуць у бар. Распрацоўнікі ў пятніцу задэплоіліся, адміны сядзяць да суботы, спрабуючы гэты дэплой падняць, паправіць.
І калі вы растлумачыце людзям, што яны нацэлены на вырашэнне адных і тых жа задач, вы можаце пераходзіць да фармалізацыі працэсаў. Гэта вельмі важна. Чаму? Таму што, калі мы кажам «фармалізацыя», то вам важна апісаць, як вашыя працэсы адбываюцца хаця б дзесьці на сурвэтцы. Вам трэба зразумець, што калі вы, напрыклад, робіце дэплой на QA-асяроддзе ці на production-асяроддзе, тое гэта заўсёды адбываецца вось у такім парадку, вось на такіх этапах мы запускаем, дапусцім, аўтаматычныя unit-тэсты, UI-тэсты. Пасля дэплою правяраем, наколькі дэплой прайшоў добра ці дрэнна. Але ў вас ужо ёсць выразны спіс дзеянняў, якія павінны паўтарацца штораз, калі вы робіце дэплой на production.
І толькі калі ў вас працэсы фармалізаваны, вы прыступаеце да выбару прадуктаў, якія дапамогуць вам вось гэтыя працэсы аўтаматызаваць.
Нажаль, я вельмі часта бачу, што гэта адбываецца ў зваротным парадку. Як толькі хтосьці чуе слова "DevOps", адразу прапануе паставіць Jenkins, таму што лічыць, што як толькі яны паставяць Jenkins, у іх будзе DevOps. Яны паставілі Jenkins, пачыталі артыкулы «How to» на сайце Jenkins, паспрабавалі працэсы запхнуць у гэтыя How to артыкулы, а потым прыйшлі да людзей і нагнулі людзей, сказаўшы, што кніжка кажа, што трэба рабіць вось так, таму робім вось так.
Не тое, што б Jenkins дрэнны інструмент. Я ні ў якім разе не хачу гэта сказаць. Але гэта толькі адзін з прадуктаў. І тое, які прадукт вы будзеце выкарыстоўваць, павінна быць ваша апошняе рашэнне, а ні ў якім разе не першае. У вас прадукт не павінен драйвіць выкарыстанне менавіта культуры і падыходаў. Гэта вельмі важна зразумець, менавіта таму я так доўга кручуся на гэтым слайдзе і так доўга ўсё гэта тлумачу.
Давайце пагаворым пра DevOps-практыкі ў цэлым. Якія яны ёсць? Чым яны адрозніваюцца? Як іх памераць? Чаму яны важныя?
Першая практыка, пра якую вы маглі чуць, называецца Continuous Integration. Магчыма, у кагосьці на праекце ёсць Continuous Integration (CI).
Самая вялікая праблема ў тым, што часцей за ўсё, калі я пытаю ў чалавека: "Ці ёсць у вас CI на праекце?" і ён кажа: "Так", то, калі я пытаю, што ён робіць, ён мне апісвае абсалютна ўвесь працэс аўтаматызацыі. Гэта не зусім так.
Насамрэч практыка CI усяго толькі накіравана на тое, што код, які пішуць розныя людзі, інтэгруецца ў нейкую адзіную базу кода. Вось і ўсё.
Разам з CI па дарозе ідуць звычайна яшчэ розныя практыкі – такія, як Continuous Deployment, Release Management, але пра гэта мы пагаворым потым.
Сам CI нам гаворыць, што розныя людзі пішуць код і гэты код павінен інтэгравацца бесперапынна ў адзіную базу кода.
Што нам гэта дае і чаму гэта важна? Калі ў нас DotNet, то гэта добра, гэта кампіляваная мова, мы можам скампіляваць наша дадатак. Калі яно кампілюецца, то гэта ўжо добры знак. Гэта яшчэ нічога не азначае, але гэта ўжо першы добры знак, што мы хаця б можам скампілявацца.
Пасля мы можам запусціць нейкія тэсты, што таксама з'яўляецца асобнай практыкай. Тэсты ўсе зялёныя - гэта ўжо другі добры знак. Але зноў гэта яшчэ нічога не азначае.
Але навошта вам гэта рабіць? Усе практыкі, пра якія я буду расказваць сёння, пад сабой нясуць прыкладна аднолькавы value, г. зн. прыкладна аднолькавыя перавагі і мераюцца таксама прыкладна аднолькава.
Першае - гэта дазваляе вам паскорыць дастаўку. За рахунак чаго гэта дазваляе вам паскорыць дастаўку? Калі ў нас заходзяць нейкія новыя змены ў нашу кодавую базу, мы можам адразу ж паспрабаваць з гэтым кодам нешта зрабіць. Мы не чакаем, пакуль у нас прыйдзе чацвер, таму што ў чацвер мы рэлізім гэта на QA Environment, мы робім гэта прама тут і прама тут.
Я раскажу вам адну сумную гісторыю з майго жыцця. Гэта было даўным-даўно, калі я яшчэ быў малады і прыгожы. Цяпер я ўжо малады, прыгожы і разумны, і сціплы. Нейкі час таму я быў у адным праекце. У нас была вялікая каманда з каля 30 распрацоўшчыкаў. І ў нас быў вялікі-вялікі Энтэрпрайз-праект, які развіваўся каля 10 гадоў. І ў нас былі розныя галінкі. У рэпазітары ў нас была галінка, у якой гулялі распрацоўшчыкі. І была галінка, якая адлюстроўвала версію кода, які ёсць на production.
Ветка production ад галіны, якая была даступная для распрацоўшчыкаў, адставала на 3 месяцы. Што гэта азначае? Гэта азначае, што як толькі ў мяне недзе нейкі баг пайшоў на production па віне распрацоўшчыкаў, таму што яны яго дапусцілі, і па віне QA, таму што яны яго прагледзелі, то гэта азначае, што калі мне прылятае задача на hotfix для production'а, то я павінен адкаціць свае кодавыя змены на 3 месяцы таму. Я мушу ўзгадаць, што ў мяне было 3 месяцы таму і паспрабаваць гэта там пафіксіць.
Калі ў вас не было яшчэ такога досведу, то можаце паспрабаваць гэта зрабіць на вашым хатнім праекце. Галоўнае, не спрабуйце на камерцыйным. Напішыце пару радкоў кода, забудзьцеся пра іх на паўгода, а потым вярніцеся і паспрабуйце хутка растлумачыць, пра што гэтыя радкі кода і як можна іх выправіць ці аптымізаваць. Гэта вельмі-вельмі займальны досвед.
Калі ў нас ёсць практыка Бесперапыннай інтэграцыі, то гэта дазваляе нам прама тут і прама зараз, як толькі я напісаў свой код, праверыць яго побач аўтаматычных інструментаў. Няхай гэта не дасць мне поўную карціну, але тым не менш, гэта прыбярэ хоць бы частку рызык. І калі там будзе нейкая патэнцыйная бага, я пра гэта даведаюся прама зараз, т. е. літаральна праз пару хвілін. Мне не трэба будзе адкочвацца на 3 месяцы таму. Мне трэба будзе адкаціцца ўсяго на 2 хвіліны таму. За 2 хвіліны добрая кофемашына нават кава не паспее зварыць, таму гэта даволі класна.
Гэта нясе ў сабе каштоўнасць, што гэта можна паўтараць раз у раз на кожным праекце, г.зн. не толькі на адным, на якім вы гэта настроілі. Можна паўтараць як саму практыку, так і сам CI будзе паўтарацца на кожную новую змену, якую вы ўносіце ў праект. Гэта дазваляе аптымізаваць рэсурсы, таму што ваша каманда працуе больш эфектыўна. У вас ужо не будзе сітуацыі, калі да вас прылятае баг з кода, з якім вы працавалі 3 месяцы таму. У вас ужо не будзе пераключэння кантэксту, калі вы сядзіце і першыя дзве гадзіны спрабуеце зразумець, што ж было тады і заехаць у сутнасць кантэксту перад тым, як пачнеце нешта выпраўляць.
Як можна памераць поспех або няўдача гэтай практыкі? Калі атраппартаваць вялікаму босу, што мы ўкаранілі на праекце CI, то ён чуе бла-бла-бла. Укаранілі, Ок, а навошта, што гэта нам прынесла, як мы гэта памераем, наколькі мы правільна ці няправільна ўкараняем?
Першае, гэта тое, што за кошт CI мы можам рабіць дэплой часцей і часцей, і часцей менавіта па той прычыне, што ў нас патэнцыйна гэта больш стабільны код. Сапраўды гэтак жа ў нас памяншаецца час на пошук памылкі і памяншаецца час на выпраўленне гэтай памылкі менавіта па тым чынніку, што мы атрымліваем адказ ад сістэмы прама тут і прама цяпер, што з нашым кодам не так.
Іншая практыка, якая ў нас ёсць, гэта практыка Аўтаматычнага тэсціравання, якая часцей за ўсё ідзе з практыкай CI. Яны ідуць поплеч.
Што тут важна разумець? Важна разумець, што тэсты ў нас бываюць розныя. І кожныя аўтаматычныя тэсты накіраваны на рашэнне сваіх задач. У нас ёсць, дапусцім, unit-тэсты, якія дазваляюць нам пратэставаць асобна нейкі модуль, г.зн. як ён працуе ў вакууме. Гэта добра.
Таксама ў нас ёсць інтэграцыйныя тэсты, якія дазваляюць нам зразумець, як розныя модулі інтэгруюцца паміж сабой. Гэта таксама добра.
У нас могуць быць UI automation тэсты, якія дазваляюць нам праверыць, наколькі праца з UI адпавядае тым ці іншым патрабаванням, якія выставіў заказчык і г.д.
Ад таго, якія менавіта тэсты вы запускаеце, гэта можа ўплываць на перыядычнасць іх запуску. Unit-тэсты звычайна ў нас пішуцца кароткімі, невялікімі. І іх можна запускаць рэгулярна.
Калі мы гаворым пра UI automation тэсты, то добра, калі ў вас праект маленькі. У вас UI automation тэсты могуць праходзіць за нейкі адэкватны час. Але звычайна UI automation тэст - гэта рэч, якая ідзе на вялікім праекце некалькі гадзін. І гэта добра, калі некалькі гадзін. Адзінае, на кожны build запускаць іх сэнсу няма. Ёсць сэнс іх запускаць уначы. І калі раніцай усё дашлі на працу: і тэстыравальнікі, і распрацоўнікі, то яны атрымалі нейкую справаздачу, што мы ўначы паганялі аўтатэстам UI і вось такія вынікі атрымалі. І тут гадзіна працы сервера, які будзе правяраць на тое, што ваш прадукт адпавядае нейкім патрабаванням, будзе нашмат танней, чым гадзіна працы таго ж QA-інжынера, нават калі гэта Junior QA-інжынер, які працуе за ежу і за дзякуй. Усё роўна гадзіна працы машыны будзе таннейшай. Менавіта таму мае сэнс у гэта інвеставаць.
У мяне ёсьць яшчэ адзін праект, на якім я працаваў. У нас былі двухтыднёвыя спрынты на гэтым праекце. Праект быў вялікі, важны для фінансавага сектара і памылку дапусціць было нельга. І па двухтыднёвым спрынце, па цыкле распрацоўцы далей ішоў працэс тэсціравання, які займаў яшчэ 4 тыдні. Паспрабуйце ўявіць сабе маштаб трагедыі. Два тыдні мы пішам код, потым мы робім аля CodeFreeze, пакуем гэта ў новую версію прыкладання, выкочваем тэсціроўшчыкам. Тэсціроўшчыкі яшчэ 4 тыдні яго тэсціруюць, г.зн. пакуль яны яго тэсціруюць, мы паспяваем яшчэ дзве версіі ім падрыхтаваць. Гэта рэальна сумны выпадак.
І мы ім сказалі, што калі вы хочаце працаваць больш прадуктыўней, вам мае сэнс укараняць практыку Аўтаматычнага тэсціравання, таму што гэта тое, што ў вас баліць прама тут і прама цяпер.
Практыка Бесперапыннага разгортвання. Выдатна, вы зрабілі build. Гэта ўжо добра. У вас код скампіляваўся. Цяпер было б нядрэнна гэты build разгарнуць на нейкім асяроддзі. Дапусцім, на асяроддзі для распрацоўшчыкаў.
Чаму гэта важна? Па-першае, вы можаце паглядзець, наколькі паспяхова ў вас адбываецца сам працэс разгортвання. Я сустракаў такія праекты, калі я пытаю: «Як вы разгортваеце новую версію дадатку?», мне хлопцы кажуць: «Мы яго збіраем і пакуем у zip-архіў. Адпраўляем адміну па пошце. Адмін гэты архіў пампуе, разгортвае. І ўся кантора пачынае маліцца, каб сервер падхопіць новую версію».
Пачнём з чагосьці простага. Напрыклад, у архіў забыліся пакласці CSS ці забыліся памяняць хэштэг у імі java-script файла. І калі мы робім запыт да сервера, то браўзэр думае, што гэта java-script файл у яго ўжо ёсць і вырашае яго не перапампоўваць. А там была старая версія, чагосьці стала не хапаць. Увогуле праблем можа быць шмат. Таму практыка Бесперапыннага разгортвання дазваляе вам, прынамсі, праверыць, што будзе, калі вы возьмеце чыстую эталонную выяву і зальяце яго на цалкам чыстае новае асяроддзе. Вы можаце паглядзець, да чаго гэта прывядзе.
Акрамя таго, калі вы інтэгруеце код паміж сабой, г.зн. паміж камандай, гэта дазваляе вам таксама паглядзець, як гэта выглядае на UI.
Адна з праблем, якая сустракаецца, дзе выкарыстоўваецца шмат ванільнага java-script, гэта тое, што два распрацоўшчыкі ўзялі і з гарачкі ў аб'екце window абвясцілі зменную з адным імем. І потым, як пашанцуе. Чый java-script файл выцягнецца другім, той і ператрэ змены іншага. Гэта таксама вельмі цікава. Ты заходзіш: у аднаго чалавека адно працуе, у другога - другое не працуе. І выдатна, калі гэта ўсё вылазіць на production.
Наступная практыка, якая ў нас ёсць, гэта практыка Аўтаматычнага аднаўлення, а менавіта адкату на папярэднюю версію прыкладання.
Чаму гэта важна для распрацоўшчыкаў? Ёсць яшчэ тыя, хто памятаюць далёкія-далёкія 90-ыя, калі кампутары былі вялікія, а праграмы маленькія. І шлях у вэб-распрацоўку ляжаў толькі праз php. Не тое што б php - гэта дрэнная мова, хоць гэта і так.
Але праблема была ў іншым. Калі мы дэплаілі новую версію нашага php-сайта, мы, як яго дэплоілі? Часцей за ўсё мы адкрывалі Far Manager ці нешта яшчэ. І залівалі гэтыя файлы на FTP. І мы раптам зразумелі, што ў нас нейкая маленькая-маленькая бага, напрыклад, мы забыліся кропку з коскай паставіць ці забыліся памяняць пароль ад базы, і там стаіць пароль ад базы, якая на local хасце. І вырашаем хуценька падлучыцца на FTP і адрэдагуем файлы прама тамака. Вось гэта проста агонь! Гэта тое, што было папулярна ў 90-ых.
Але, калі вы не зазіралі ў каляндар, 90-ыя былі амаль 30 гадоў таму. Цяпер ужо ўсё адбываецца крыху па-іншаму. І паспрабуйце ўявіць маштаб трагедыі, калі вам кажуць: «Мы задэплоілі на production, але там нешта пайшло ня так. Вось табе лагін і пароль ад FTP, падключайся на production і хуценька там папраў». Калі вы Чак Норыс, то гэта спрацуе. Калі няма, тыя вы рызыкуеце, што вы паправіце адну багу, зробіце яшчэ 10. Вось менавіта таму гэтая практыка адкату на мінулую версію, дазваляе вам дамагчыся шматлікага.
Нават у выпадку, калі нешта недзе неяк дрэннае пралезла на prod, то гэта дрэнна, але не смяротна. Вы можаце адкаціцца на папярэднюю версію, якая ў вас ёсць. Назавіце гэта бэкапам, калі прасцей у такой тэрміналогіі ўспрымаць. Вы можаце адкаціцца на гэтую папярэднюю версію, і карыстачы ўсё роўна змогуць працаваць з вашым прадуктам, а ў вас з'явіцца адэкватны запас па часе. Вы зможаце спакойна, без спешкі, усё гэта ўзяць і лакальна пратэставаць, пафіксіць, а потым ужо заліць новую версію. Гэта рэальна мае сэнс рабіць.
Цяпер давайце паспрабуем сумясціць недзе неяк дзве папярэднія практыкі разам. Мы атрымаем трэцюю, якая называецца Release Management.
Калі мы гаворым пра Continuous Deployment у класічным яго ўяўленні, то мы кажам, што мы павінны выцягнуць з рэпазітара код з нейкай галінкі, скампіляваць і задэплоіць. Гэта добра, калі ў нас адно асяроддзе. Калі ў нас акружэнняў некалькі, тое гэта азначае, што мы павінны кожны раз выцягваць код няхай нават з таго ж комміта. Мы кожны раз будзем яго выцягваць, кожны раз будзем яго білдзіць і будзем дэплоіць на новае асяроддзе. Па-першае, гэта час, таму што на build праекта, калі ен у вас вялікі і прыйшоў з 90-ых, то гэта можа заняць некалькі гадзін.
Акрамя таго, ёсць іншы смутак. Калі вы будзеце білдзіць няхай нават на той жа самай машыне, вы будзеце білдзіць тыя ж самыя зыходнікі, у вас усё роўна няма гарантыі, што гэтая машына знаходзіцца ў тым жа стане, у якім яна была падчас мінулага білда.
Дапушчальны, хтосьці зайшоў і абнавіў вам DotNet ці, наадварот, хтосьці вырашыў нешта выдаліць. І потым у вас кагнітыўны дысананс, што з гэтага комміту два тыдні таму мы білдзілі білд і ўсё было добра, а зараз накшталт як тая ж самая машына, той жа самы коміт, той жа самы код, які мы спрабуем білдзіць, але не атрымліваецца. Вы доўга з гэтым будзеце разбірацца і не факт, што разбярэцеся. Прынамсі, нерваў сапсуеце сабе вельмі шмат.
Таму практыка Release Management прапануе ўкараніць дадатковую абстракцыю, якая завецца сховішча артэфактаў ці галерэя, ці бібліятэка. Можна назваць як заўгодна.
Асноўная ідэя ў тым, што, як толькі ў нас з'яўляецца там нейкі коміт, дапусцім, у галінцы, якую мы ўжо гатовыя дэплоіць на нашы розныя асяроддзі, мы збіраем прыкладанні з гэтага комміта і ўсё, што нам трэба для гэтага прыкладання, мы пакуем у zip-архіў і захоўваем у нейкім надзейным сховішчы. І з гэтага сховішча мы гэты zip-архіў можам у любы момант дастаць.
Потым мы бярэм і аўтаматычна разгортваем яго на dev-акружэнні. Там ганяем, і калі ўсё добра, то разгортваем на stage. Калі ўсё добра, то разгортваем на production адзін і той жа архіў, адны і тыя ж бінарнікі, скампіляваныя роўна адзін раз.
Акрамя таго, калі ў нас ёсць вось такая галерэя, гэта таксама дапамагае нам адрасаваць рызыкі, якія мы адрасавалі на мінулым слайдзе, калі мы казалі пра rollback да папярэдняй версіі. Калі вы выпадкова задэплоілі штосьці не тое, вы заўсёды можаце з вось гэтай галерэі ўзяць любую іншую папярэднюю версію і сапраўды гэтак жа расдэплоіць на гэтыя асяроддзі. Гэта дазваляе вам у выпадку нейкага шухера лёгка адкаціцца на папярэднюю версію.
Ёсць яшчэ адна цудоўная практыка. Усе мы з вамі разумеем, што, калі мы адкочваем нашы прыкладанні на папярэднюю версію, гэта можа азначаць, што інфраструктура нам патрэбна таксама папярэдняй версіі.
Калі мы гаворым пра віртуальную інфраструктуру, многія думаюць, што гэта нешта такое, што настройваюць адміны. І калі вам трэба, дапусцім, атрымаць новы сервер, на якім вы хочаце патэставаць новую версію вашага прыкладання, то вы павінны пісаць тыкет адмінам або дэвапсам. Дэвопсы будуць браць на гэта 3 тыдні. І праз 3 тыдні скажуць, што мы табе ўсталявалі віртуалку, дзе адно ядро, два гігабайта аператыўнай памяці і Windows-сервер без DotNet. Вы кажаце: "А я хацеў DotNet". Яны: "Ok, прыходзь праз 3 тыдні".
Ідэя ў тым, што, выкарыстоўваючы практыку "Інфраструктура як код", вы можаце ставіцца да вашай віртуальнай інфраструктуры ўсяго толькі як да яшчэ аднаго чарговага рэсурсу.
Магчыма, калі хтосьці з вас распрацоўвае прыкладанні на DotNet, вы маглі чуць пра такую бібліятэку, як Entity Framework. І, магчыма, вы нават чулі, што Entity Framework – гэта адзін з падыходаў, які Microsoft актыўна пушыць. Для працы з базай дадзеных гэта падыход, які завецца Code First. Гэта калі вы ў кодзе апісваеце, як вы хочаце, каб выглядала ваша база дадзеных. І потым вы разгортваеце дадатак. Яно падключаецца да базы, яно само вызначае, якія табліцы ёсць, якіх табліц няма, і ўсё, што вам неабходна, стварае.
Гэтак жа вы можаце рабіць з вашай інфраструктурай. Няма ніякай розніцы тым часам ці патрэбна вам для праекта база дадзеных або патрэбен для праекта Windows-сервер. Гэта ўсяго толькі рэсурс. І вы можаце аўтаматызаваць стварэнне гэтага рэсурсу, вы можаце аўтаматызаваць настройку гэтага рэсурсу. Адпаведна, кожны раз, калі вы захочаце пратэставаць нейкую новую канцэпцыю, нейкі новы падыход, вам не трэба будзе пісаць тыкет дэвапсам, вы зможаце ўзяць і проста разгарнуць самі сабе з ужо гатовых шаблонаў, з гатовых скрыптоў ізаляваную інфраструктуру і правесці там усе вашыя эксперыменты. Можаце выдаліць гэта, атрымаць нейкія вынікі і апатраппартаваць пра гэта далей.
Наступная практыка, якая таксама ёсць і таксама важная, але якой мала хто карыстаецца, гэта Application Performance Monitoring.
Пра Application Performance Monitoring жадаў сказаць толькі адну рэч. Што найбольш важна ў гэтай практыцы? Гэта тое, што Application Performance Monitoring - гэта прыкладна гэтак жа, як і рамонт у кватэры. Гэта не фінальны стан, гэта працэс. Вам трэба праводзіць яго рэгулярна.
Па-добраму было б добра Application Performance Monitoring праводзіць ці ледзь не на кожны build, хоць, як вы разумееце, далёка не заўсёды гэта магчыма. Але, прынамсі, на кожны рэліз яго трэба праводзіць.
Чаму гэта важна? Таму што калі ў вас раптам пайшла прасадка па прадукцыйнасці, тое вам трэба выразна разумець з-за чаго. Калі ў вас у камандзе, дапусцім, двухтыднёвыя спрынты, тыя вы хоць бы раз у два тыдні павінны разгортваць ваша прыкладанне на нейкі асобна стаячы сервер, дзе ў вас выразна фіксаваны працэсар, аператыўная памяць, дыскі і т. д. І праганяеце тыя ж самыя тэсты прадукцыйнасці. Атрымліваеце вынік. Глядзіце, як яно памянялася ад папярэдняга спрынту.
І калі вы даведаецеся аб тым, што прасадка пайшла рэзка кудысьці ўніз, то гэта будзе азначаць, што гэта было ўсяго толькі з-за змен, якія былі на працягу апошніх двух тыдняў. Гэта дазволіць вам нашмат хутчэй вызначыць і выправіць гэтую праблему. І зноў гэта тыя ж прыкладна метрыкі, па якіх можна памераць, наколькі паспяхова гэта ў вас атрымалася.
Наступная практыка, якая ў нас ёсьць, гэта практыка Configuration Management. Вельмі мала, хто ставіцца да гэтага сур'ёзна. Але, паверце мне, гэта насамрэч вельмі сур'ёзная штука.
Нядаўна была смешная гісторыя. Прыйшлі да мяне хлопцы і кажуць: "Дапамажы правесці нам security audit нашага прыкладання". Мы доўга глядзелі разам у код, яны мне расказвалі аб дадатку, малявалі схемы. І плюс-мінус усё было лагічна, зразумела, бяспечна, але было адно НС! У іх у source control ляжалі канфігурацыйныя файлы ў тым ліку ад production з IP базы дадзеных, з лагінамі і паролямі для падлучэння да гэтых баз дадзеных і т. д.
І я кажу: «Хлопцы, добра вы firewall-ом зачынілі сваё production-асяроддзе, але тое, што ў вас ёсць лагін і пароль ад production-базы прама ў source control і любы распрацоўнік мае магчымасць гэта прачытаць, гэта ўжо велізарная рызыка бяспекі. І якім бы суперабароненым ваша прыкладанне не было з пункта гледжання кода, калі ў вас гэта застанецца ляжаць у source control, то ніколі нідзе ніякі аўдыт вы не пройдзеце». Вось пра што я і кажу.
Упраўленне канфігурацыяй. На розным асяроддзі ў нас можа быць розная канфігурацыя. Напрыклад, у нас могуць быць розныя лагіны і паролі для баз даных для QA, demo, production-акружэння і г.д.
Настройку гэтай канфігурацыі таксама можна аўтаматызаваць. Яна павінна заўсёды быць асобнай ад непасрэдна прыкладання. Чаму? Таму што прыкладанне вы збілдзілі адзін раз, і потым з дадаткам усё роўна - падлучаецеся да SQL-серверу па такім-то IP або па такім-то IP, яно павінна працаваць аднолькава. Таму калі раптам хтосьці з вас да гэтага часу хардкадзіць connection string у кодзе, то запомніце, што я вас знайду і пакараю, калі вы апынецеся са мной на адным праекце. Гэта заўсёды выносіцца ў асобную канфігурацыю, напрыклад, у web.config.
І гэтая канфігурацыя ўжо кіруецца асобна, т. е. гэта як раз той момант, калі можа прыйсці распрацоўшчык і адмін, сесці ў адным пакоі. І распрацоўшчык можа сказаць: «Глядзі, вось бінарнікі майго прыкладання. Яны працуюць. Дадатку для працы патрэбна база даных. Вось побач з бінарнікамі ляжыць файл. У гэтым файле гэтае поле адказвае за лагін, гэта за пароль, гэта за IP. Дэплой яго куды заўгодна». І адміну гэта проста і зразумела. Ён можа гэта дэплоіць і сапраўды куды заўгодна, кіруючы гэтай канфігурацыяй.
І апошняя практыка, пра якую хацеў бы сказаць, гэта практыка, якая вельмі-вельмі моцна адносіцца да аблокаў. І максімальны эфект яна прыносіць, калі вы працуеце ў воблаку. Гэта Аўтаматычнае выдаленне вашага асяроддзя.
Я ведаю, што на гэтай канферэнцыі прысутнічае некалькі людзей з тых каманд, з якімі я працую. І з усімі камандамі, з якімі я працую, мы выкарыстоўваем вось гэтую практыку.
Чаму? Вядома, было б класна, калі б на кожнага распрацоўшчыка была б віртуальная машына, якая б працавала 24/7. Але, магчыма, для вас гэта навіна, магчыма, вы не зважалі, але сам па сабе распрацоўшчык не працуе 24/7. Распрацоўнік працуе звычайна 8 гадзін у дзень. Няхай ён прыходзіць на працу рана, у яго вялікі абед, на працягу якога ён ходзіць у спартзалу. Няхай гэта 12 гадзін у дзень, калі распрацоўшчык рэальна карыстаецца гэтымі рэсурсамі. Па нашым заканадаўстве ў нас у тыдні ёсць 5 з 7 дзён, якія лічацца працоўнымі.
Адпаведна, у працоўныя дні гэтая машына павінна працаваць не 24 гадзіны, а толькі 12, а на выходныя дні гэтая машына працаваць наогул не павінна. Здавалася б, усё вельмі проста, але што тут важна сказаць? Укараняючы вось гэтую простую практыку па такім базавым раскладзе, гэта дазваляе вам паменшыць кошт утрымання гэтых асяродкаў на 70 %, т. е. вы цану на вашыя dev, QA, demo, environment вы ўзялі і падзялілі на 3.
Пытанне, што рабіць з астатнімі грашыма? Напрыклад, купіць распрацоўшчыкам ReSharper, калі яшчэ не купілі. Або зладзіць кактэйльную вечарынку. Калі ў вас раней было адно асяроддзе, на якім пасвіліся і dev, і QA, і ўсё, то зараз вы можаце зрабіць 3 розных, якія будуць ізаляваныя, і людзі не будзе мяшаць адзін аднаму.
Што тычыцца слайда з пастаянным замерам прадукцыйнасці, як можна параўнаць прадукцыйнасць, калі ў нас у праекце было 1 запісаў у базе дадзеных, праз два месяцы іх мільён? Як зразумець, чаму і які сэнс у замеры прадукцыйнасці?
Гэта добрае пытанне, таму што вы прадукцыйнасць павінны замяраць заўсёды на адных і тых жа рэсурсах. Т. е. вы выкочваеце новы код, вы замяраеце прадукцыйнасць на новым кодзе. Напрыклад, вам неабходна праверыць розныя сцэнары прадукцыйнасці, дапусцім, вы хочаце праверыць, як прыкладанне працуе на лёгкай нагрузцы, дзе 1 карыстальнікаў і памер базы дадзеных 000 гігабайтаў. Вы замералі, атрымалі лічбы. Далей бярэм іншы сцэнар. Напрыклад, 5 карыстальнікаў, памер базы 5 тэрабайт. Атрымалі вынікі, запомнілі.
Што тут важна? Тут важна тое, што ў залежнасці ад сцэнара, ад аб'ёму дадзеных, ад колькасці адначасовых карыстачоў і т. д., вы можаце ўперціся ў тыя ці іншыя ліміты. Напрыклад, у ліміт сеткавай карты ці ў ліміт цвёрдай кружэлкі, ці ў ліміт магчымасцяў працэсара. Вось што вам важна зразумець. На розных сцэнарах вы ўпіраецеся ў тыя ці іншыя ліміты. І трэба разумець лічбы, калі вы ў іх упрэцеся.
Тут гаворка ідзе аб замеры прадукцыйнасці на спецыяльным тэставым асяроддзі? Т. е. гэта не production?
Так, гэта не production, гэта тэставае асяроддзе, якое заўсёды аднолькавае, каб вы маглі параўнаць яго з папярэднімі замерамі.
Зразумеў, дзякуй!
Калі пытанняў няма, я думаю, можам скончыць. Дзякуй!
Крыніца: habr.com