Водич за континуирану испоруку - Изградња цевовода за континуирану испоруку помоћу Јенкинса

Континуирана испорука:

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

• Шта је континуирана испорука?
• Врсте тестирања софтвера
• Разлика између континуиране интеграције, испоруке и примене
• Шта је потребно за континуирану испоруку?
• Практично коришћење Јенкинса и Томцата

Дозволите нам да брзо схватимо како функционише континуирана испорука.

Шта је континуирана испорука?

То је процес у којем градите софтвер на такав начин да се у сваком тренутку може пустити у производњу.Размотрите доњи дијаграм:

Дозволите ми да објасним горњи дијаграм:

• Аутоматизоване скрипте за изградњу откриће промене у управљању изворним кодом (СЦМ), попут Гита.
• Једном када се открије промена, изворни код ће се применити на наменски сервер за изградњу како би се осигурало да градња не успева и да ли све класе тестова и тестови интеграције раде у реду.
• Затим се апликација за изградњу поставља на тест сервере (претпродукцијски сервери) за тест корисничког прихватања (УАТ).
• Коначно, апликација се ручно поставља на производне сервере ради објављивања.

Пре него што наставим, биће поштено објаснити вам различите врсте тестирања.

Врсте тестирања софтвера:

Уопштено говорећи, постоје две врсте тестирања:

• Блацкбок тестирање: То је техника испитивања која занемарује унутрашњи механизам система и фокусира се на излаз који се генерише у односу на било који улаз и извршење система. Такође се назива функционално испитивање. У основи се користи за валидацију софтвера.
• Вхитебок тестирање: је техника испитивања која узима у обзир унутрашњи механизам система. Такође се назива испитивање конструкција и испитивање стаклених кутија. У основи се користи за верификацију софтвера.

Вхитебок тестирање:

Постоје две врсте тестирања које спадају у ову категорију.

• Јединствено тестирање: То је испитивање појединачне јединице или групе сродних јединица. Програмер то често ради како би тестирао да јединица коју је применио даје очекивани излаз у односу на дати улаз.
• Интеграционо тестирање: То је врста испитивања у којој је група компоненатакомбиновано за производњу резултата. Такође, интеракција између софтвера и хардвера се тестира ако софтвер и хардверске компоненте имају било какве везе. Може се подвргнути и тестирању беле кутије и црне кутије.

Блацкбок тестирање:

Постоји више тестова који спадају у ову категорију. Усредсредићу се нанеколико, које је важно да знате како бисте разумели овај блог:

• Испитивање функционалности / прихватања: Осигурава да наведена функционалност потребна у системским захтевима ради. То се ради како би се осигурало да испоручени производ испуњава захтеве и да ради онако како је купац очекивао
• Тестирање система: Осигурава да стављањем софтвера у различита окружења (нпр. Оперативни системи) и даље ради.
• Испитивање напрезања: Процењује се како се систем понаша под неповољним условима.
• Бета тестирање: То раде крајњи корисници, тим који није у развоју или јавно објављује потпуну верзију производа која је позната каобетаверзија. Циљ бета тестирања је да покрије неочекиване грешке.

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

Разлике између континуиране интеграције, испоруке и примене:

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

У континуираној интеграцији, свако урезивање кода се гради и тестира, али није у стању да буде објављено. Мислим, апликација за изградњу не поставља се аутоматски на тест сервере да би је проверила ваљаношћу користећи различите типове Блацкбок тестирања попут - Усер Аццептанце Тестинг (УАТ).

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

Континуирано постављање је следећи корак поред Континуиране испоруке, где не само да креирате пакет који се може применити, већ га заправо аутоматизујете.

Дозволите ми да сумирам разлике користећи табелу:

Једноставно речено, континуирана интеграција је део континуиране испоруке и континуиране примене. А континуирано постављање је попут континуиране испоруке, осим што се издања дешавају аутоматски.

Научите како да направите ЦИ / ЦД цевоводе користећи Јенкинс Он Цлоуд

Али питање је да ли је довољна континуирана интеграција.

Зашто нам је потребна континуирана испорука?

Разумимо ово на примеру.

Замислите да 80 програмера ради на великом пројекту. Користе цевоводе континуиране интеграције како би олакшали аутоматизоване израде. Знамо да буилд укључује и јединствено тестирање. Једног дана одлучили су да примене најновију верзију која је прошла јединствене тестове у тест окружење.

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

