Най-добрите DevOps практики за разработчици. Антон Бойко (2017)

Докладът ще говори за някои DevOps практики, но от гледна точка на разработчика. Обикновено всички инженери, които се присъединяват към DevOps, вече имат няколко години административен опит зад гърба си. Но това не означава, че тук няма място за разработчика. По-често разработчиците са заети да поправят „следващия спешно критичен бъг за деня“ и нямат време дори да хвърлят бърз поглед към полето DevOps. Според разбирането на автора DevOps е, първо, здрав разум. Второ, това е възможност да бъдем по-ефективни. Ако сте разработчик, имате здрав разум и искате да бъдете по-ефективни като екипен играч, този доклад е за вас.

Нека се представя, напълно признавам, че в стаята има хора, които не ме познават. Казвам се Антон Бойко, аз съм Microsoft Azure MVP. Какво е MVP? Това е Model-View-Presenter. Model-View-Presenter съм точно аз.

Освен това в момента заемам позицията на архитект на решения в Ciklum. И съвсем наскоро си купих такъв красив домейн и актуализирах имейла си, който обикновено показвам на презентации. Можете да ми пишете на: аз [куче] byokoant.pro. Можете да ми изпратите имейл с въпроси. Обикновено им отговарям. Единственото нещо е, че не бих искал да получавам въпроси по имейл, които се отнасят до две теми: политика и религия. За всичко останало можете да ми пишете по имейл. Ще мине известно време, ще отговоря.

Няколко думи за себе си:

• Вече 10 години съм в тази сфера.
• Работех в Microsoft.
• Аз съм основателят на украинската Azure общност, която основахме някъде през 2014 г. И все още го имаме и го развиваме.
• Аз съм и баща на основателя на конференцията Azure, която сме домакини в Украйна.
• Също така помагам в организирането на Global Azure Bootcamp в Киев.
• Както казах, аз съм Microsoft Azure MVP.
• Доста често говоря на конференции. Наистина обичам да говоря на конференции. През изминалата година успях да изпълня около 40 пъти. Ако подминете Украйна, Беларус, Полша, България, Швеция, Дания, Холандия, Испания или многократно друга страна в Европа, тогава е напълно възможно, когато отидете на конференция, която има облачна тема в своя поток, може да ме видите в списъка с оратори.
• Аз също съм фен на Стар Трек.

Нека поговорим малко за дневния ред. Нашата програма е много проста:

• Ще говорим за това какво е DevOps. Нека поговорим защо това е важно. Преди това DevOps беше ключова дума, която пишехте в автобиографията си и веднага получавахте +$500 заплата. Сега трябва да напишете например blockchain в автобиографията си, за да получите +500 долара към заплатата си.
• И тогава, когато разберем малко какво е това, ще говорим какво представляват DevOps практиките. Но не толкова в контекста на DevOps като цяло, а относно онези практики на DevOps, които може да представляват интерес за разработчиците. Ще ви кажа защо могат да ви заинтересуват. Ще ви кажа защо изобщо трябва да правите това и как може да ви помогне да изпитвате по-малко болка.

Традиционна картина, която много хора показват. Това се случва в много проекти. Това е, когато имаме отдели за развитие и операции, които поддържат нашия софтуер. И тези отдели не комуникират помежду си.

Може би, ако не сте успели да го усетите толкова ясно в отделите DevOps и операциите, можете да направите аналогия с отделите Dev и QA. Има хора, които разработват софтуер и има QA хора, които са лоши от гледна точка на разработчиците. Например, изпращам чудесния си код в хранилището и там седи някакъв негодник, който ми връща този код и казва, че вашият код е лош.

Всичко това се случва, защото хората не общуват помежду си. И те си хвърлят някакви пакети, някакво приложение през някаква стена от неразбиране и се опитват да направят нещо с тях.

Точно тази стена е предназначена да разруши DevOps културата, т.е. накарайте хората да общуват помежду си и поне да разберат какво правят различните хора в проекта и защо работата им е важна.

