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

Када напишете свој код, морате се уверити да је:

1. Ð Ð ° Ð ± Ð¾Н‚Ð ° ÐµН ‚.
2. Ништа не квари, укључујући и код које су ваше колеге написале.

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

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

• Драги људи. Сат рада било ког програмера скупљи је од сата рада било ког сервера.
• Људи праве грешке. Стога се могу појавити ситуације када су тестови покренути на погрешној грани или је погрешно урезивање састављено за тестере.
• Људи су лењи. С времена на време, када завршим неки задатак, јави се мисао: „Шта ту треба проверити? Написао сам два реда - све ради! Мислим да неки од вас понекад имају такве мисли. Али увек треба проверити.

Како је Цонтинуоус Интегратион имплементирана и развијена у тиму за развој мобилних Авито, како су прешли са 0 на 450 прављења дневно и како се машине за прављење склапају 200 сати дневно, каже Николај Нестеров (ннестеров) је учесник свих еволутивних промена ЦИ/ЦД Андроид апликације.

Прича је заснована на примеру Андроид команде, али већина приступа је применљива и на иОС-у.

Некада је једна особа радила у Авито Андроид тиму. По дефиницији, није му било потребно ништа од континуиране интеграције: није било с ким да се интегрише.

Али апликација је расла, појавило се све више нових задатака, а тим је растао у складу са тим. У неком тренутку, време је да се формалније успостави процес интеграције кода. Одлучено је да се користи Гит флов.

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

Чекови

Видети код својим очима је цоол, али није довољно. Због тога се уводе аутоматске провере.

• Пре свега, проверавамо АРК скупштина.
• Пуно Јунит тестови.
• Сматрамо покривеност кода, пошто радимо тестове.

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

Може се схематски представити овако:

• Програмер пише код на свом лаптопу. Можете покренути интеграцијске провере управо овде - или са закачицом за урезивање, или једноставно покренути провере у позадини.
• Након што програмер гурне код, отвара захтев за повлачење. Да би његов код био укључен у грану за развој, потребно је проћи кроз преглед кода и прикупити потребан број потврда. Овде можете омогућити провере и надградње: док све не буду успешне, захтев за повлачење се не може спојити.
• Након што је захтев за повлачење спојен и код укључен у развој, можете одабрати погодно време: на пример, ноћу, када су сви сервери слободни, и покренути онолико провера колико желите.

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

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

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

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

У то време, све наше градње су завршене прилично брзо, тако да смо једноставно укључили АРК буилд, Јунит тестове и прорачуне покривености кода као блокатор захтева за повлачење. Укључили смо га, размислили о томе и напустили покривање кода јер смо мислили да нам не треба.

Требало нам је два дана да комплетно поставимо основни ЦИ (у даљем тексту временска процена је приближна, потребна за размеру).

После тога смо почели да размишљамо даље - да ли уопште проверавамо исправно? Да ли исправно покрећемо надградње на захтевима за повлачење?

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

Да бисмо то урадили, написали смо једноставну басх скрипту премерге.сх:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

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

Било је потребно три дана да се проблем локализује, пронађе решење и напише ова скрипта.

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

Пример како се ово дешава:

Два програмера истовремено почињу да раде на карактеристикама А и Б. Програмер функције А открива неискоришћену функцију у пројекту answer() и, као добар извиђач, уклања га. Истовремено, програмер функције Б додаје нови позив овој функцији у својој грани.

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

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

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

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

Како не сломити развој

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

Да бисте разумели колико ће ово трајати, размотрите пример са два ПР-а. Отварамо два ПР-а: две израде, две провјере. Након што се први ПР споји у развој, други треба поново да се изгради. Укупно, два ПР захтевају три провере: 2 + 1 = 3.

У принципу, у реду је. Али погледали смо статистику и типична ситуација у нашем тиму је била 10 отворених ПР-а, а онда је број провера збир прогресије: 10 + 9 +... + 1 = 55. То јест, прихватити 10 ПР, потребно је да се реконструише 55 пута. И то у идеалној ситуацији, када све провере прођу први пут, када нико не отвори додатни пулл захтев док се ових десетина обрађује.

Замислите себе као програмера који треба први да кликне на дугме „спајање“, јер ако то уради комшија, онда ћете морати да сачекате док се све верзије поново не прођу... Не, то неће успети , то ће озбиљно успорити развој.

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

Као резултат тога, остала је само трећа опција - бицикл. Сав наш код, сви наши извори се чувају у спремишту на Битбуцкет серверу. Сходно томе, морали смо да развијемо додатак за Битбуцкет.

Овај додатак замењује механизам спајања захтева за повлачењем. Почетак је стандардан: отвара се ПР, сви склопови се покрећу, преглед кода је завршен. Али након што је преглед кода завршен и програмер одлучи да кликне на „спајање“, додатак проверава у односу на које развојно стање су провере покренуте. Ако је развој ажуриран након изградње, додатак неће дозволити да се такав захтев за повлачењем споји у главну грану. Једноставно ће поново покренути верзије релативно недавног развоја.

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

