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