И когато говорим за DevOps, някой ще ви каже, че DevOps е, когато проектът има непрекъсната интеграция; някой ще каже, че DevOps е, ако проектът прилага практиката „инфраструктура като код“; някой ще каже, че първата стъпка към DevOps е разклоняване на функции, флагове на функции.

По същество всичко това е вярно по свой начин. Но това са само най-добрите практики, които имаме. Преди да преминете към тези практики, предлагам да разгледате този слайд, който показва 3-те етапа на внедряване на методологията Dev-Ops във вашия проект, във вашата компания.

Този слайд има и второ неофициално име. Можете да търсите онлайн, за да разберете кои са 3-те мускетари на DevOps. Възможно е да намерите тази статия. Защо 3 мускетари? Отдолу пише: хора, процеси и продукти, т.е. ППП – Портос, Портос и Портос. Ето 3-те мускетари на DevOps. Тази статия описва по-подробно защо това е важно и какво включва.

Когато започнете да прилагате DevOps култура, е много важно тя да бъде внедрена в следния ред.

Първоначално трябва да говорите с хората. И трябва да обясните на хората какво е това и как могат да извлекат някои ползи от него.

Нашата конференция се нарича DotNet Fest. И както ми казаха организаторите, поканихме тук основно публика от разработчици, така че се надявам повечето хора в залата да участват в разработката.

Ще говорим за хората, ще говорим за това, което разработчиците искат да правят всеки ден. Какво искат най-много? Те искат да напишат нов код, да използват новомодни рамки, да създадат нови функции. Какво най-малко искат разработчиците? Коригирайте стари грешки. Надявам се да сте съгласни с мен. Това искат разработчиците. Те искат да пишат нови функции, не искат да коригират грешки.

Броят на грешките, които даден разработчик произвежда, зависи от това колко изправени са ръцете му и колко растат от раменете му, а не от джобовете на задника му. Но въпреки това, когато имаме голям проект, понякога се случва, че е невъзможно да следим всичко, така че би било хубаво да използваме някои подходи, които ще ни помогнат да напишем по-стабилен и по-качествен код.

Какво най-много искат QA? Не знам дали са в залата. Трудно ми е да кажа, че искам QA, защото никога не съм бил такъв. И без обиди към момчетата, ще се каже, че се надявам никога да не го направя. Но не поради причината, че смятам работата им за безсмислена и безполезна, а защото не се смятам за човек, който би могъл да върши тази работа ефективно, така че дори няма да се опитам да я направя. Но доколкото разбирам, това, което QA не харесва най-много, е да работи сутрин, непрекъснато да изпълнява някакви регресионни тестове, да настъпва същите грешки, които са докладвали на разработчиците преди 3 спринта и да казва: „Кога ще , мосю Д'Артанян, поправете тази грешка.' А мосю Д'Артанян му отговаря: „Да, да, да, вече го поправих.“ И как се случи така, че поправих един бъг и направих 5 по пътя.

Хората, които поддържат това решение в производството, искат това решение да работи без грешки, така че да не се налага да рестартират сървъра всеки петък, когато всички нормални хора отиват в бара. Разработчиците внедриха в петък, администраторите седят до събота, опитвайки се да оправят и коригират това внедряване.

И когато обясните на хората, че те са насочени към решаване на същите проблеми, можете да преминете към формализиране на процесите. Много е важно. Защо? Защото, когато казваме „формализация“, за вас е важно поне някъде върху салфетка да опишете как протичат вашите процеси. Трябва да разберете, че ако, например, внедрявате в QA среда или производствена среда, тогава това винаги се случва в този ред; на тези етапи ние изпълняваме, например, автоматични модулни тестове и UI тестове. След внедряването проверяваме дали внедряването е преминало добре или зле. Но вие вече имате ясен списък с действия, които трябва да се повтарят отново и отново, когато внедрявате в производство.

