Денес, повеќето софтверски производи се развиваат во тимови. Условите за успешен развој на тимот може да се претстават во форма на едноставен дијаграм.

Откако ќе го напишете вашиот код, треба да бидете сигурни дека:

1. Работи.
2. Ништо не крши, вклучително и кодот што го напишале твоите колеги.

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

CI е работен тек каде што го интегрирате вашиот код во целокупниот код на производот што е можно почесто. И вие не само што се интегрирате, туку и постојано проверувате дали сè работи. Бидејќи треба многу и често да проверувате, вреди да се размислува за автоматизација. Можете да проверите сè рачно, но не треба, а еве зошто.

• Драги луѓе. Еден час работа на кој било програмер е поскап од еден час работа на кој било сервер.
• Луѓето прават грешки. Затоа, може да се појават ситуации кога тестовите биле извршени на погрешна гранка или погрешно извршување е составено за тестери.
• Луѓето се мрзливи. Одвреме-навреме, кога ќе завршам некоја задача, ми се наметнува мислата: „Што има да се провери? Напишав два реда - сè работи! Мислам дека некои од вас понекогаш имаат такви мисли. Но, секогаш треба да проверувате.

Како Континуирана интеграција беше имплементирана и развиена во тимот за развој на мобилни телефони Avito, како тие отидоа од 0 на 450 градби дневно и дека градежните машини склопуваат 200 часа на ден, вели Николај Нестеров (ннестеров) е учесник во сите еволутивни промени на CI/CD Android апликацијата.

Приказната се заснова на примерот на команда на Android, но повеќето од пристапите се применливи и на iOS.

Еднаш, едно лице работеше во тимот на Avito Android. По дефиниција, не му требаше ништо од Континуирана интеграција: немаше со кого да се интегрира.

Но, апликацијата растеше, се појавуваа се повеќе и повеќе нови задачи, а тимот растеше соодветно. Во одреден момент, време е поформално да се воспостави процес на интеграција на кодот. Беше одлучено да се користи Git flow.

Концептот на Git flow е добро познат: проектот има една заедничка развојна гранка, и за секоја нова функција, програмерите сечат посебна гранка, се обврзуваат на неа, туркаат и кога сакаат да го спојат својот код во гранката за развој, отвораат барање за повлекување. За да споделиме знаење и да разговараме за пристапите, воведовме преглед на кодот, односно колегите мора да го проверат и да го потврдат кодот меѓусебно.

Проверки

Гледањето код со очи е кул, но не доволно. Затоа се воведуваат автоматски проверки.

• Прво на сите, ние проверуваме склопување ARK.
• Многу Јунит тестови.
• Сметаме покриеност со код, бидејќи правиме тестови.

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

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

• Програмер пишува код на својот лаптоп. Можете да извршите проверки за интеграција токму овде - или со commit hook, или едноставно да извршите проверки во позадина.
• Откако развивачот ќе го притисне кодот, тој отвора барање за повлекување. За да може неговиот код да биде вклучен во гранката за развој, потребно е да поминете низ преглед на кодот и да го соберете потребниот број потврди. Овде можете да овозможите проверки и градби: додека не бидат успешни сите градби, барањето за повлекување не може да се спои.
• Откако ќе се спои барањето за повлекување и кодот е вклучен во развојот, можете да изберете погодно време: на пример, ноќе, кога сите сервери се слободни и да извршите проверки колку што сакате.

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

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

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

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

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

Ни требаа два дена за целосно да го поставиме основниот CI (во натамошниот текст проценката на времето е приближна, потребна за размер).

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

Ја започнавме изградбата на последниот commit на гранката од која беше отворено барањето за повлекување. Но, тестовите на оваа заложба можат само да покажат дека кодот што го напишал развивачот работи. Но, не докажуваат дека ништо не скршил. Всушност, треба да ја проверите состојбата на гранката за развој откако функцијата ќе се спои во неа.

За да го направите ова, напишавме едноставна баш скрипта premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

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

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

Апликацијата се разви, се појавуваа сè повеќе задачи, тимот растеше, а premerge.sh понекогаш почна да не разочарува. Develop имаше спротивставени промени што ја прекинаа изградбата.

