Разумевање сталне интеграције и непрекидне примене

Чуо сам ЦИ / ЦД, али није сигуран шта је то?


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

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

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

Ако сте икада били у овој ситуацији, сложићете се да то може бити бол – нико не жели да свој радни дан проведе овако.

Шта је решење?

Континуирано интеграција

хттпс://ввв.иоутубе.цом/ватцх?в=ХнВуИјУв_К8

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

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

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

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

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

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

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

Врсте тестова

У писању тестова који ће бити део процеса интеграције, ево неколико који се могу применити у процесу:

  • Интеграција – комбинује појединачне јединице софтвера и тестира их као групу.
  • Јединица – тестира појединачне јединице или компоненте софтвера попут метода или функција.
  • УИ – тврди да софтвер добро функционише из перспективе корисника.
  • Прихватање – тестови које софтвер испуњава у складу са пословним захтевима.

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

Алат за континуирану интеграцију

Не улазећи у дубину, ево алата помоћу којих можете почети да користите у својим тренутним или новим пројектима;

  • Травис ЦИ – познат у свету отвореног кода и обећава вам да ћете код без проблема тестирати за неколико минута.
  • Круг ЦИ – пружа вам снагу, флексибилност и контролу за аутоматизацију цевовода од контроле до примене.
  • Јенкинс – пружа стотине додатака за подршку изградњи, имплементацији и аутоматизацији било којег пројекта.

Ако сте нови за Јенкинс, ја бих предложио да ово узмете Курс Удеми научити ЦИ са Јава и .НЕТ.

Непрекидно постављање

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

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

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

Да би тим имао користи од праксе континуираног размештања, морају имати следеће;

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

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

Закључак

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

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

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

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map