И едва когато вашите процеси са формализирани, започвате да избирате продукти, които ще ви помогнат да автоматизирате тези процеси.

За съжаление много често виждам това да се случва в обратна посока. Веднага щом някой чуе думата „DevOps“, те веднага предлагат да инсталират Jenkins, защото вярват, че веднага щом инсталират Jenkins, ще имат DevOps. Те инсталираха Дженкинс, прочетоха статиите „Как да“ на уебсайта на Дженкинс, опитаха се да вмъкнат процеси в тези статии „Как да“ и след това дойдоха при хората и ги наклониха, казвайки, че книгата казва, че трябва да го направите по този начин, така че го правим по този начин.

Не че Дженкинс е лош инструмент. Не искам да го кажа по никакъв начин. Но това е само един от продуктите. И кой продукт да използвате трябва да бъде последното ви решение, а не първото. Вашият продукт не трябва да се ръководи от прилагането на култура и подходи. Това е много важно да се разбере, поради което отделям толкова много време на този слайд и обяснявам всичко това толкова дълго.

Нека поговорим за практиките на DevOps като цяло. Какво са те? Каква е разликата? Как да ги пробвам? Защо са важни?

Първата практика, за която може би сте чували, се нарича непрекъсната интеграция. Може би някой от проекта има непрекъсната интеграция (CI).

Най-големият проблем е, че най-често, когато попитам човек: „Имате ли CI по проекта?“ и той казва: „Да“, след което, когато го питам какво прави, той ми описва абсолютно целия процес на автоматизация. Това не е съвсем вярно.

Всъщност практиката на CI е насочена само към интегриране на кода, който различни хора пишат, в някакъв вид единна кодова база. Това е всичко.

Заедно с CI обикновено има и други практики по пътя - като непрекъснато внедряване, управление на издания, но ще говорим за това по-късно.

Самият CI ни казва, че различни хора пишат код и този код трябва непрекъснато да бъде интегриран в единна кодова база.

Какво ни дава това и защо е важно? Ако имаме DotNet, тогава това е добре, това е компилиран език, можем да компилираме нашето приложение. Ако се компилира, това вече е добър знак. Това все още не означава нищо, но е първият добър знак, че можем поне да компилираме.

След това можем да проведем някои тестове, което също е отделна практика. Всички тестове са зелени - това е вторият добър знак. Но това отново не означава нищо.

Но защо бихте направили това? Всички практики, за които ще говоря днес, носят приблизително еднаква стойност, т.е. приблизително еднакви ползи и също се измерват приблизително по един и същи начин.

Първо, това ви позволява да ускорите доставката. Как това ви позволява да ускорите доставката? Когато направим някои нови промени в нашата кодова база, можем веднага да опитаме да направим нещо с този код. Ние не чакаме да дойде четвъртък, защото в четвъртък го пускаме в QA Environment, правим го точно тук и точно тук.

Ще ви разкажа една тъжна история от моя живот. Беше много отдавна, когато бях още млад и красив. Сега вече съм млад, красив и умен, и скромен. Преди време бях в един проект. Имахме голям екип от около 30 разработчици. И имахме голям, голям Enterprise проект, който се развиваше около 10 години. И имахме различни клонове. В хранилището имахме клон, в който ходеха разработчици. И имаше клон, който показваше версията на кода, който е в производство.

Производственият клон изостана с 3 месеца от клона, който беше достъпен за разработчиците. Какво означава това? Това означава, че веднага щом имам грешка някъде, която отива в производство по вина на разработчиците, защото те са го позволили, и по грешка на QA, защото са го разгледали, тогава това означава, че ако получа задача за актуална корекция за производство, тогава трябва да върна промените в кода си преди 3 месеца. Трябва да си спомня какво имах преди 3 месеца и да се опитам да го поправя там.