Пример како се случува ова:

Двајца програмери истовремено почнуваат да работат на карактеристиките А и Б. Развивачот на карактеристиката А открива неискористена карактеристика во проектот answer() и како добар извидник го отстранува. Во исто време, развивачот на функцијата Б додава нов повик на оваа функција во неговата филијала.

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

Кога нема да се развие, тоа е локална катастрофа. Целиот тим не може да собере ништо и да го достави на тестирање.

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

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

Како да не се скрши развие

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

За да разберете колку време ќе потрае, разгледајте пример со два ПР. Отвораме два ПР: две конструкции, две проверки. Откако првиот ПР ќе се спои во развој, вториот треба повторно да се изгради. Севкупно, два ПР бараат три циклуси на проверки: 2 + 1 = 3.

Во принцип, добро е. Но, ја разгледавме статистиката и типичната ситуација во нашиот тим беше 10 отворени ПР, а потоа бројот на проверки е збир на прогресијата: 10 + 9 +... + 1 = 55. Односно, да се прифати 10 ПР, треба да се обнови 55 пати. И ова е во идеална ситуација, кога сите проверки поминуваат прв пат, кога никој не отвора дополнително барање за повлекување додека овие десетици се обработуваат.

Замислете се себеси како програмер кој треба да биде првиот што ќе кликне на копчето „спој“, бидејќи ако соседот го направи ова, тогаш ќе мора да почекате додека сите изданија не поминат повторно... Не, тоа нема да функционира , тоа сериозно ќе го забави развојот.

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

Како резултат на тоа, остана само третата опција - возење велосипед. Целиот наш код, сите наши извори се зачувани во складиште на серверот Bitbucket. Според тоа, моравме да развиеме приклучок за Bitbucket.

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

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

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

Вреди да се напомене дека овој приклучок има недостаток: само еднаш ја рестартира изградбата. Односно, сè уште постои мал прозорец низ кој може да се развијат конфликтни промени. Но, веројатноста за ова е мала, и го направивме овој компромис помеѓу бројот на стартови и веројатноста за неуспех. За две години пукаше само еднаш, па веројатно не беше залудно.

Ни требаа две недели да ја напишеме првата верзија на приклучокот Bitbucket.

Нови проверки

Во меѓувреме, нашиот тим продолжи да расте. Додадени се нови проверки.

Мислевме: зошто да правиме грешки ако може да се спречат? И затоа спроведоа анализа на статички код. Започнавме со lint, кој е вклучен во Android SDK. Но, во тоа време тој воопшто не знаеше да работи со кодот на Котлин, а ние веќе имавме 75% од апликацијата напишана во Котлин. Затоа, вградените беа додадени на влакненца Проверки на Android Studio.

За да го направиме ова, моравме да направиме многу изопачувања: да земеме Android Studio, да го спакуваме во Docker и да го пуштиме на CI со виртуелен монитор, за да мисли дека работи на вистински лаптоп. Но, тоа функционираше.

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

Но, тестовите за инструменти и тестовите за слики од екранот треба да се извршуваат на уреди: на емулатори или на вистински уреди. Со оглед на тоа што има многу тестови и често се водат, потребна е цела фарма. Започнувањето на сопствена фарма е премногу трудоинтензивно, па најдовме готова опција - Firebase Test Lab.

Лабораторија за тестирање на Firebase

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

Беа потребни приближно три недели за да се имплементира Firebase Test Lab во нашиот CI.

Но, тимот продолжи да расте, а Firebase, за жал, почна да не разочарува. Во тоа време, тој немаше никаков SLA. Понекогаш Firebase нè тераше да чекаме додека потребниот број уреди не се ослободат за тестови и не започнувавме веднаш да ги извршуваме, како што сакавме. Чекањето во ред траеше и до половина час, што е многу долго. На секој ПР се вршеа тестови за инструменти, одложувањата навистина го забавија развојот, а потоа месечната сметка дојде со тркалезна сума. Во принцип, беше одлучено да се напушти Firebase и да се работи внатре, бидејќи тимот порасна доволно.