Шта би могао бити очигледни узрок неуспеха?

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

Један перцептивни програмер је приступио паметно:

Тада је један од старијих програмера испробао апликацију на својој развојној машини. Ни тамо није успело.

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

Изјава о проблему:

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

Дозволите ми да резимирам научене лекције гледајући горе наведене проблеме:

• Јединствени тестови само тестирају перспективу програмера за решење проблема. Имају само ограничену способност да докажу да апликација ради оно што треба из перспективе корисника. Нису довољни запрепознати стварне функционалне проблеме.
• Примена апликације у тест окружењу је сложен, ручно интензиван процес који је био прилично склон грешкама.То је значило да је сваки покушај примене био нови експеримент - ручни процес, склон грешкама.

Решење - Цевовод за континуирану испоруку (Аутоматски тест прихватања):

Предузели су континуирану интеграцију (континуирана испорука) до следећег корака и увели неколико једноставних, аутоматизованих тестова прихватања који су доказали да је апликација радила и да може да изврши своју најосновнију функцију.Већина тестова који се изводе током фазе теста прихватљивости су тестови функционалне прихватљивости.

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

Доста теорије, сада ћу вам показати како да направите цевовод континуиране испоруке користећи Јенкинс.

Цевовод за континуирану испоруку помоћу Јенкинса:

Овде ћу користити Јенкинс за стварање цевовода за континуирану испоруку, који ће укључивати следеће задатке:

Кораци укључени у демонстрацију:

• Преузимање кода са ГитХуб-а
• Компајлирање изворног кода
• Јединствено тестирање и генерисање извештаја о тестирању ЈУнит
• Паковање апликације у ВАР датотеку и њено постављање на Томцат сервер

Предуслови:

• Машина ЦентОС 7
• Јенкинс 2.121.1
• Доцкер
• Томцат 7

Корак - 1 Састављање изворног кода:

Почнимо са стварањем пројекта Фреестиле у Јенкинс-у. Размотрите доњи снимак екрана:

факторијел користећи рекурзију у в

Дајте име свом пројекту и одаберите Фреестиле Пројецт:

Када се померите надоле, пронаћи ћете опцију за додавање спремишта изворног кода, одабир гит-а и додавање УРЛ-а спремишта, у том спремишту налази се пом.кмл фине који ћемо користити за изградњу нашег пројекта. Размотрите доњи снимак екрана:

Сада ћемо додати Буилд Триггер. Изаберите опцију СЦМ за анкету. У основи, ми ћемо конфигурисати Јенкинс-а да анкетира ГитХуб спремиште након сваких 5 минута ради промена у коду. Размотрите доњи снимак екрана:

Пре него што наставим, даћу вам мали увод у Мавен Буилд Цицле.

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

Следи списак фаза израде:

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

Могу да покренем доњу команду за састављање изворног кода, јединствено тестирање, па чак и паковање апликације у ратну датотеку:

мвн чист пакет

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

Па ћемо започети са састављањем изворног кода. На картици израде кликните на позивање мавен циљева највишег нивоа и откуцајте доњу команду:

саставити

Размотрите доњи снимак екрана:

Ово ће повући изворни код из ГитХуб спремишта и такође ће га компајлирати (Мавен Цомпиле Пхасе).

Кликните на Сачувај и покрените пројекат.

Сада кликните на излаз конзоле да бисте видели резултат.

Корак - 2 Јединствено тестирање:

Сада ћемо створити још један пројекат Фреестиле за јединствено тестирање.

Додајте исти УРЛ спремишта на картицу за управљање изворним кодом, као што смо то урадили у претходном послу.

Сада, на картици „Буид Триггер“ кликните на „буилд афтер отхер пројецтс аре буилт“. Тамо откуцајте име претходног пројекта где компајлирамо изворни код и можете одабрати било коју од следећих опција:

• Окидач само ако је изградња стабилна
• Окидач чак и ако је израда нестабилна
• Окидач чак и ако изградња не успе

Мислим да су горње опције прилично саме по себи разумљиве, па одаберите било коју. Размотрите доњи снимак екрана:

На картици Буилд кликните на позивање мавен циљева највишег нивоа и користите наредбу у наставку:

тест

Јенкинс такође сјајно ради помажући вам да прикажете резултате теста и трендове резултата испитивања.