Ако все още не сте имали този опит, можете да го изпробвате в дома си. Основното нещо е да не го пробвате на комерсиален. Напишете няколко реда код, забравете за тях за шест месеца и след това се върнете и се опитайте бързо да обясните за какво са тези редове код и как можете да ги коригирате или оптимизирате. Това е много, много вълнуващо преживяване.

Ако имаме практика на непрекъсната интеграция, тогава това ни позволява да я проверим с редица автоматизирани инструменти точно тук и точно сега, веднага след като съм написал своя код. Това може да не ми даде пълната картина, но въпреки това ще премахне поне част от рисковете. И ако има някакъв потенциален бъг, ще знам за него точно сега, тоест буквално след няколко минути. Няма да има нужда да връщам 3 месеца назад. Ще трябва да върна само 2 минути назад. Една добра кафемашина дори няма да има време да приготви кафе за 2 минути, така че това е доста готино.

Това има стойност, че може да се повтаря многократно във всеки проект, т.е. не само този, на който сте го настроили. Можете да повторите както самата практика, така и самият CI ще се повтаря за всяка нова промяна, която правите в проекта. Това ви позволява да оптимизирате ресурсите, защото вашият екип работи по-ефективно. Вече няма да имате ситуация, в която ви идва бъг от кода, с който сте работили преди 3 месеца. Вече няма да имате превключване на контекста, когато седите и прекарвате първите два часа, опитвайки се да разберете какво се е случило тогава и да навлезете в същността на контекста, преди да започнете да коригирате нещо.

Как можем да измерим успеха или неуспеха на тази практика? Ако докладвате на големия шеф какво сме внедрили по проекта CI, той чува бла бла бла. Приложихме го, добре, но защо, какво ни донесе, как го измерваме, колко правилно или неправилно го прилагаме?

Първият е, че благодарение на CI можем да внедряваме все по-често и по-често, точно защото нашият код е потенциално по-стабилен. По същия начин се намалява времето ни за намиране на грешка и времето за коригиране на тази грешка именно поради причината, че получаваме отговор от системата точно тук и точно сега какво не е наред с нашия код.

Друга практика, която имаме, е практиката за автоматизирано тестване, която най-често идва с практиката CI. Вървят ръка за ръка.

Какво е важно да разберем тук? Важно е да разберете, че нашите тестове са различни. И всеки автоматизиран тест е насочен към решаване на собствените си проблеми. Имаме например единични тестове, които ни позволяват да тестваме модул отделно, т.е. Как работи във вакуум? Това е добре.

Имаме и интеграционни тестове, които ни позволяват да разберем как различните модули се интегрират един с друг. Също така е добро.

Може да имаме тестове за автоматизация на UI, които ни позволяват да проверим доколко работата с UI отговаря на определени изисквания, зададени от клиента и т.н.

Конкретните тестове, които изпълнявате, могат да повлияят на това колко често ги изпълнявате. Единичните тестове обикновено се пишат кратки и малки. И те могат да се стартират редовно.

Ако говорим за тестове за автоматизация на потребителския интерфейс, тогава е добре проектът ви да е малък. Вашите тестове за автоматизация на потребителския интерфейс може да отнемат известно време. Но обикновено тестът за автоматизация на потребителския интерфейс е нещо, което отнема няколко часа при голям проект. И е добре, ако са няколко часа. Единственото нещо е, че няма смисъл да ги пускате за всяка компилация. Има смисъл да ги пускате през нощта. И когато всички дойдоха на работа сутринта: и тестери, и разработчици, те получиха някакъв вид доклад, че сме пуснали автотеста на потребителския интерфейс през нощта и получихме тези резултати. И тук един час работа на сървър, който ще провери дали вашият продукт отговаря на някои изисквания, ще бъде много по-евтин от час работа на същия QA инженер, дори ако той е Junior QA инженер, който работи за храна и благодарност. Все пак един час работа на машината ще бъде по-евтин. Ето защо има смисъл да се инвестира в него.

