Најбоље ДевОпс праксе за програмере. Антон Бојко (2017)

Извештај ће говорити о неким ДевОпс праксама, али са становишта програмера. Обично сви инжењери који се придруже ДевОпс-у већ имају неколико година административног искуства иза себе. Али то не значи да овде нема места за програмера. Чешће него не, програмери су заузети исправљањем „следеће хитно критичне грешке у дану“, а немају времена чак ни да погледају ДевОпс поље. У схватању аутора, ДевОпс је, пре свега, здрав разум. Друго, то је прилика да будете ефикаснији. Ако сте програмер, имате здрав разум и желите да будете ефикаснији као тимски играч, овај извештај је за вас.

Дозволите ми да се представим, у потпуности признајем да у просторији има људи који ме не познају. Моје име је Антон Бојко, ја сам Мицрософт Азуре МВП. Шта је МВП? Ово је Модел-Виев-Пресентер. Модел-Виев-Пресентер сам управо ја.

Поред тога, тренутно сам на позицији архитекте решења у Циклуму. Недавно сам себи купио тако леп домен, и ажурирао своју е-пошту, коју обично показујем на презентацијама. Можете ми писати на: ме [пас] биокоант.про. Можете ми послати е-пошту са питањима. Обично им одговарам. Једино што не бих волео да мејлом добијам питања која се односе на две теме: политику и религију. О свему осталом можете ми писати путем мејла. Проћи ће неко време, одговорићу.

Неколико речи о себи:

• Ја сам у овој области већ 10 година.
• Радио сам у Мицрософту.
• Ја сам оснивач украјинске заједнице Азуре коју смо основали негде 2014. године. И још га имамо и развијамо га.
• Такође сам и отац оснивача конференције Азуре, чији смо домаћин у Украјини.
• Такође помажем у организацији Глобал Азуре Боотцамп-а у Кијеву.
• Као што сам рекао, ја сам Мицрософт Азуре МВП.
• Прилично често говорим на конференцијама. Заиста волим да говорим на конференцијама. Током прошле године могао сам да наступим око 40 пута. Ако прођете поред Украјине, Белорусије, Пољске, Бугарске, Шведске, Данске, Холандије, Шпаније или дате или узмете неку другу државу у Европи, онда је сасвим могуће да када одете на конференцију која има тему облака у свом току, можете ме видети на листи говорника.
• Такође сам фан Звезданих стаза.

Хајде да причамо мало о дневном реду. Наш план је врло једноставан:

• Разговараћемо о томе шта је ДевОпс. Хајде да разговарамо зашто је ово важно. Раније је ДевОпс била кључна реч коју сте написали у својој биографији и одмах примили +500 долара плате. Сада морате да упишете, на пример, блокчејн у свој животопис да бисте добили +500 долара на своју плату.
• А онда, када мало схватимо шта је ово, причаћемо о томе шта су ДевОпс праксе. Али не толико у контексту ДевОпс-а уопште, већ о оним ДевОпс праксама које би могле бити од интереса за програмере. Рећи ћу вам зашто би вас могли занимати. Рећи ћу вам зашто би то уопште требало да радите и како вам то може помоћи да доживите мање болова.

Традиционална слика коју многи људи показују. То се дешава у многим пројектима. Тада имамо развојна и оперативна одељења која подржавају наш софтвер. И ова одељења не комуницирају једни са другима.

Можда, ако нисте били у стању да то тако јасно осетите у ДевОпс и оперативним одељењима, можете повући аналогију са одељењима Дев и КА. Постоје људи који развијају софтвер, а постоје људи за осигурање квалитета који су лоши са тачке гледишта програмера. На пример, предајем свој дивни код у спремиште, а тамо седи неки нитков који ми враћа овај код и каже да је ваш код лош.

Све се то дешава зато што људи не комуницирају једни са другима. И бацају неке пакете, неку апликацију једни другима кроз неки зид неспоразума и покушавају да ураде нешто са њима.