Де фацто стандард за извештавање о тестовима у свету Јаве је КСМЛ формат који користи ЈУнит. Овај формат користе и многи други Јава алати за тестирање, као што су ТестНГ, Споцк и Еасиб. Јенкинс разуме овај формат, па ако ваша верзија даје ЈУнит КСМЛ резултате теста, Јенкинс може временом да генерише лепе графичке извештаје о тестовима и статистику о резултатима теста, а такође вам омогућава да видите детаље свих неуспеха на тесту. Јенкинс такође бележи колико дуго трају ваши тестови, како глобално, тако и по тесту - ово може добро доћи ако требате да пронађете проблеме са перформансама.

Дакле, следећа ствар коју треба да урадимо је да наговоримо Јенкинса да прати наше јединице тестове.

Идите на одељак Пост-буилд Ацтионс и означите поље за потврду „Објави извештај о резултату теста ЈУнит“. Када Мавен покрене јединствене тестове у пројекту, он аутоматски генерише КСМЛ извештаје о тестирању у директоријуму који се назива сурефире-репортс. Дакле, унесите „** / таргет / сурефире-репортс / *. Ксмл“ у поље „КСМЛ-ови извештаја о тестирању“. Две звјездице на почетку путање („**“) најбоља су пракса да конфигурацију учините мало робуснијом: омогућавају Јенкинсу да пронађе циљни директоријум без обзира на то како смо конфигурисали Јенкинса да провери изворни код.

** / таргет / сурефире-репортс / *. кмл

Поново га сачувајте и кликните на Буилд Нов.

Сада је извештај ЈУнит написан на / вар / либ / јенкинс / воркспаце / тест / гамеофлифе-цоре / таргет / сурефире-репортс / ТЕСТ-бехавиоур.

На Џенкинсовој контролној таблитакође можете приметити резултате теста:

Корак - 3 Стварање ВАР датотеке и постављање на Томцат сервер:

Сада је следећи корак паковање наше апликације у ВАР датотеку и њено постављање на Томцат сервер за тест корисничког прихватања.

Направите још један пројекат слободног стила и додајте УРЛ спремишта изворног кода.

Затим на картици окидача за изградњу изаберите изградњу када се граде други пројекти, размотрите доњи снимак екрана:

У основи, након пробног задатка, фаза примене започиње аутоматски.

На картици буилд изаберите скрипту љуске. Откуцајте доњу наредбу да бисте апликацију спаковали у ВАР датотеку:

мвн пакет

Следећи корак је размештање ове ВАР датотеке у Томцатсервер. На картици „Пост-Буилд Ацтионс“ одаберите имплементацију вар / еар у контејнер. Овде дајте путању до ратне датотеке и наведите путању контекста. Размотрите доњи снимак екрана:

Изаберите акредитиве Томцат и приметите горњи снимак екрана. Такође, треба да наведете УРЛ свог Томцат сервера.

Да бисте додали акредитиве у Јенкинс, кликните на опцију акредитиви на Јенкинс контролној табли.

Кликните на Систем и изаберите глобалне акредитиве.

Тада ћете пронаћи опцију за додавање акредитива. Кликните на њега и додајте акредитиве.

Додајте поверљиве податке за Томцат, размотрите доњи снимак екрана.

Кликните на ОК.

допуштају вам методе класе скенера

Сада у своју Конфигурацију пројекта додајте томцат акредитиве који сте убацили у претходном кораку.

Кликните на Саве, а затим изаберите Буилд Нов.

Идите на своју УРЛ адресу томцат, са путањом контекста, у мом случају то је хттп: // лоцалхост: 8081. Сада додајте путању контекста на крају, размотрите доњи снимак екрана:

Веза - хттп: // лоцалхост: 8081 / гоф

Надам се да сте разумели значење контекстног пута.

Сада направите приказ цевовода, размотрите снимак екрана испод:

Кликните на икону плус да бисте креирали нови приказ.

Конфигуришите цевовод онако како желите, размотрите снимак екрана испод:

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

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

Тако смо у могућности да нашу апликацију континуирано примењујемо на тест серверу за тест прихватања корисника (УАТ).

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

Да бисте изградили ЦИ / ЦД цевоводе, морате да савладате широку палету вештина Савладајте потребне вештине за ДевОпс одмах