Имам друг проект, върху който работя. Имахме двуседмични спринтове по този проект. Проектът беше голям, важен за финансовия сектор и не можеше да се направи грешка. И след двуседмичен спринт, цикълът на разработка беше последван от процес на тестване, който отне още 4 седмици. Опитайте се да си представите мащаба на трагедията. Пишем код в продължение на две седмици, след което го правим като CodeFreeze, пакетираме го в нова версия на приложението и го пускаме на тестери. Тестерите го тестват още 4 седмици, т.е. Докато го тестват, ние имаме време да подготвим още две версии за тях. Това е наистина тъжен случай.

И ние им казахме, че ако искате да сте по-продуктивни, има смисъл да приложите практики за автоматизирано тестване, защото това е, което ви наранява точно тук, точно сега.

Практикувайте непрекъснато внедряване. Страхотно, завършихте изграждането. Това вече е добре. Вашият код е компилиран. Сега би било хубаво да внедрите тази компилация в някаква среда. Да кажем в среда за разработчици.

Защо е важно? Първо, можете да видите доколко сте успешни със самия процес на внедряване. Срещал съм проекти като този, когато попитам: „Как се внедрява нова версия на приложението?“, момчетата ми казват: „Ние го сглобяваме и го пакетираме в zip архив. Изпращаме го на администратора по пощата. Администраторът изтегля и разширява този архив. И целият офис започва да се моли сървърът да вземе новата версия.

Да започнем с нещо просто. Например, те са забравили да поставят CSS в архива или са забравили да променят хаштага в името на файла на java-script. И когато отправим заявка към сървъра, браузърът смята, че вече има този java-script файл и решава да не го изтегля. И имаше стара версия, нещо липсваше. Като цяло може да има много проблеми. Следователно практиката на непрекъснато внедряване ви позволява поне да тествате какво би се случило, ако вземете чисто референтно изображение и го качите в напълно чиста нова среда. Можете да видите докъде води това.

Освен това, когато интегрирате код помежду си, т.е. между командата, това ви позволява също да видите как изглежда в потребителския интерфейс.

Един от проблемите, които възникват, когато се използва много ванилен java-скрипт, е, че двама разработчици прибързано са декларирали променлива със същото име в обекта прозорец. И тогава, в зависимост от вашия късмет. Чийто java-script файл е изтеглен втори, ще презапише промените на другия. Освен това е много вълнуващо. Влизате: едно нещо работи за един човек, друго не работи за друг. И е „прекрасно“, когато всичко излезе в производство.

Следващата практика, която имаме, е практиката на автоматично възстановяване, а именно връщане към предишната версия на приложението.

Защо това е важно за разработчиците? Все още има хора, които си спомнят далечните, далечни 90-те години, когато компютрите бяха големи, а програмите бяха малки. И единственият начин за уеб разработка беше чрез PHP. Не че PHP е лош език, въпреки че е така.

Но проблемът беше друг. Когато внедрихме нова версия на нашия php сайт, как я внедрихме? Най-често отваряхме Far Manager или нещо друго. И качи тези файлове на FTP. И внезапно осъзнахме, че имаме някакъв малък, малък бъг, например, забравихме да поставим точка и запетая или сме забравили да сменим паролата за базата данни, а има парола за базата данни, която е на локалния хост. И решаваме бързо да се свържем с FTP и да редактираме файловете точно там. Това е просто огън! Това беше популярно през 90-те години.

Но ако не сте гледали календара, 90-те години бяха преди почти 30 години. Сега всичко се случва малко по-различно. И се опитайте да си представите мащаба на трагедията, когато ви кажат: „Разгърнахме се в производство, но там нещо се обърка. Ето вашето FTP потребителско име и парола, свържете се с производството и бързо го поправете там. Ако си Чък Норис, това ще свърши работа. Ако не, тогава рискувате, че ако коригирате един бъг, ще направите още 10. Ето защо тази практика на връщане към предишната версия ви позволява да постигнете много.