Управо тај зид је дизајниран да уништи ДевОпс култура, тј. присиљавати људе да међусобно комуницирају и барем разумеју шта различити људи у пројекту раде и зашто је њихов рад важан.

А када говоримо о ДевОпс-у, неко ће вам рећи да је ДевОпс када пројекат има континуирану интеграцију; неко ће рећи да је ДевОпс ако пројекат имплементира праксу „инфраструктура као код“; неко ће рећи да је први корак ка ДевОпс-у гранање карактеристика, ознаке функција.

У суштини, све је то тачно на свој начин. Али ово су само крајње праксе које имамо. Пре него што пређемо на ове праксе, предлажем да погледате овај слајд, који показује 3 фазе имплементације Дев-Опс методологије у вашем пројекту, у вашој компанији.

Овај слајд има и друго незванично име. Можете претраживати на мрежи да бисте сазнали шта су 3 мускетара ДевОпс-а. Могуће је да ћете пронаћи овај чланак. Зашто 3 мускетара? Испод пише: људи, процеси и производи, тј. ЈПП – Портос, Портос и Портос. Ево 3 мускетара ДевОпс-а. Овај чланак детаљније описује зашто је то важно и шта подразумева.

Када почнете да имплементирате ДевОпс културу, веома је важно да се имплементира следећим редоследом.

У почетку морате разговарати са људима. И треба да објасните људима шта је то и како могу да извуку неке користи од тога.

Наша конференција се зове ДотНет Фест. И као што су ми рекли организатори, овде смо углавном позвали публику програмера, тако да се надам да је већина људи у сали укључена у развој.

Причаћемо о људима, причаћемо о томе шта програмери желе да раде сваки дан. Шта они највише желе? Желе да напишу неки нови код, користе новонастале оквире, креирају нове функције. Шта програмери најмање желе? Поправите старе грешке. Надам се да се слажете са мном. То је оно што програмери желе. Они желе да пишу нове функције, не желе да поправљају грешке.

Број грешака које одређени програмер производи зависи од тога колико су му руке равне и колико расту из његових рамена, а не из џепова на задњици. Али ипак, када имамо велики пројекат, понекад се деси да је немогуће све пратити, па би било лепо да користимо неке приступе који ће нам помоћи да напишемо стабилнији и квалитетнији код.

Шта КА највише желе? Не знам да ли су у сали. Тешко ми је да кажем да желим КА, јер то никада нисам био. И без увреде за момке, рећи ће се да се надам да никада нећу. Али не из разлога што њихов рад сматрам бесмисленим и бескорисним, већ зато што себе не сматрам особом која би могла ефикасно да ради овај посао, па нећу ни покушавати да то урадим. Али колико сам разумео, оно што КА највише не воли је да ради ујутру, да стално ради неке врсте регресионих тестова, гази исте грешке које су пријавили програмерима пре 3 спринта и говоре: „Када ћеш , Монсиеур Д 'Артагнан, поправи ову грешку.' А господин Д'Артањан му одговара: "Да, да, да, већ сам то поправио." И како се дешава да сам једну грешку поправио и успут направио 5.

Људи који подржавају ово решење у продукцији желе да ово решење ради без грешака, тако да не морају да рестартују сервер сваког петка, када сви нормални људи иду у бар. Програмери су распоређени у петак, администратори седе до суботе, покушавајући да подесе и поправе ову имплементацију.

А када објасните људима да су они усмерени на решавање истих проблема, можете прећи на формализовање процеса. Врло је важно. Зашто? Јер када кажемо „формализација“, важно је да опишете како се ваши процеси одвијају бар негде на салвети. Морате да разумете да ако, на пример, имплементирате у КА окружење или производно окружење, онда се то увек дешава овим редоследом; у овим фазама покрећемо, на пример, аутоматске тестове јединица и УИ тестове. Након распоређивања, проверавамо да ли је распоређивање прошло добро или лоше. Али већ имате јасну листу радњи које се морају понављати изнова и изнова када их примените у производњу.

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

