Права разлика између континуиране интеграције и континуиране примене

Постоји доста садржаја који описује шта су континуирана интеграција, континуирана испорука и континуирана примена. Али какве сврхе ти процеси уопште служе?

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

Непрекидна интеграција је тимски проблем

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

Сценариј који желимо да избегнемо је да се неисправно урезивање доводи до главне гране. Неисправан значи да се код не компајлира или се апликација неће покренути или је неупотребљива. Зашто? Не зато што је апликација неисправна или зато што сви тестови морају увек бити зелени. То није проблем - можете одлучити да не примените ту верзију и сачекате решење.

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

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

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

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

Провере осигуравају да, на минимуму:

  • Апликација треба да се направи и покрене
  • Најкритичније функције би требале бити функционалне у сваком тренутку (путовање за регистрацију / пријаву корисника и кључне пословне карактеристике)
  • Уобичајени слојеви апликације на које се ослањају сви програмери требало би да буду стабилни. То значи јединствене тестове на тим деловима.

У пракси то значи да требате повући било који оквир за јединствено тестирање који вам одговара и осигурати уобичајене слојеве апликације. Понекад то није толико кода и може се учинити прилично брзо. Такође треба да додате „тест дима“ којим се потврђује да се код компајлира и да се апликација покреће. Ово је посебно важно у технологијама са лудим ињекцијама зависности попут Јава Спринг или .НЕТ језгра. У великим пројектима је тако лако погрешно повезати зависности да је потребно проверити да ли се апликација увек покреће.

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

У следећим одељцима видећемо како ће процес континуиране испоруке добро искористити ове многе тестове.

Не ради се о алатима

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

Континуирана интеграција није ствар алата. Ради се о раду у малим деловима и интеграцији вашег новог кода у главну грану и честом повлачењу.

Често значи барем свакодневно. Задатак на којем радите поделите на мање задатке. Спојите свој код врло често и повуците врло често. На овај начин нико не ради одвојено дуже од дан или два, а проблеми немају времена да постану груде снега.

Велики задатак не мора бити све у једној грани. Никад не би требало. Технике спајања недовршеног рада са главном граном називају се „гранање апстракцијом“ и „пребацивање карактеристика“. Погледајте пост на блогу Како започети континуирану интеграцију за више детаља.

Кључне тачке за добру израду ЦИ

Врло је једноставно. Нека буде кратко. 3-7 минута би требало да буде макс. Није ствар у ЦПУ и ресурсима. Ради се о продуктивности програмера. Прво правило продуктивности је фокус. Урадите једну ствар, завршите је, а затим пређите на следећу ствар.

Пребацивање контекста је скупо. Студије показују да је потребно око 23 минута да се дубоко преусмерите на нешто када вас узнемире.

Замислите да притиснете своју грану да бисте је спојили. Започињете други задатак. Трошите 15-20 минута улазећи у то. Минут након што сте у зони, од ваше 20-минутне израде ЦИ-а за претходни задатак добијате обавештење „неуспешна изградња“. Врати се да то поправиш. Притиснеш га поново. Лако сте изгубили више од 20 минута крећући се напред-назад.

Помножите 20 минута једном или два пута дневно са бројем програмера у вашем тиму ... То је много изгубљеног драгоценог времена.

Сад замислите да ли су повратне информације стигле у року од 3 минута. Вероватно уопште не бисте започели нови задатак. Имали бисте доказ да сте још једном прочитали код или прегледали ПР док сте чекали. Дошло би неуспешно обавештење и ви бисте га поправили. Тада бисте могли да пређете на следећи задатак. То је врста фокуса који би ваш процес требао омогућити.

Ако вам кратка израда ЦИ буде кратка, то представља компромис. Тестови који трају дуже или пружају малу вредност у контексту ЦИ треба преместити на корак ЦД-а. И да, и тамо треба отклонити кварове. Али пошто они никога не спречавају да уради своје, поправке можете узети као „следећи задатак“ када завршите оно што радите. Само искључите обавештења док радите и свако мало проверите. Нека се пребацивање контекста на минимум.

Континуирана испорука и примена су инжењерски проблеми

Помиримо се са дефиницијама да то уклонимо с пута.

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

Идеја континуиране испоруке је да припреми артефакте што ближе ономе што желите да покренете у свом окружењу. То могу бити .јар или .вар датотеке ако радите са Јавом или извршне датотеке ако радите са .НЕТ. То такође могу бити директоријуми преписаног ЈС кода или чак Доцкер контејнери, шта год чини примену краћом (тј. Унапред сте направили онолико колико можете унапред).

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

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

На овај начин можете филтрирати које верзије ваше главне гране су заправо спремне за производњу, а које не. Идеалан тестни пакет:

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

Не мора бити врло брзо. Прихватљиво је 30 минута или 1 сат.

Континуирано постављање је следећи корак. Најсавременију верзију кода која је спремна за производњу инсталирате у неко окружење. Идеално за продукцију ако довољно верујете свом ЦД тест пакету.

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

Континуирана испорука и континуирана примена (назовимо их од сада ЦД) нису проблеми у тиму. Ради се о проналажењу праве равнотеже између времена извршавања, напора на одржавању и релевантности вашег пакета тестова како бисте могли да кажете „Ова верзија ради како треба“.

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

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

Која је велика разлика?

Континуирана интеграција је проблем хоризонталне скалабилности. Желите да програмери често спајају свој код, тако да провере морају бити брзе. Идеално у року од неколико минута како би се избегло да програмери непрестано пребацују контекст уз изузетно асинхне повратне информације од ЦИ верзија.

Што више програмера имате, већа рачунарска снага вам је потребна за покретање једноставних провера (израда и тестирање) на свим активним гранама.

Добра израда ЦИ: Осигурава да се у главну грану не уведе код који разбија основне ствари и спречава остале чланове тима да раде и да је довољно брз да програмерима пружи повратне информације у року од неколико минута да спречи пребацивање контекста између задатака.

Континуирана испорука и примена су проблеми вертикалне скалабилности. Пред вама је једна прилично сложена операција.

Добра израда ЦД-а: Осигурава да што више функција ради исправно. Што је брже, то боље, али није ствар у брзини. Израда од 30-60 минута је у реду.

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

Али то нам није потребно. Израда артефаката за свако урезивање и што је брже могуће је обично претерана. Можете врло добро приступити ЦД-у на најбољи могући начин: направите једну ЦД изградњу која ће одабрати најновију предају да би се верификовала када је завршена дата градња.

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

Закључак

Алати и принципи који се користе за извршавање ЦИ и ЦД-а су често врло слични. Циљеви су ипак врло различити.

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

Континуирана испорука примене је покретање што темељитијих провјера како бисте ухватили проблеме на коду. Комплетност провера је најважнији фактор. Обично се мери у смислу покривености кодом или функционалне покривености ваших тестова. Рано хватање грешака спречава да се сломљени код примени у било које окружење и штеди драгоцено време вашег тест тима.

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

Објављено 27. новембра 2019. на блогу Фире ЦИ.