Докер + Пајтон + баш

Го зедовме Docker, наполнивме емулатори во него, напишавме едноставна програма во Python, која во вистински момент го прикажува потребниот број на емулатори во потребната верзија и ги запира кога е потребно. И, се разбира, неколку баш скрипти - каде ќе бевме без нив?

Беа потребни пет недели за да се создаде сопствена средина за тестирање.

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

• склопување ARK;
• Јунит тестови;
• Линт;
• Проверки на Android Studio;
• Тестови со инструменти;
• Тестови од екранот.

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

Колку долго е предолго? Поставивме податоци од Bitbucket и TeamCity во системот за анализа и го сфативме тоа просечно време на чекање 45 минути. Односно, развивачот, кога отвора барање за повлекување, во просек чека 45 минути за резултатите од изградбата. Според мое мислење, ова е многу, и не можете да работите така.

Се разбира, решивме да ги забрзаме сите наши градби.

Да забрзаме

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

Отстранување на проверки што траат премногу долго

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

• Нема да се. CI може да фати грешка при компилација кога нешто не се гради поради конфликтни промени. Како што веќе реков, тогаш никој не може да состави ништо, развојот запира и сите стануваат нервозни.
• Грешка во однесувањето. На пример, кога апликацијата е изградена, но паѓа кога ќе притиснете копче или копчето воопшто не е притиснато. Ова е лошо бидејќи таква грешка може да стигне до корисникот.
• Грешка во распоредот. На пример, се кликнува на копче, но се поместени 10 пиксели налево.
• Зголемување на техничкиот долг.

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

Врз основа на оваа класификација, ја размрдавме целата листа на проверки. Прецртано Линт и го одложи неговото лансирање преку ноќ: само за да произведе извештај за тоа колку проблеми имало во проектот. Се договоривме да работиме одделно со техничкиот долг, и Проверките на Android Studio беа целосно напуштени. Android Studio во Docker за извршување инспекции звучи интересно, но предизвикува многу проблеми во поддршката. Секое ажурирање на верзиите на Android Studio значи борба со неразбирливи грешки. Исто така, беше тешко да се поддржат тестовите за слики од екранот, бидејќи библиотеката не беше многу стабилна и имаше лажни позитиви. Тестовите за слики од екранот се отстранети од списокот за проверка.

Како резултат на тоа, останавме со:

• склопување ARK;
• Јунит тестови;
• Тестови со инструменти.

Gradle далечински кеш

Без тешки проверки, сè стана подобро. Но, нема ограничување до совршенството!

Нашата апликација веќе беше поделена на околу 150 gradle модули. Gradle далечинскиот кеш обично работи добро во овој случај, па решивме да го пробаме.

Gradle далечинскиот кеш е услуга која може да ги кешира артефактите од изградени за поединечни задачи во поединечни модули. Gradle, наместо всушност да го компајлира кодот, користи HTTP за да чука на далечинскиот кеш и да праша дали некој веќе ја извршил оваа задача. Ако одговорот е да, едноставно го презема резултатот.

Работењето на далечинскиот кеш на Gradle е лесно бидејќи Gradle обезбедува слика на Docker. Успеавме да го направиме тоа за три часа.

Сè што требаше да направите е да го стартувате Docker и да напишете една линија во проектот. Но, иако може брзо да се лансира, ќе биде потребно доста време за сè да функционира добро.

Подолу е графиконот за промашување на кешот.

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

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

Анализа на влијание

На барање за повлекување, собираме git diff и ги наоѓаме изменетите Gradle модули.

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

Тестовите за инструменти не се толку едноставни, бидејќи тие мора да се наоѓаат во модулот за апликација од највисоко ниво. Користивме хеуристика со анализа на бајтекод за да разбереме на кој модул припаѓа секој тест.

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

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

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