Пре имплементације овог додатка, у просеку смо имали 2,7 покретања прегледа по захтеву за повлачење. Са додатком је било 3,6 покретања. Ово нам је одговарало.

Вреди напоменути да овај додатак има недостатак: само једном поново покреће изградњу. Односно, још увек постоји мали прозор кроз који се конфликтне промене могу развити. Али вероватноћа за то је мала и направили смо компромис између броја покретања и вероватноће неуспеха. За две године опалио је само једном, тако да вероватно није било џабе.

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

Нове чекове

У међувремену, наш тим је наставио да расте. Додате су нове чекове.

Помислили смо: зашто правити грешке ако се могу спречити? И зато су спровели статичка анализа кода. Почели смо са линтом, који је укључен у Андроид СДК. Али у то време он уопште није знао да ради са Котлин кодом, а ми смо већ имали 75% апликације написане у Котлину. Због тога су у линт додани уграђени Андроид Студио провере.

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

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

Али тестови инструментације и тестови снимка екрана морају се изводити на уређајима: на емулаторима или на стварним уређајима. С обзиром на то да има много тестова и да се често раде, потребна је цела фарма. Покретање сопствене фарме је превише радно интензивно, па смо пронашли готову опцију - Фиребасе Тест Лаб.

Фиребасе Тест Лаб

Изабран је зато што је Фиребасе Гоогле производ, што значи да би требало да буде поуздан и мало је вероватно да ће икада умрети. Цене су разумне: $5 по сату рада правог уређаја, 1 $ по сату рада емулатора.

Требало је отприлике три недеље да имплементирамо Фиребасе Тест Лаб у наш ЦИ.

Али тим је наставио да расте, а Фиребасе је, нажалост, почео да нас изневерава. У то време није имао СЛА. Понекад нас је Фиребасе терао да сачекамо док се потребан број уређаја не ослободи за тестове, а није одмах почео да их извршава, како смо желели. Чекање у реду је трајало и до пола сата, што је јако дуго. Тестови инструментације су вођени на сваком ПР-у, кашњења су заиста успоравала развој, а онда је месечни рачун долазио са округлом сумом. Генерално, одлучено је да се напусти Фиребасе и ради у кући, пошто је тим довољно порастао.

Доцкер + Питхон + басх

Узели смо Доцкер, убацили у њега емулаторе, написали једноставан програм у Пајтону, који у правом тренутку поднесе потребан број емулатора у траженој верзији и по потреби их заустави. И, наравно, неколико басх скрипти - где бисмо били без њих?

Било је потребно пет недеља да створимо сопствено окружење за тестирање.

Као резултат тога, за сваки захтев за повлачењем постојала је опсежна листа провера за блокирање спајања:

• АРК скупштина;
• Јунит тестови;
• Линт;
• Андроид Студио провере;
• Инструментатион тестс;
• Тестови снимка екрана.

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

Колико дуго је предуго? Учитали смо податке из Битбуцкет-а и ТеамЦити-а у систем анализе и то схватили просечно време чекања 45 минута. То јест, програмер, када отвори захтев за повлачење, чека у просеку 45 минута на резултате изградње. По мом мишљењу, ово је много, а не можете тако да радите.

Наравно, одлучили смо да убрзамо све наше градње.

Хајде да убрзамо

Видевши да зграде често стоје у реду, прва ствар коју урадимо је купио више хардвера — екстензивни развој је најједноставнији. Градње су престале да стоје у реду, али се време чекања само незнатно смањило, јер су неке провере саме по себи трајале веома дуго.

Уклањање чекова који предуго трају

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

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

Након што смо погледали ову листу, схватили смо да су само прве две тачке критичне. Желимо прво да ухватимо такве проблеме. Грешке у изгледу се откривају у фази прегледа дизајна и тада се могу лако исправити. Бављење техничким дугом захтева посебан процес и планирање, па смо одлучили да га не тестирамо на захтеву за повлачење.

На основу ове класификације, уздрмали смо целу листу провера. Прецртани Линт и одложио његово лансирање преко ноћи: само да би направио извештај о томе колико је проблема било у пројекту. Договорили смо се да радимо одвојено са техничким дугом, и Провере Андроид Студија су потпуно напуштене. Андроид Студио у Доцкер-у за покретање инспекција звучи занимљиво, али изазива много проблема у подршци. Свако ажурирање верзија Андроид Студија значи борбу са неразумљивим грешкама. Такође је било тешко подржати тестове снимака екрана, јер библиотека није била баш стабилна и било је лажних позитивних резултата. Тестови снимака екрана су уклоњени са листе за проверу.

Као резултат тога, остали смо са:

• АРК скупштина;
• Јунит тестови;
• Инструментациони тестови.

Градле удаљена кеш меморија

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

Наша апликација је већ била подељена на око 150 градле модула. Градле удаљени кеш обично добро функционише у овом случају, па смо одлучили да га испробамо.

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