Дори ако нещо лошо някак си е попаднало в продукцията някъде, то е лошо, но не е фатално. Можете да се върнете към предишната версия, която имате. Наречете го резервно копие, ако е по-лесно да го възприемете с тази терминология. Можете да се върнете към тази предишна версия и потребителите все още ще могат да работят с вашия продукт и ще имате достатъчно време за буфериране. Можете спокойно, без да бързате, да вземете всичко това и да го тествате локално, да го поправите и след това да качите нова версия. Наистина има смисъл да се направи това.

Сега нека се опитаме да съчетаем по някакъв начин двете предишни практики. Ще получим трета, наречена Release Management.

Когато говорим за непрекъснато внедряване в неговата класическа форма, казваме, че трябва да изтеглим код от някакъв клон от хранилището, да го компилираме и да го внедрим. Добре е, ако имаме еднаква среда. Ако имаме няколко среди, това означава, че трябва да изтегляме кода всеки път, дори от един и същ комит. Ще го изваждаме всеки път, ще го изграждаме всеки път и ще го внедряваме в нова среда. Първо, това е време, защото изграждането на проект, ако имате голям и идва от 90-те години, може да отнеме няколко часа.

Освен това има и друга тъга. Когато изграждате, дори на една и съща машина, вие ще изграждате същите източници, все още нямате гаранция, че тази машина е в същото състояние, в което беше по време на последното компилиране.

Да приемем, че някой влезе и актуализира DotNet вместо вас или, обратно, някой реши да изтрие нещо. И тогава имате когнитивен дисонанс, че от този комит преди две седмици изграждахме компилация и всичко беше наред, но сега изглежда, че същата машина, същият комит, същият код, който се опитваме да изградим, но не работи . Ще се занимавате с това дълго време и не е факт, че ще го разберете. Най-малкото ще си развалите много нервите.

Следователно практиката за управление на изданията предлага въвеждане на допълнителна абстракция, наречена хранилище на артефакти, галерия или библиотека. Можете да го наричате както искате.

Основната идея е, че веднага щом имаме някакъв вид ангажимент там, да речем, в клон, който сме готови да внедрим в нашите различни среди, ние събираме приложения от този комит и всичко, от което се нуждаем за това приложение, ние го пакетираме в zip архив и го запазете в някакво надеждно хранилище. И от това хранилище можем да получим този zip архив по всяко време.

След това го вземаме и автоматично го внедряваме в средата за разработка. Състезаваме се там и ако всичко е наред, тогава се разгръщаме на сцената. Ако всичко е наред, тогава внедряваме същия архив в производството, същите двоични файлове, компилирани точно веднъж.

Освен това, когато имаме галерия като тази, това също ни помага да се справим с рисковете, които разгледахме на последния слайд, когато говорихме за връщане към предишната версия. Ако случайно сте внедрили нещо нередно, винаги можете да вземете всяка друга предишна версия от тази галерия и да я деинсталирате в тези среди по същия начин. Това ви позволява лесно да се върнете към предишната версия, ако нещо се обърка.

Има и друга чудесна практика. Вие и аз всички разбираме, че когато върнем приложенията си към предишна версия, това може да означава, че също се нуждаем от инфраструктурата на предишната версия.

Когато говорим за виртуална инфраструктура, много хора смятат, че това е нещо, което администраторите настройват. И ако имате нужда, да речем, да получите нов сървър, на който искате да тествате нова версия на вашето приложение, тогава трябва да напишете билет до администраторите или devops. Devops ще отнеме 3 седмици за това. И след 3 седмици ще ви кажат, че сме ви инсталирали виртуална машина, с едно ядро, два гигабайта RAM и Windows сървър без DotNet. Казвате: „Но аз исках DotNet.“ Те: „Добре, върнете се след 3 седмици.“

Идеята е, че като използвате практиките на инфраструктурата като код, можете да третирате своята виртуална инфраструктура просто като още един ресурс.