Проблемите со повратните информации го забавуваат развојот, па затоа се обидовме да обезбедиме што е можно појасни и детални информации за секој ПР и градба. Започнавме со коментари во Bitbucket до ПР, покажувајќи која изработка не успеала и зошто, и напишавме насочени пораки во Slack. На крајот, создадовме контролна табла за односи со јавноста за страницата со список на сите изданија што моментално се извршуваат и нивниот статус: наредени, работи, паднати или завршени. Можете да кликнете на изградбата и да стигнете до нејзиниот дневник.

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

Планови

Да преминеме на поновата историја. Откако го решивме проблемот со повратните информации, достигнавме ново ниво - решивме да изградиме сопствена фарма за емулатори. Кога има многу тестови и емулатори, тешко е да се управуваат. Како резултат на тоа, сите наши емулатори се префрлија во кластерот k8s со флексибилно управување со ресурсите.

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

• Врати го Линт (и друга статичка анализа). Веќе работиме во оваа насока.
• Вклучете сè на блокатор за односи со јавноста тестови од крај до крај на сите SDK верзии.

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

Советы

Кога би можел да дадам само еден совет, тоа би било ова:

Ве молиме бидете внимателни со скриптите на школка!

Bash е многу флексибилна и моќна алатка, многу е погодно и брзо за пишување скрипти. Но, со него можете да паднете во стапица и, за жал, паднавме во неа.

Сè започна со едноставни скрипти што работеа на нашите машини за изградба:

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

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

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

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

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

Решивме да ја избереме втората опција и сега систематски ги бришеме сите баш скрипти и пишуваме многу сопствени gradle задачи.

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

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

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

Совет бр. 3: Docker може да помогне со животната средина.

Дефинитивно ќе им помогне на програмерите на Android, за жал, iOS сè уште нема.

Ова е пример за едноставна докер-датотека која содржи jdk и android-sdk:

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

Откако ја напишавте оваа датотека Docker (ќе ви кажам една тајна, не мора да ја пишувате, туку само извлечете ја подготвена од GitHub) и ја составивте сликата, добивате виртуелна машина на која можете да ја изградите апликацијата и извршете ги тестовите на Junit.

Двете главни причини зошто ова има смисла се приспособливоста и повторливоста. Користејќи го докерот, можете брзо да подигнете дузина build-агенти кои ќе имаат потполно иста околина како претходната. Ова многу го олеснува животот на CI инженерите. Сосема е лесно да се втурне android-sdk во docker, но со емулаторите е малку потешко: ќе треба да работите малку понапорно (или повторно да го преземете готовиот од GitHub).

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

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

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

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

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

Сега има многу компании кои обезбедуваат облак CI.

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

Совет бр. 7: Во голем тим, домашните решенија се попрофитабилни.

Но, порано или подоцна, како што расте тимот, домашните решенија ќе станат попрофитабилни. Има еден проблем со овие одлуки. Во економијата постои закон за намалување на приносите: во секој проект, секое следно подобрување е сè потешко и бара се повеќе и повеќе инвестиции.

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

Јасно е дека секое подобрување станува сè потешко. Гледајќи го овој график, можете да разберете дека Континуираната интеграција треба да се развива во согласност со растот на големината на тимот. За тим од две лица, трошењето 50 дена за развој на внатрешна фарма за емулатори е просечна идеја. Но, во исто време, за голем тим, воопшто да не се прави Континуирана интеграција е исто така лоша идеја, бидејќи проблемите со интеграцијата, поправање на комуникацијата итн. ќе биде потребно уште повеќе време.

Почнавме со идејата дека е потребна автоматизација затоа што луѓето се скапи, грешат и се мрзливи. Но, луѓето исто така автоматизираат. Затоа, сите исти проблеми се однесуваат на автоматизацијата.

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

Но, имам статистика: грешките се фатени во 20% од склоповите. И ова не е затоа што нашите програмери лошо пишуваат код. Тоа е затоа што програмерите се уверени дека ако направат некоја грешка, таа нема да заврши во развој, туку ќе биде фатена со автоматизирани проверки. Според тоа, програмерите можат да поминуваат повеќе време за пишување код и интересни работи, наместо да работат и тестираат нешто локално.

Вежбајте континуирана интеграција. Но, во умерени количини.

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

Извор: www.habr.com