Нажалост, често видим да се ово дешава обрнуто. Чим неко чује реч „ДевОпс“, одмах предлажу инсталирање Џенкинса, јер верују да ће чим инсталирају Џенкинс имати ДевОпс. Инсталирали су Џенкинса, прочитали чланке „Како да“ на веб страници Џенкинса, покушали да уметну процесе у ове чланке Како да, а онда су дошли до људи и сагнули људе, говорећи да књига каже да то треба да урадите на овај начин, па то радимо на овај начин.

Није да је Џенкинс лош алат. Не мислим то ни на који начин да кажем. Али ово је само један од производа. И који производ ћете користити требало би да буде ваша последња одлука, а никако прва. Ваш производ не треба да буде вођен применом културе и приступа. Ово је веома важно разумети, због чега проводим толико времена на овом слајду и све ово толико дуго објашњавам.

Хајде да причамо о ДевОпс пракси уопште. Шта су они? Која је разлика? Како их испробати? Зашто су важни?

Прва пракса за коју сте можда чули зове се Континуирана интеграција. Можда неко на пројекту има континуирану интеграцију (ЦИ).

Највећи проблем је што најчешће када питам особу: „Да ли имате ЦИ на пројекту?“ и он каже: „Да“, онда када га питам шта ради, он ми описује апсолутно цео процес аутоматизације. Ово није сасвим тачно.

У ствари, пракса ЦИ је само усмерена на интеграцију кода који различити људи пишу у неку врсту јединствене базе кода. То је све.

Уз ЦИ, обично постоје и друге праксе на путу - као што су континуирана имплементација, управљање издањима, али о томе ћемо касније.

Сам ЦИ нам говори да различити људи пишу код и да овај код мора бити континуирано интегрисан у једну базу кода.

Шта нам ово даје и зашто је важно? Ако имамо ДотНет, онда је то добро, то је компајлирани језик, можемо да компајлирамо нашу апликацију. Ако се компајлира, онда је то већ добар знак. Ово још ништа не значи, али је први добар знак да можемо бар да компајлирамо.

Онда можемо да извршимо неке тестове, што је такође посебна пракса. Сви тестови су зелени – ово је други добар знак. Али опет, ово не значи ништа.

Али зашто би ово урадио? Све праксе о којима ћу данас говорити носе приближно исту вредност, односно приближно исте користи и такође се мере приближно на исти начин.

Прво, омогућава вам да убрзате испоруку. Како вам ово омогућава да убрзате испоруку? Када направимо неке нове промене у нашој бази кода, можемо одмах покушати да урадимо нешто са овим кодом. Не чекамо да дође четвртак јер га у четвртак објављујемо у КА окружење, радимо то управо овде и овде.

Испричаћу вам једну тужну причу из мог живота. Било је то давно, када сам још био млад и згодан. Сада сам већ млад, леп и паметан, и скроман. Пре неког времена сам био у пројекту. Имали смо велики тим од око 30 програмера. И имали смо велики, велики Ентерприсе пројекат који се развијао око 10 година. А имали смо различите филијале. У спремишту смо имали грану у којој су програмери ходали. И постојала је грана која је приказивала верзију кода која је у производњи.

Производна грана је била 3 ​​месеца иза огранка који је био доступан програмерима. Шта ово значи? То значи да чим имам грешку негде која иде у производњу грешком програмера, јер су то дозволили, и грешком КА, јер су је погледали, онда то значи да ако добијем задатак за хитну исправку за производњу, онда морам да вратим промене кода пре 3 месеца. Морам да се сетим шта сам имао пре 3 месеца и да покушам да то поправим тамо.