Покретање Градле удаљене кеш меморије је лако јер Градле пружа Доцкер слику. То смо успели да урадимо за три сата.

Све што је требало да урадите је да покренете Доцкер и упишете један ред у пројекат. Али иако се може брзо покренути, биће потребно доста времена да све добро функционише.

Испод је графикон промашаја кеша.

На самом почетку, проценат промашаја кеша био је око 65. После три недеље успели смо да повећамо ову вредност на 20%. Испоставило се да задаци које Андроид апликација прикупља имају чудне транзитивне зависности, због чега је Градле пропустио кеш.

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

Анализа утицаја

На захтев за повлачење, прикупљамо гит дифф и проналазимо модификоване Градле модуле.

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

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

Надоградња рада тестова инструментације тако да они тестирају само укључене модуле трајала је око осам недеља.

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

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

Проблеми са повратним информацијама успоравају развој, па смо се потрудили да пружимо што јасније и детаљније информације о сваком ПР-у и изградњи. Почели смо са коментарима у Битбуцкет-у за ПР, наводећи која је изградња пропала и зашто, и написали циљане поруке у Слацк-у. На крају смо направили ПР контролну таблу за страницу са листом свих верзија које су тренутно покренуте и њиховим статусом: у реду чекања, покренут, срушен или завршен. Можете кликнути на градњу и доћи до њеног дневника.

Шест недеља је потрошено на детаљне повратне информације.

Планови

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

Поред тога, постоје и други планови.

• Вратите Линт (и друге статичке анализе). У том правцу већ радимо.
• Покрените све на ПР блокатору тестови од краја до краја на свим верзијама СДК-а.

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

Советы

Ако бих могао да дам само један савет, то би био овај:

Будите пажљиви са схелл скриптама!

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

Све је почело једноставним скриптама које су радиле на нашим машинама за прављење:

#!/usr/bin/env bash
./gradlew assembleDebug

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

Можете замислити трошкове рада за развој таквих скрипти. Саветујем ти да не упаднеш у ову замку.

Шта се може заменити?

• Било који скриптни језик. Писати Питхон или Котлин Сцрипт згодније јер је програмирање, а не скрипте.
• Или опишите сву логику изградње у обрасцу Прилагођени градле задаци за ваш пројекат.

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

Савет #2: Чувајте инфраструктуру у коду.

Погодно је када се поставка Цонтинуоус Интегратион не чува у корисничком интерфејсу Јенкинса или ТеамЦити-а, итд., већ у облику текстуалних датотека директно у спремишту пројекта. Ово даје могућност верзије. Неће бити тешко вратити или направити код на другој грани.

Скрипте се могу чувати у пројекту. Шта радити са животном средином?

Савет бр. 3: Доцкер може помоћи у заштити животне средине.

Дефинитивно ће помоћи Андроид програмерима; иОС га, нажалост, још нема.

Ово је пример једноставне доцкер датотеке која садржи јдк и андроид-сдк:

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

Након што сте написали овај Доцкер фајл (рећи ћу вам тајну, не морате да га пишете, већ га само извуците готову са ГитХуб-а) и саставите слику, добијате виртуелну машину на којој можете да направите апликацију и покрените Јунит тестове.

Два главна разлога зашто ово има смисла су скалабилност и поновљивост. Користећи доцкер, можете брзо подићи десетак агената за изградњу који ће имати потпуно исто окружење као претходни. Ово чини живот ЦИ инжењерима много лакшим. Сасвим је лако угурати андроид-сдк у доцкер, али са емулаторима је то мало теже: мораћете да радите мало више (или поново преузмете готов са ГитХуб-а).

Савет број 4: не заборавите да се инспекције не раде ради инспекције, већ ради људи.

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

Савет #5: Будите прагматични када развијате континуирану интеграцију.

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

Савет #6: Користите готове алате.

Сада постоји много компанија које пружају ЦИ у облаку.

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

Савет #7: У великом тиму, интерна решења су исплативија.

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

Економија описује цео наш живот, укључујући и континуирану интеграцију. Направио сам распоред трошкова рада за сваку фазу развоја наше континуиране интеграције.

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

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

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

Али имам статистику: грешке се хватају у 20% скупова. И то није зато што наши програмери лоше пишу код. То је зато што су програмери уверени да ако направе неку грешку, она неће завршити у развоју, већ ће бити ухваћена аутоматским проверама. Сходно томе, програмери могу провести више времена у писању кода и занимљивих ствари, умјесто да раде и тестирају нешто локално.

Вежбајте континуирану интеграцију. Али у умерености.

Иначе, Николај Нестеров не само да сам даје одличне извештаје, већ је и члан програмског одбора АппсЦонф и помаже другима да припреме значајне говоре за вас. Комплетност и корисност програма следеће конференције може се оценити по темама у распоред. А за детаље дођите у Инфоспаце 22-23. априла.

Извор: ввв.хабр.цом