Ако ваша компанија управо уводи ДевОпс или ЦИ/ЦД алате, можда ће вам бити корисно да се упознате са најчешћим грешкама како их не бисте поновили и не згазили туђе грабље.
Тим превео чланак .
Неспремност за промену културе и процеса
Ако погледате циклични дијаграм , јасно је да је у ДевОпс праксама тестирање континуирана активност, фундаментални део сваке појединачне примене.
ДевОпс графикон бесконачног циклуса
Тестирање и осигурање квалитета током развоја и испоруке су суштински део свега што програмери раде. Ово захтева промену начина размишљања да би се тестирање укључило у сваки задатак.
Тестирање постаје део свакодневног рада сваког члана тима. Прелазак на стално тестирање није лак, морате бити спремни за то.
Недостатак повратних информација
Ефикасност ДевОпс-а зависи од сталних повратних информација. Континуирано усавршавање је немогуће ако нема простора за сарадњу и комуникацију.
Компаније које не организују ретроспективне састанке тешко имплементирају културу континуираних повратних информација у ЦИ/ЦД. Ретроспективни састанци се одржавају на крају сваке итерације, током којих чланови тима разговарају о томе шта је прошло добро, а шта лоше. Ретроспективни састанци су основа Сцрум/Агиле-а, али су такође неопходни за ДевОпс.
То је зато што ретроспективни састанци усађују навику размене повратних информација и мишљења. Једна од најважнијих тачака на почетку је организовање понављајућих ретро састанака како би постали разумљиви и познати целом тиму.
Када је у питању квалитет софтвера, сви чланови тима су одговорни за његово одржавање. На пример, програмери могу писати јединичне тестове и такође писати код имајући на уму могућност тестирања, помажући да се смањи ризик од самог почетка.
Један једноставан начин да се одрази промена у размишљању о тестирању је да се тестери позову не КА, већ софтверски тестер или инжењер квалитета. Ова промена може изгледати превише једноставна или чак глупа. Али називање некога „особом за осигурање квалитета софтвера“ даје погрешну идеју о томе ко је одговоран за квалитет производа. У пракси Агиле, ЦИ/ЦД и ДевОпс, свако је одговоран за квалитет софтвера.
Још једна важна ствар је разумети шта квалитет значи за цео тим и сваког његовог члана, организацију и заинтересоване стране.
Неразумевање завршетка фазе
Ако је квалитет континуиран и општи процес, потребно је заједничко разумевање завршетка фазе. Како знате када је фаза готова? Шта се дешава када је корак означен као завршен на Трелло или другој Канбан табли?
Дефиниција готовог (ДоД) је моћан алат у контексту ЦД ДевОпс/ЦИ. Помаже да се боље разумеју стандарди квалитета онога што и како тим гради.
Развојни тим мора одлучити шта значи "Готово". Они треба да седну и направе листу карактеристика које морају бити испуњене у свакој фази да би се она сматрала потпуном.
ДоД чини процес транспарентнијим и олакшава имплементацију ЦИ/ЦД-а ако га разумеју сви чланови тима и ако се међусобно слажу.
Недостатак реалних, јасно дефинисаних циљева
Ово је један од најчешће цитираних савета, али вреди поновити. Да бисте успели у било ком већем подухвату, укључујући ЦИ/ЦД или ДевОпс, морате да поставите реалне циљеве и мерите учинак у односу на њих. Шта покушавате да постигнете са ЦИ/ЦД? Да ли ово омогућава бржа издања са бољим квалитетом?
Сви постављени циљеви морају бити не само транспарентни и реални, већ и у складу са тренутним активностима компаније. На пример, колико често вашим клијентима требају нове закрпе или верзије? Нема потребе за преоптерећењем процеса и бржим ослобађањем ако нема додатне користи за кориснике.
Поред тога, не морате увек да имплементирате и ЦД и ЦИ. На пример, високо регулисане компаније као што су банке и медицинске клинике могу да раде само са ЦИ.
ЦИ служи као добра полазна тачка за сваку компанију која имплементира ДевОпс. Када се имплементира, приступи компанија испоруци софтвера се значајно мењају. Када савладате ЦИ, можете размишљати о побољшању целог процеса, повећању брзине увођења и другим променама.
За многе организације довољан је само ЦИ, а ЦД би требало применити само ако додаје вредност.
Недостатак одговарајућих контролних табли и метрика
Када поставите своје циљеве, развојни тим може да направи контролну таблу за мерење КПИ-ја. Пре његовог развоја, вреди проценити параметре који ће се пратити.
Различити извештаји и апликације су корисни за различите чланове тима. Сцрум Мастер је више заинтересован за статус и досег. Док виши менаџмент може бити заинтересован за стопу сагоревања специјалиста.
Неки тимови такође користе контролне табле са црвеним, жутим и зеленим индикаторима за процену статуса ЦИ/ЦД-а да би разумели да ли све раде како треба или постоји грешка. Црвена значи да морате обратити пажњу на оно што се дешава.
Међутим, ако контролне табле нису стандардизоване, могу да доведу у заблуду. Анализирајте који подаци су свима потребни, а затим направите стандардизовани опис онога што они значе. Сазнајте шта има више смисла за заинтересоване стране: графика, текст или бројеви.
Нема ручних тестова
Аутоматизација тестирања поставља основу за добар ЦИ/ЦД цевовод. Али аутоматизовано тестирање у свим фазама не значи да не треба да спроводите ручно тестирање.
Да бисте изградили ефикасан ЦИ/ЦД цевовод, потребни су вам и ручни тестови. Увек ће постојати неки аспекти тестирања који захтевају анализу људи.
Вреди размислити о интеграцији покушаја ручног тестирања у ваш цевовод. Када се заврши ручно тестирање неких тест случајева, можете прећи на фазу примене.
Не покушавајте да побољшате тестове
Ефикасан ЦИ/ЦД цевовод захтева приступ правим алатима, било да се ради о управљању тестовима или интеграцији и сталном праћењу.
Стварање јаке културе оријентисане на квалитет има за циљ , праћење интеракција корисника након имплементације и праћење побољшања.
Ево неколико практичних савета које можете лако применити:
- Уверите се да су ваши тестови лаки за писање и довољно флексибилни да се не покваре када рефакторишете код.
- Развојни тимови треба да буду укључени у процес тестирања – погледајте листу корисничких проблема и захтева које је важно тестирати током ЦИ цевовода.
- Можда немате потпуну покривеност тестом, али увек осигурајте да се тестирају токови који су важни за УКС и корисничко искуство.
Последња, али не и најмање важна тачка
Прелазак на ЦИ/ЦД обично се покреће одоздо према горе, али на крају је то трансформација која захтева учешће лидера, време и ресурсе компаније. На крају крајева, ЦИ/ЦД је скуп вештина, процеса, алата и културног реструктурирања; такве промене се могу применити само систематски.
Шта још читати на тему:
- .
- .
- .
Извор: ввв.хабр.цом