Ако још нисте имали ово искуство, можете га испробати на свом кућном пројекту. Главна ствар је, не покушавајте то на комерцијалном. Напишите неколико редова кода, заборавите на њих шест месеци, а затим се вратите и покушајте брзо да објасните о чему се ради у тим линијама кода и како можете да их поправите или оптимизујете. То је веома, веома узбудљиво искуство.

Ако имамо праксу континуалне интеграције, то нам омогућава да то проверимо са бројним аутоматизованим алатима управо овде и сада, чим напишем свој код. Ово ми можда неће дати потпуну слику, али ће ипак уклонити барем неке од ризика. А ако постоји нека потенцијална грешка, знаћу за њу одмах, односно буквално за пар минута. Нећу морати да враћам 3 месеца уназад. Требаће ми само да вратим 2 минута уназад. Добар апарат за кафу неће имати времена ни да скува кафу за 2 минута, тако да је то прилично кул.

Ово има вредност да се може понављати сваки пут на сваком пројекту, тј. не само онај на који сте га поставили. Можете поновити и саму праксу и сам ЦИ ће се понављати за сваку нову промену коју направите на пројекту. Ово вам омогућава да оптимизујете ресурсе јер ваш тим ради ефикасније. Више нећете имати ситуацију да вам дође грешка из кода са којим сте радили пре 3 месеца. Више нећете имати промену контекста када седите и проведете прва два сата покушавајући да разумете шта се тада догодило и уђете у суштину контекста пре него што почнете да исправљате нешто.

Како можемо измерити успех или неуспех ове праксе? Ако пријавите великом шефу шта смо имплементирали на ЦИ пројекту, он чује бла бла бла. Ми смо то имплементирали, у реду, али зашто, шта нам је то донело, како то меримо, колико исправно или нетачно спроводимо?

Први је да, захваљујући ЦИ, можемо све чешће да примењујемо, а све чешће управо зато што је наш код потенцијално стабилнији. На исти начин, наше време за проналажење грешке је смањено и време за исправљање ове грешке је смањено управо из разлога што добијамо одговор од система управо овде и одмах, шта није у реду са нашим кодом.

Друга пракса коју имамо је пракса Аутоматско тестирање, која најчешће долази са праксом ЦИ. Они иду руку под руку.

Шта је овде важно разумети? Важно је разумети да се наши тестови разликују. И сваки аутоматизовани тест има за циљ решавање сопствених проблема. Имамо, на пример, јединичне тестове који нам омогућавају да одвојено тестирамо модул, тј. Како то функционише у вакууму? Ово је добро.

Такође имамо интеграцијске тестове који нам омогућавају да разумемо како се различити модули интегришу један са другим. Такође је добро.

Можда имамо тестове аутоматизације корисничког интерфејса који нам омогућавају да проверимо колико добро рад са корисничким интерфејсом испуњава одређене захтеве које поставља купац, итд.

Специфични тестови које покрећете могу утицати на то колико често их изводите. Јединични тестови се обично пишу кратки и мали. И могу се редовно лансирати.

Ако говоримо о тестовима аутоматизације корисничког интерфејса, онда је добро ако је ваш пројекат мали. Тестови аутоматизације корисничког интерфејса могу потрајати неко време. Али обично је тест аутоматизације корисничког интерфејса нешто што траје неколико сати на великом пројекту. И добро је ако је неколико сати. Једина ствар је да нема смисла да их покрећете за сваку градњу. Има смисла водити их ноћу. А када су сви ујутро дошли на посао: и тестери и програмери, добили су неку врсту извештаја да смо ноћу покренули аутотест корисничког интерфејса и добили ове резултате. А ево, сат рада сервера који ће проверити да ли ваш производ испуњава неке захтеве биће много јефтинији од сата рада истог КА инжењера, чак и ако је Јуниор КА инжењер који ради за храну и хвала. Свеједно, сат рада машине ће бити јефтинији. Због тога има смисла улагати у то.