Може би, ако някой от вас разработва приложения в DotNet, може би е чувал за библиотека, наречена Entity Framework. И може би дори сте чували, че Entity Framework е един от подходите, които Microsoft активно прокарва. За работа с база данни това е подход, наречен Code First. Това е, когато описвате в код как искате да изглежда вашата база данни. И след това разгръщате приложението. Той се свързва с базата данни, сам определя кои таблици има и кои не и създава всичко необходимо.

Можете да направите същото с вашата инфраструктура. Няма разлика между това дали имате нужда от база данни за проект или дали имате нужда от Windows сървър за проект. Това е просто ресурс. И можете да автоматизирате създаването на този ресурс, можете да автоматизирате конфигурацията на този ресурс. Съответно, всеки път, когато искате да тествате някаква нова концепция, някакъв нов подход, няма да е необходимо да пишете билет за devops, можете просто да разположите изолирана инфраструктура за себе си от готови шаблони, от готови скриптове и да я внедрите там са всичките ти експерименти. Можете да изтриете това, да получите някои резултати и да докладвате допълнително за него.

Следващата практика, която също съществува и също е важна, но която малко хора използват, е Application Performance Monitoring.

Исках да кажа само едно нещо за мониторинга на производителността на приложенията. Кое е най-важното в тази практика? Ето какво е Наблюдението на производителността на приложението приблизително същото като ремонт на апартамент. Това не е крайно състояние, това е процес. Трябва да го правите редовно.

В добър смисъл би било добре да се извършва мониторинг на производителността на приложенията на почти всяка компилация, въпреки че, както разбирате, това не винаги е възможно. Но най-малкото трябва да се извършва за всяко издание.

Защо е важно? Защото, ако изведнъж почувствате спад в производителността, тогава трябва ясно да разберете защо. Ако вашият екип има, да речем, двуседмични спринтове, тогава поне веднъж на всеки две седмици трябва да разположите приложението си на някакъв отделен сървър, където имате ясно фиксиран процесор, RAM, дискове и т.н. И да изпълните същите тези тестове за производителност . Получавате резултата. Вижте как се е променил от предишния спринт.

И ако разберете, че усвояването е рязко намаляло някъде, това ще означава, че това се дължи на промените, настъпили през последните две седмици. Това ще ви позволи да идентифицирате и отстраните проблема много по-бързо. И отново, това са приблизително същите показатели, чрез които можете да измерите колко успешно сте го направили.

Следващата практика, която имаме, е практиката за управление на конфигурацията. Много малко са тези, които приемат това сериозно. Но повярвайте ми, това всъщност е много сериозно нещо.

Наскоро имаше една забавна история. Момчетата дойдоха при мен и казаха: „Помогнете ни да направим одит на сигурността на нашето приложение.“ Разглеждахме кода заедно дълго време, разказаха ми за приложението, начертаха диаграми. И плюс или минус всичко беше логично, разбираемо, безопасно, но имаше едно НО! Те имаха конфигурационни файлове в своя контрол на източника, включително тези от производството с IP базата данни, с потребителски имена и пароли за свързване към тези бази данни и т.н.

И аз казвам: „Момчета, добре, затворихте производствената си среда със защитна стена, но фактът, че имате данните за вход и паролата за производствената база данни точно в контролата на източника и всеки разработчик може да ги прочете, вече представлява огромен риск за сигурността . И без значение колко супер сигурно е вашето приложение от гледна точка на кода, ако го оставите в контрола на източника, никога няма да преминете одит никъде.“ За това говоря.

Управление на конфигурацията. Може да имаме различни конфигурации в различни среди. Например, може да имаме различни потребителски имена и пароли за бази данни за QA, демонстрация, производствена среда и т.н.