Имам још један пројекат на којем сам радио. Имали смо двонедељне спринтове на овом пројекту. Пројекат је био велики, важан за финансијски сектор и није се могла направити грешка. И након двонедељног спринта, циклус развоја је праћен процесом тестирања, који је трајао још 4 недеље. Покушајте да замислите размере трагедије. Две недеље пишемо код, а онда то радимо ала ЦодеФреезе, упакујемо га у нову верзију апликације и пуштамо тестерима. Тестери га тестирају још 4 недеље, тј. Док они то тестирају, имамо времена да им припремимо још две верзије. Ово је заиста тужан случај.

И рекли смо им да ако желите да будете продуктивнији, има смисла да примените аутоматизовано тестирање, јер вас то боли управо овде, управо сада.

Вежбајте континуирано распоређивање. Одлично, завршили сте. Ово је већ добро. Ваш код је компајлиран. Сада би било лепо применити ову верзију на неком окружењу. Рецимо у окружењу за програмере.

Зашто је важно? Прво, можете погледати колико сте успешни у самом процесу постављања. Упознао сам овакве пројекте, када питам: „Како да имплементирате нову верзију апликације?“, момци ми кажу: „Састављамо је и спакујемо у зип архиву. Шаљемо га администратору поштом. Администратор преузима и проширује ову архиву. И цела канцеларија почиње да се моли да сервер преузме нову верзију.”

Почнимо са нечим једноставним. На пример, заборавили су да ставе ЦСС у архиву или су заборавили да промене хасхтаг у називу јава-сцрипт датотеке. А када упутимо захтев серверу, претраживач мисли да већ има ову јава-сцрипт датотеку и одлучује да је не преузима. И постојала је стара верзија, нешто је недостајало. Генерално, може бити много проблема. Стога вам пракса континуиране имплементације омогућава да барем тестирате шта би се десило ако бисте узели чисту референтну слику и отпремили је у потпуно чисто ново окружење. Можете видети куда ово води.

Такође, када интегришете међусобне кодове, тј. између команде, ово вам такође омогућава да видите како то изгледа на корисничком интерфејсу.

Један од проблема који се јавља када се користи много ванилла јава-сцрипт-а је тај што су два програмера нагло прогласила променљиву са истим именом у објекту прозора. А онда, у зависности од ваше среће. Чија јава-сцрипт датотека је извучена друга ће преписати измене друге. Такође је веома узбудљиво. Улазите: једна ствар ради за једну особу, друга не ради за другу. И то је „сјајно“ када се све појави у производњи.

Следећа пракса коју имамо је пракса аутоматског враћања у претходно стање, односно враћање на претходну верзију апликације.

Зашто је ово важно за програмере? Још увек има оних који се сећају далеких, далеких 90-их, када су рачунари били велики, а програми мали. А једини начин за развој веба био је преко ПХП-а. Није да је ПХП лош језик, иако јесте.

Али проблем је био другачији. Када смо поставили нову верзију нашег пхп сајта, како смо је применили? Најчешће смо отварали Фар Манагер или нешто друго. И отпремио ове датотеке на ФТП. И одједном смо схватили да имамо неку малу, малу грешку, на пример, заборавили смо да ставимо тачку и зарез или смо заборавили да променимо лозинку за базу података, а постоји лозинка за базу података, која је на локалном хосту. И ми одлучујемо да се брзо повежемо на ФТП и уређујемо датотеке управо тамо. Ово је само ватра! То је оно што је било популарно 90-их.

Али, ако нисте погледали календар, 90-те су биле пре скоро 30 година. Сада се све дешава мало другачије. И покушајте да замислите размере трагедије када вам кажу: „Покренули смо се у производњу, али тамо је нешто пошло по злу. Ево вашег ФТП корисничког имена и лозинке, повежите се са производњом и брзо то поправите тамо." Ако сте Цхуцк Норрис, ово ће радити. Ако не, онда ризикујете да ћете ако поправите једну грешку направити још 10. Управо због тога ова пракса враћања на претходну верзију вам омогућава да постигнете много.