Тази конфигурация може да бъде и автоматизирана. Винаги трябва да е отделно от самото приложение. Защо? Тъй като сте създали приложението веднъж и след това приложението не се интересува дали се свързвате към SQL сървъра чрез такъв и такъв IP или такъв и такъв IP, то трябва да работи по същия начин. Ето защо, ако внезапно някой от вас все още твърдо кодира низа за връзка в кода, тогава не забравяйте, че ще ви намеря и ще ви накажа, ако се окажете в същия проект с мен. Това винаги се поставя в отделна конфигурация, например в web.config.

И тази конфигурация вече се управлява отделно, т.е. това е точно моментът, в който програмист и администратор могат да дойдат и да седнат в една стая. И разработчикът може да каже: „Вижте, ето двоичните файлове на моето приложение. Те работят. Приложението се нуждае от база данни, за да работи. Тук до двоичните файлове има файл. В този файл това поле отговаря за входа, това е за паролата, това е за IP. Разположете го навсякъде." И това е просто и ясно за администратора. Той може да го разположи наистина навсякъде, като управлява тази конфигурация.

И последната практика, за която бих искал да говоря, е практика, която е много, много свързана с облаците. И носи максимален ефект, ако работите в облака. Това е автоматично премахване на вашата среда.

Знам, че има няколко души на тази конференция от екипите, с които работя. И с всички екипи, с които работя, използваме тази практика.

Защо? Разбира се, би било чудесно, ако всеки разработчик има виртуална машина, която да работи 24/7. Но може би това е новина за вас, може би не сте обърнали внимание, но самият разработчик не работи 24/7. Разработчикът обикновено работи по 8 часа на ден. Дори да дойде на работа по-рано, той обядва обилно, по време на който отива на фитнес. Нека бъде 12 часа на ден, когато разработчикът действително използва тези ресурси. Според нашето законодателство имаме 5 от 7 дни в седмицата, които се считат за работни.

Съответно през делничните дни тази машина не трябва да работи 24 часа, а само 12, а през почивните дни тази машина не трябва да работи изобщо. Изглежда, че всичко е много просто, но какво е важно да кажем тук? Чрез внедряването на тази проста практика в този основен график ви позволява да намалите разходите за поддръжка на тези среди със 70%, т.е. вие сте взели цената на вашия dev, QA, demo, среда и сте я разделили на 3.

Въпросът е какво да правя с останалите пари? Например, разработчиците трябва да купят ReSharper, ако още не са го направили. Или организирайте коктейл. Ако преди това сте имали една среда, в която пасат и разработчиците, и QA, и това е, сега можете да направите 3 различни, които ще бъдат изолирани и хората няма да си пречат.

По отношение на слайда с непрекъснато измерване на производителността, как можем да сравним производителността, ако имахме 1 записа в базата данни в проекта, два месеца по-късно има милион? Как да разберем защо и какъв е смисълът от измерване на ефективността?

Това е добър въпрос, защото винаги трябва да измервате ефективността на едни и същи ресурси. Тоест, пускате нов код, измервате ефективността на новия код. Например, трябва да тествате различни сценарии на производителност, да приемем, че искате да тествате как се представя приложението при слабо натоварване, където има 1 потребители и размерът на базата данни е 000 гигабайта. Измерихте го и получихте числата. След това приемаме друг сценарий. Например 5 потребители, размер на базата данни 5 терабайт. Получихме резултатите и ги запомнихме.

Какво е важното тук? Важното тук е, че в зависимост от сценария, обема на данните, броя на едновременните потребители и т.н., може да попаднете на определени ограничения. Например до границата на мрежова карта, или до границата на твърд диск, или до границата на възможностите на процесора. Това е, което е важно да разберете. В различни сценарии се натъквате на определени ограничения. И трябва да разбирате числата, когато ги ударите.

Говорим ли за измерване на производителността в специална тестова среда? Тоест това не е производство?

Да, това не е производство, това е тестова среда, която винаги е една и съща, за да можете да я сравните с предишни измервания.

Разбрано благодаря!

Ако няма въпроси, мисля, че можем да приключим. Благодаря ти!

Източник: www.habr.com