Чак и ако је нешто лоше некако ушло у прод негде, онда је лоше, али није фатално. Можете се вратити на претходну верзију коју имате. Назовите то резервном, ако је то лакше схватити у тој терминологији. Можете да се вратите на ову претходну верзију, а корисници ће и даље моћи да раде са вашим производом, а ви ћете имати одговарајуће време бафера. Можете мирно, без журбе, све ово узети и тестирати локално, поправити, а затим поставити нову верзију. Заиста има смисла ово урадити.

Покушајмо сада некако да спојимо две претходне праксе заједно. Добићемо трећи који се зове Управљање издањима.

Када говоримо о континуираној имплементацији у њеном класичном облику, кажемо да морамо извући код из неке гране из спремишта, компајлирати га и имплементирати. Добро је ако имамо исто окружење. Ако имамо неколико окружења, то значи да морамо сваки пут да извлачимо код, чак и из истог урезивања. Сваки пут ћемо га извлачити, сваки пут ћемо га градити и постављаћемо га у ново окружење. Прво, ово је време, јер за изградњу пројекта, ако имате велики и долазите из 90-их, може потрајати неколико сати.

Осим тога, постоји још једна туга. Када градите, чак и на истој машини, изградићете исте изворе, још увек немате гаранцију да је ова машина у истом стању као што је била током последње израде.

Рецимо да је неко дошао и ажурирао ДотНет уместо вас или је, обрнуто, неко одлучио да избрише нешто. И онда имате когнитивну дисонанцу да смо од овог урезивања пре две недеље правили буилд и све је било у реду, али сада изгледа као иста машина, исти урезивање, исти код који покушавамо да направимо, али не ради . Дуго ћете се бавити овим и није чињеница да ћете то схватити. У најмању руку, много ћете покварити своје живце.

Стога пракса управљања издањима предлаже увођење додатне апстракције која се зове складиште артефаката или галерија или библиотека. Можете то назвати како год желите.

Основна идеја је да чим имамо неку врсту урезивања тамо, рецимо, у грани коју смо спремни да распоредимо у наша различита окружења, сакупимо апликације из овог урезивања и све што нам је потребно за ову апликацију, ми то спакујемо у зип архиву и сачувајте је у неком поузданом складишту. И из овог складишта можемо добити ову зип архиву у било ком тренутку.

Затим га узимамо и аутоматски га постављамо у окружење за развој. Тркамо се тамо, и ако је све добро, онда се распоређујемо на сцену. Ако је све у реду, онда постављамо исту архиву у продукцију, исте бинарне датотеке, компајлиране тачно једном.

Поред тога, када имамо овакву галерију, то нам такође помаже да решимо ризике о којима смо говорили на последњем слајду када смо говорили о враћању на претходну верзију. Ако сте случајно применили нешто погрешно, увек можете узети било коју другу претходну верзију из ове галерије и на исти начин је поништити у овим окружењима. Ово вам омогућава да се лако вратите на претходну верзију ако нешто крене наопако.

Постоји још једна сјајна пракса. Сви ви и ја разумемо да када враћамо наше апликације на претходну верзију, то може значити да нам је потребна и инфраструктура претходне верзије.

Када говоримо о виртуелној инфраструктури, многи мисле да је то нешто што администратори постављају. А ако вам је потребно, рецимо, да добијете нови сервер на коме желите да тестирате нову верзију своје апликације, онда морате да напишете тикет администраторима или девопс-у. Девопс-у ће бити потребно 3 недеље за ово. А после 3 недеље ће вам рећи да смо за вас инсталирали виртуелну машину, са једним језгром, два гигабајта РАМ-а и Виндовс сервером без ДотНет-а. Кажете: „Али желео сам ДотНет.“ Они: „У реду, врати се за 3 недеље.“

Идеја је да коришћењем инфраструктуре као праксе кода, своју виртуелну инфраструктуру можете третирати као само још један ресурс.

Можда, ако неко од вас развија апликације на ДотНет-у, можда сте чули за библиотеку под називом Ентити Фрамеворк. Можда сте чак чули да је Ентити Фрамеворк један од приступа које Мицрософт активно гура. За рад са базом података, ово је приступ који се зове Цоде Фирст. Ово је када у коду опишете како желите да ваша база података изгледа. А онда примените апликацију. Повезује се са базом података, сам одређује које табеле постоје, а које не, и креира све што вам треба.

Исто можете учинити са својом инфраструктуром. Не постоји разлика између тога да ли вам је потребна база података за пројекат или да ли вам је потребан Виндовс сервер за пројекат. То је само ресурс. И можете аутоматизовати креирање овог ресурса, можете аутоматизовати конфигурацију овог ресурса. Сходно томе, сваки пут када желите да тестирате неки нови концепт, неки нови приступ, нећете морати да пишете тикет за девопс, можете једноставно да поставите изоловану инфраструктуру за себе из готових шаблона, из готових скрипти и имплементирате је ту су сви ваши експерименти. Можете да избришете ово, добијете неке резултате и о томе даље извештавате.

Следећа пракса, која такође постоји и такође је важна, али коју мало ко користи је Мониторинг перформанси апликације.

Хтео сам да кажем само једну ствар о праћењу перформанси апликације. Шта је најважније у овој пракси? Ово је оно што је праћење перформанси апликација отприлике исто као и поправка стана. Ово није коначно стање, то је процес. Морате то радити редовно.

На добар начин, било би добро спровести праћење перформанси апликације на скоро свакој верзији, иако, као што разумете, то није увек могуће. Али, у најмању руку, то треба да се спроведе за свако издање.

Зашто је важно? Јер ако изненада доживите пад перформанси, онда морате јасно разумети зашто. Ако ваш тим има, рецимо, двонедељне спринтове, онда би бар једном у две недеље требало да распоредите своју апликацију на неки посебан сервер, где имате јасно фиксиран процесор, РАМ, дискове итд. И покрените те исте тестове перформанси . Добићете резултат. Погледајте како се променио у односу на претходни спринт.

А ако сазнате да је пад негде нагло опао, то ће значити да је то само због промена које су се десиле у протекле две недеље. Ово ће вам омогућити да идентификујете и решите проблем много брже. И опет, ово су отприлике исте метрике помоћу којих можете мерити колико сте успешно то урадили.

Следећа пракса коју имамо је пракса управљања конфигурацијом. Мало је оних који ово схватају озбиљно. Али верујте ми, ово је заправо веома озбиљна ствар.

Недавно је била смешна прича. Момци су дошли код мене и рекли: „Помозите нам да извршимо безбедносну ревизију наше апликације. Дуго смо заједно гледали код, причали су ми о апликацији, цртали дијаграме. И плус-минус све је било логично, разумљиво, сигурно, али постојало је једно АЛИ! Имали су конфигурационе датотеке у својој изворној контроли, укључујући оне из производње са ИП базом података, са логиновима и лозинкама за повезивање са овим базама података, итд.

И ја кажем: „Момци, у реду, затворили сте своје производно окружење заштитним зидом, али чињеница да имате логин и лозинку за производну базу података директно у контроли извора и сваки програмер може да је прочита већ представља огроман безбедносни ризик . И без обзира колико је ваша апликација супер безбедна са тачке гледишта кода, ако је оставите у контроли извора, никада нигде нећете проћи никакву ревизију.” О томе причам.

Управљање конфигурацијом. Можемо имати различите конфигурације у различитим окружењима. На пример, можемо имати различите логин и лозинке за базе података за КА, демо, производно окружење, итд.

Ова конфигурација се такође може аутоматизовати. Увек треба да буде одвојен од саме апликације. Зашто? Пошто сте једном направили апликацију, а онда апликацији није важно да ли се повезујете са СКЛ сервером преко те и такве ИП или такве и такве ИП адресе, требало би да ради исто. Стога, ако изненада неко од вас и даље чврсто кодира низ везе у коду, запамтите да ћу вас пронаћи и казнити ако се нађете на истом пројекту са мном. Ово се увек ставља у посебну конфигурацију, на пример, у веб.цонфиг.

И овом конфигурацијом се већ управља одвојено, односно управо је то тренутак када програмер и администратор могу да дођу и седе у истој просторији. А програмер може рећи: „Види, ево бинарних датотека моје апликације. Они раде. Апликацији је потребна база података да би радила. Овде поред бинарних датотека налази се фајл. У овој датотеци, ово поље је одговорно за пријаву, ово је за лозинку, ово је за ИП. Распоредите га било где." И то је једноставно и јасно администратору. Он може да га примени било где управљајући овом конфигурацијом.

И последња пракса о којој бих желео да говорим је пракса која је веома, веома повезана са облацима. И доноси максималан ефекат ако радите у облаку. Ово је Аутоматско уклањање вашег окружења.

Знам да је на овој конференцији неколико људи из тимова са којима радим. И са свим тимовима са којима радим користимо ову праксу.

Зашто? Наравно, било би сјајно када би сваки програмер имао виртуелну машину која би радила 24/7. Али можда је ово новост за вас, можда нисте обратили пажњу, али сам програмер не ради 24/7. Програмер обично ради 8 сати дневно. Чак и ако рано дође на посао, има велики ручак током којег иде у теретану. Нека програмер заиста користи ове ресурсе 12 сати дневно. Према нашем законодавству, имамо 5 од 7 дана у недељи који се сматрају радним данима.

Сходно томе, радним данима ова машина не би требало да ради 24 сата, већ само 12, а викендом ова машина не би требало да ради уопште. Чини се да је све врло једноставно, али шта је овде важно рећи? Применом ове једноставне праксе на овом основном распореду, она вам омогућава да смањите трошкове одржавања ових окружења за 70%, тј. узели сте цену вашег дев, КА, демо, окружења и поделили је са 3.

Питање је шта радити са остатком новца? На пример, програмери би требало да купе РеСхарпер ако већ нису. Или направите коктел забаву. Ако сте раније имали једно окружење у којем су се налазили и дев и КА, и то је то, сада можете направити 3 различита која ће бити изолована и људи се неће мешати једни у друге.

Што се тиче слајда са континуираним мерењем перформанси, како да упоредимо перформансе ако смо имали 1 записа у бази података у пројекту, а два месеца касније их има милион? Како разумети зашто и која је сврха мерења учинка?

Ово је добро питање, јер увек треба да мерите учинак на истим ресурсима. То јест, уводите нови код, мерите перформансе на новом коду. На пример, потребно је да тестирате различите сценарије перформанси, рецимо да желите да тестирате како апликација ради на малом оптерећењу, где има 1 корисника и величина базе података је 000 гигабајта. Измерили сте и добили бројеве. Затим узимамо други сценарио. На пример, 5 корисника, величина базе података 5 терабајт. Добили смо резултате и запамтили их.

Шта је овде важно? Овде је важно да у зависности од сценарија, количине података, броја истовремених корисника итд., можете наићи на одређена ограничења. На пример, до границе мрежне картице, или до границе чврстог диска, или до границе могућности процесора. То је оно што је важно да разумете. У различитим сценаријима наилазите на одређене границе. И морате да разумете бројеве када их погодите.

Да ли говоримо о мерењу перформанси у посебном тест окружењу? То јест, ово није производња?

Да, ово није производња, ово је тестно окружење, које је увек исто тако да можете да га упоредите са претходним мерењима.

Разумео хвала!

Ако нема питања, мислим да можемо да завршимо. Хвала вам!

Извор: ввв.хабр.цом