Днес повечето софтуерни продукти се разработват в екипи. Условията за успешно развитие на екипа могат да бъдат представени под формата на проста диаграма.

След като напишете своя код, трябва да се уверите, че той:

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

Ако и двете условия са изпълнени, значи сте на път към успеха. За да проверим лесно тези условия и да не се отклоняваме от печелившия път, измислихме непрекъсната интеграция.

CI е работен процес, при който интегрирате кода си в общия код на продукта възможно най-често. И вие не просто интегрирате, но и постоянно проверявате дали всичко работи. Тъй като трябва да проверявате много и често, струва си да помислите за автоматизация. Можете да проверите всичко ръчно, но не трябва и ето защо.

• Мили хора. Един час работа на всеки програмист е по-скъп от час работа на който и да е сървър.
• Хората правят грешки. Следователно могат да възникнат ситуации, когато тестовете са били изпълнявани на грешен клон или грешен комит е бил компилиран за тестери.
• Хората са мързеливи. От време на време, когато свърша задача, възниква мисълта: „Какво има за проверка? Написах два реда - всичко работи! Мисля, че някои от вас също понякога имат такива мисли. Но винаги трябва да проверявате.

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

Историята се основава на примера на Android команда, но повечето от подходите са приложими и на iOS.

Имало едно време един човек работеше в екипа на Avito Android. По дефиниция той не се нуждаеше от нищо от непрекъснатата интеграция: нямаше с кого да се интегрира.

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

Концепцията на потока на Git е добре известна: един проект има един общ клон за разработка и за всяка нова функция разработчиците изрязват отделен клон, ангажират се с него, натискат и когато искат да слеят кода си в клона за разработка, отварят заявка за изтегляне. За споделяне на знания и обсъждане на подходи въведохме преглед на кода, тоест колегите трябва да проверяват и потвърждават кода на другия.

проверки

Да видите код с очите си е страхотно, но не е достатъчно. Затова се въвеждат автоматични проверки.

• На първо място проверяваме ARK монтаж.
• Много Junit тестове.
• Разглеждаме покритието на кода, тъй като провеждаме тестове.

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

Тя може да бъде представена схематично така:

• Разработчик пише код на своя лаптоп. Можете да изпълнявате проверки за интеграция точно тук - или с кука за ангажиране, или просто да изпълнявате проверки във фонов режим.
• След като разработчикът натисне кода, той отваря заявка за изтегляне. За да може неговият код да бъде включен в клона за разработка, е необходимо да се премине през преглед на кода и да се съберат необходимия брой потвърждения. Можете да активирате проверки и компилации тук: докато всички компилации не са успешни, заявката за изтегляне не може да бъде обединена.
• След като заявката за изтегляне бъде обединена и кодът е включен в разработката, можете да изберете удобно време: например през нощта, когато всички сървъри са свободни, и да изпълните колкото искате проверки.

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

Наистина ни хареса да провеждаме проверки през нощта, защото има много време и сървъри, можете да се разхождате наоколо. Но, за съжаление, когато кодът на функцията влезе в разработката, разработчикът има много по-малко мотивация да поправи грешките, които CI откри. Периодично се улавях да си мисля, когато разглеждах всички открити грешки в сутрешния отчет, че ще ги поправя някой ден по-късно, защото сега има страхотна нова задача в Jira, която просто искам да започна да правя.

Ако проверките блокират заявка за изтегляне, тогава има достатъчно мотивация, защото докато компилациите не станат зелени, кодът няма да влезе в разработката, което означава, че задачата няма да бъде завършена.

В резултат на това избрахме следната стратегия: изпълняваме максималния възможен набор от проверки през нощта и стартираме най-критичните от тях и, най-важното, най-бързите при заявка за изтегляне. Но ние не спираме дотук – успоредно с това оптимизираме скоростта на проверките, така че да ги прехвърлим от нощен режим към проверки за изтегляне на заявки.

По това време всички наши компилации бяха завършени доста бързо, така че ние просто включихме компилацията на ARK, тестовете на Junit и изчисленията на покритието на кода като блокер за заявката за изтегляне. Включихме го, обмислихме го и изоставихме кодовото покритие, защото смятахме, че не ни е необходимо.

Отне ни два дни, за да настроим напълно основния CI (по-нататък оценката на времето е приблизителна, необходима за мащаба).

След това започнахме да мислим по-нататък - дори проверяваме ли правилно? Правилно ли изпълняваме компилации на заявки за изтегляне?

Започнахме изграждането на последния комит на клона, от който беше отворена заявката за изтегляне. Но тестовете на този комит могат само да покажат, че кодът, който разработчикът е написал, работи. Но те не доказват, че не е счупил нищо. Всъщност трябва да проверите състоянието на клона за разработка, след като дадена функция бъде обединена в него.

За да направим това, написахме прост bash скрипт premerge.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

Тук всички най-нови промени от development просто се изтеглят и се сливат в текущия клон. Добавихме скрипта premerge.sh като първа стъпка във всички компилации и започнахме да проверяваме какво точно искаме, т.е. интеграция.

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

Приложението се разви, появиха се все повече задачи, екипът се разрасна и premerge.sh понякога започна да ни разочарова. Develop имаше противоречиви промени, които нарушиха компилацията.

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

Двама разработчици едновременно започват да работят върху функции A и B. Разработчикът на функция A открива неизползвана функция в проекта answer() и като добър скаут го премахва. В същото време разработчикът на функция B добавя ново извикване към тази функция в своя клон.

Разработчиците завършват работата си и отварят заявка за изтегляне едновременно. Компилациите се стартират, premerge.sh проверява и двете заявки за изтегляне относно последното състояние на разработка - всички проверки са зелени. След това заявката за изтегляне на функция A се обединява, заявката за изтегляне на функция B се обединява... Бум! Прекъсвания в разработката, защото кодът за разработка съдържа извикване на несъществуваща функция.

Когато няма да се развива, е така местно бедствие. Целият екип не може да събере нищо и да го изпрати за тестване.

Така се случи, че най-често работех върху инфраструктурни задачи: анализи, мрежа, бази данни. Тоест, аз бях този, който написа тези функции и класове, които другите разработчици използват. Поради това много често попадах в подобни ситуации. Дори имах тази снимка да виси известно време.

Тъй като това не ни устройваше, започнахме да проучваме варианти как да предотвратим това.

Как да не се счупи развива

Първият вариант: възстановява всички заявки за изтегляне при актуализиране на разработката. Ако в нашия пример заявката за изтегляне с функция A е първата, която е включена в разработката, заявката за изтегляне на функция B ще бъде преустроена и съответно проверките ще бъдат неуспешни поради грешка при компилация.

За да разберете колко време ще отнеме това, разгледайте пример с два PR. Отваряме два PR: две компилации, две изпълнения на проверки. След като първият PR се слее в development, вторият трябва да бъде изграден отново. Общо два PR изискват три проверки: 2 + 1 = 3.

По принцип е добре. Но ние погледнахме статистиката и типичната ситуация в нашия екип беше 10 отворени PR, а след това броят на проверките е сумата от прогресията: 10 + 9 +... + 1 = 55. Тоест, да приемем 10 PRs, трябва да възстановите 55 пъти. И това е в идеална ситуация, когато всички проверки преминават от първия път, когато никой не отваря допълнителна заявка за изтегляне, докато тези дузина се обработват.

Представете си себе си като разработчик, който трябва пръв да щракне върху бутона „сливане“, защото ако съсед направи това, тогава ще трябва да изчакате, докато всички компилации преминат отново... Не, това няма да работи , ще забави сериозно развитието.

Втори възможен начин: събирайте заявки за изтегляне след преглед на кода. Тоест отваряте заявка за изтегляне, събирате необходимия брой одобрения от колеги, коригирате каквото е необходимо и след това стартирате компилациите. Ако са успешни, заявката за изтегляне се обединява в development. В този случай няма допълнителни рестарти, но обратната връзка е силно забавена. Като разработчик, когато отворя заявка за изтегляне, веднага искам да видя дали ще работи. Например, ако тестът е неуспешен, трябва бързо да го поправите. В случай на забавено изграждане, обратната връзка се забавя, а следователно и цялото развитие. Това също не ни устройваше.

В резултат на това остана само третият вариант - велосипед. Целият наш код, всички наши източници се съхраняват в хранилище на сървъра Bitbucket. Съответно трябваше да разработим плъгин за Bitbucket.

Този плъгин отменя механизма за обединяване на заявки за изтегляне. Началото е стандартно: PR се отваря, всички сборки се стартират, прегледът на кода е завършен. Но след като прегледът на кода приключи и разработчикът реши да щракне върху „обединяване“, приставката проверява спрямо кое състояние на разработка са извършени проверките. Ако разработката е актуализирана след компилациите, плъгинът няма да позволи такава заявка за изтегляне да бъде обединена в основния клон. Той просто ще рестартира компилациите на сравнително скорошна разработка.

В нашия пример с противоречиви промени, такива компилации ще се провалят поради грешка при компилиране. Съответно, разработчикът на функция B ще трябва да коригира кода, да рестартира проверките, след което плъгинът автоматично ще приложи заявката за изтегляне.

Преди да внедрим този плъгин, изчислихме средно 2,7 рецензии на заявка за изтегляне. С плъгина имаше 3,6 стартирания. Това ни устройваше.

Струва си да се отбележи, че този плъгин има недостатък: той рестартира компилацията само веднъж. Тоест все още има малък прозорец, през който могат да се развият противоречиви промени. Но вероятността за това е ниска и ние направихме този компромис между броя на стартиранията и вероятността от неуспех. За две години стреля само веднъж, така че вероятно не е било напразно.

Отне ни две седмици, за да напишем първата версия на плъгина Bitbucket.

Нови чекове

Междувременно екипът ни продължи да расте. Добавени са нови проверки.

Помислихме си: защо да правим грешки, ако могат да бъдат предотвратени? И затова го внедриха анализ на статичен код. Започнахме с lint, който е включен в Android SDK. Но по това време той изобщо не знаеше как да работи с кода на Kotlin и вече имахме 75% от приложението, написано на Kotlin. Затова към мъхчетата бяха добавени вградени Проверки на Android Studio.

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

Също така през това време започнахме да пишем много инструментални тестове и изпълнени тестване на скрийншот. Това е, когато се генерира референтна екранна снимка за отделен малък изглед и тестът се състои в правене на екранна снимка от изгледа и сравняването й със стандарта директно пиксел по пиксел. Ако има разминаване, това означава, че оформлението е сбъркано някъде или нещо не е наред в стиловете.

Но инструменталните тестове и тестовете за екранни снимки трябва да се изпълняват на устройства: на емулатори или на реални устройства. Като се има предвид, че има много тестове и те се провеждат често, трябва цяла ферма. Стартирането на собствена ферма е твърде трудоемко, затова намерихме готов вариант – Firebase Test Lab.

Тестова лаборатория на Firebase

Беше избран, защото Firebase е продукт на Google, което означава, че трябва да бъде надежден и малко вероятно някога да умре. Цените са разумни: $5 на час работа на реално устройство, 1 $ на час работа на емулатор.

Отне около три седмици, за да внедрим Firebase Test Lab в нашия CI.

Но екипът продължи да расте и Firebase, за съжаление, започна да ни разочарова. По това време той нямаше SLA. Понякога Firebase ни накара да изчакаме необходимия брой устройства да бъдат свободни за тестове и не започна да ги изпълнява веднага, както искахме. Чакането на опашка отне до половин час, което е много дълго време. Тестовете на инструментите бяха пуснати на всеки PR, забавянията наистина забавиха развитието и тогава месечната сметка дойде с кръгла сума. Като цяло беше решено да се изостави Firebase и да се работи вътрешно, тъй като екипът беше нараснал достатъчно.

Docker + Python + bash

Взехме Docker, напълнихме емулатори в него, написахме проста програма на Python, която в точното време стартира необходимия брой емулатори в правилната версия и ги спира, когато е необходимо. И, разбира се, няколко bash скрипта - къде щяхме да сме без тях?

Отне пет седмици, за да създадем собствена тестова среда.

В резултат на това за всяка заявка за изтегляне имаше обширен списък с проверки за блокиране на сливане:

• ARK монтаж;
• Junit тестове;
• мъх;
• Проверки на Android Studio;
• Инструментални тестове;
• Тестове за екранни снимки.

Това предотврати много възможни повреди. Технически всичко работи, но разработчиците се оплакаха, че чакането на резултатите е твърде дълго.

Колко дълго е твърде дълго? Качихме данни от Bitbucket и TeamCity в системата за анализ и разбрахме това средно време за изчакване 45 минути. Това означава, че разработчикът, когато отваря заявка за изтегляне, чака средно 45 минути за резултатите от компилацията. Според мен това е много и не можете да работите така.

Разбира се, решихме да ускорим всичките си компилации.

Да ускорим

Виждайки, че компилациите често стоят на опашка, първото нещо, което правим, е купих още хардуер — екстензивното развитие е най-простото. Компилациите спряха да стоят на опашка, но времето за изчакване намаля съвсем леко, тъй като някои проверки отнеха много дълго време.

Премахване на проверки, които отнемат твърде много време

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

• Няма да го направя. CI може да улови грешка при компилиране, когато нещо не се компилира поради противоречиви промени. Както вече казах, тогава никой не може да сглоби нищо, развитието спира и всички се изнервят.
• Грешка в поведението. Например, когато приложението е изградено, но се срива, когато натиснете бутон, или бутонът изобщо не е натиснат. Това е лошо, защото такъв бъг може да достигне до потребителя.
• Грешка в оформлението. Например, бутон е щракнат, но се е преместил с 10 пиксела наляво.
• Увеличаване на техническия дълг.

След като разгледахме този списък, разбрахме, че само първите две точки са критични. Първо искаме да хванем такива проблеми. Грешките в оформлението се откриват на етапа на преглед на дизайна и могат лесно да бъдат коригирани след това. Справянето с технически дълг изисква отделен процес и планиране, така че решихме да не го тестваме при заявка за изтегляне.

Въз основа на тази класификация разтърсихме целия списък от проверки. Зачеркнат мъх и отложи стартирането му за една нощ: само за да изготви доклад колко проблеми има в проекта. Договорихме се да работим отделно с техническия дълг и Проверките на Android Studio бяха напълно изоставени. Android Studio в Docker за провеждане на проверки звучи интересно, но причинява много проблеми при поддръжката. Всяка актуализация на версиите на Android Studio означава борба с неразбираеми грешки. Също така беше трудно да се поддържат тестове за екранни снимки, тъй като библиотеката не беше много стабилна и имаше фалшиви положителни резултати. Тестовете за екранни снимки са премахнати от списъка за проверка.

В резултат на това ни останаха:

• ARK монтаж;
• Junit тестове;
• Инструментални тестове.

Отдалечен кеш на Gradle

Без тежки проверки всичко стана по-добро. Но няма ограничение за съвършенството!

Нашето приложение вече беше разделено на около 150 модула gradle. Отдалеченият кеш на Gradle обикновено работи добре в този случай, така че решихме да го изпробваме.

Отдалеченият кеш на Gradle е услуга, която може да кешира артефакти за изграждане за отделни задачи в отделни модули. Gradle, вместо всъщност да компилира кода, използва HTTP, за да почука на отдалечения кеш и да попита дали някой вече е изпълнил тази задача. Ако да, той просто изтегля резултата.

Изпълнението на отдалечен кеш на Gradle е лесно, защото Gradle предоставя Docker изображение. Успяхме да го направим за три часа.

Всичко, което трябваше да направите, беше да стартирате Docker и да напишете един ред в проекта. Но въпреки че може да се стартира бързо, ще отнеме доста време, за да работи всичко добре.

По-долу е графиката на пропуските в кеша.

В самото начало процентът на пропуските в кеша беше около 65. След три седмици успяхме да увеличим тази стойност до 20%. Оказа се, че задачите, които Android приложението събира, имат странни транзитивни зависимости, поради което Gradle пропуска кеша.

Свързвайки кеша, ние значително ускорихме изграждането. Но освен сглобяването, има и тестове на апаратура, а те отнемат много време. Може би не е необходимо да се изпълняват всички тестове за всяка заявка за изтегляне. За да разберем, използваме анализ на въздействието.

Анализ на въздействието

При заявка за изтегляне събираме git diff и намираме модифицираните Gradle модули.

Има смисъл да се изпълняват само тестове на инструментите, които проверяват променените модули и всички модули, които зависят от тях. Няма смисъл да се правят тестове за съседни модули: кодът там не е променен и нищо не може да се счупи.

Инструменталните тестове не са толкова прости, защото трябва да се намират в модула за приложения от най-високо ниво. Използвахме евристика с анализ на байт код, за да разберем към кой модул принадлежи всеки тест.

Модернизирането на работата на тестовете на инструментите, така че те да тестват само включените модули, отне около осем седмици.

Мерките за ускоряване на проверките са работили успешно. От 45 минути стигнахме до около 15. Вече е нормално да чакате четвърт час за изграждане.

Но сега разработчиците започнаха да се оплакват, че не разбират кои компилации се стартират, къде да видят дневника, защо компилацията е червена, кой тест е неуспешен и т.н.

Проблемите с обратната връзка забавят развитието, затова се опитахме да предоставим възможно най-ясна и подробна информация за всеки PR и билд. Започнахме с коментари в Bitbucket към PR, като посочихме коя компилация се е провалила и защо, и написахме целеви съобщения в Slack. В крайна сметка създадохме табло за PR за страницата със списък на всички компилации, които се изпълняват в момента, и техния статус: на опашка, работещ, сринат или завършен. Можете да щракнете върху компилацията и да стигнете до нейния дневник.

Шест седмици бяха изразходвани за подробна обратна връзка.

Планове

Да преминем към най-новата история. След като решихме проблема с обратната връзка, достигнахме ново ниво - решихме да изградим собствена ферма за емулатори. Когато има много тестове и емулатори, те са трудни за управление. В резултат на това всички наши емулатори се преместиха в клъстера k8s с гъвкаво управление на ресурсите.

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

• Върнете мъх (и друг статичен анализ). Вече работим в тази посока.
• Пуснете всичко на PR блокер тестове от край до край на всички версии на SDK.

И така, проследихме историята на развитието на непрекъснатата интеграция в Avito. Сега искам да дам няколко съвета от опитна гледна точка.

Советы

Ако мога да дам само един съвет, той би бил следният:

Моля, внимавайте с шел скриптовете!

Bash е много гъвкав и мощен инструмент, много е удобен и бърз за писане на скриптове. Но можете да попаднете в капан с него и, за съжаление, ние попаднахме в него.

Всичко започна с прости скриптове, които се изпълняваха на нашите компилиращи машини:

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

Но, както знаете, всичко се развива и става по-сложно с течение на времето - нека стартираме един скрипт от друг, нека предадем някои параметри там - в крайна сметка трябваше да напишем функция, която определя на какво ниво на bash влагане сме сега, за да да вмъкнете необходимите кавички, за да започне всичко.

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

Какво може да бъде заменено?

• Всеки скриптов език. Пиши на Скрипт на Python или Kotlin по-удобно, защото е програмиране, а не скриптове.
• Или опишете цялата логика на изграждане във формуляра Персонализирани задачи за gradle за вашия проект.

Решихме да изберем втората опция и сега систематично изтриваме всички bash скриптове и пишем много персонализирани градски задачи.

Съвет #2: Съхранявайте инфраструктурата в код.

Удобно е, когато настройката за непрекъсната интеграция се съхранява не в UI интерфейса на 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.

Двете основни причини, поради които това има смисъл, са мащабируемостта и повторяемостта. Използвайки docker, можете бързо да създадете дузина агенти за изграждане, които ще имат точно същата среда като предишната. Това прави живота на CI инженерите много по-лесен. Доста лесно е да поставите android-sdk в докер, но с емулаторите е малко по-трудно: ще трябва да работите малко повече (или да изтеглите готовия от GitHub отново).

Съвет № 4: не забравяйте, че проверките не се правят заради тях, а за хората.

Бързата и най-важното ясна обратна връзка е много важна за разработчиците: какво се е счупило, кой тест е неуспешен, къде мога да видя buildlog.

Съвет #5: Бъдете прагматични, когато разработвате непрекъсната интеграция.

Ясно разберете какви видове грешки искате да предотвратите, колко ресурси, време и компютърно време сте готови да отделите. Проверките, които отнемат твърде много време, могат например да бъдат отложени за една нощ. И тези от тях, които улавят не много важни грешки, трябва да бъдат напълно изоставени.

Съвет #6: Използвайте готови инструменти.

Сега има много компании, които предоставят облачен CI.

Това е добро решение за малки екипи. Не е необходимо да поддържате нищо, просто платете малко пари, създайте своето приложение и дори изпълнете тестове на инструментите.

Съвет #7: В голям екип вътрешните решения са по-печеливши.

Но рано или късно, с нарастването на екипа, вътрешните решения ще станат по-печеливши. Има един проблем с тези решения. В икономиката има закон за намаляващата възвръщаемост: във всеки проект всяко следващо подобрение е все по-трудно и изисква все повече инвестиции.

Икономиката описва целия ни живот, включително непрекъснатата интеграция. Изградих график на разходите за труд за всеки етап от развитието на нашата непрекъсната интеграция.

Ясно е, че всяко подобрение става все по-трудно. Разглеждайки тази графика, можете да разберете, че непрекъснатата интеграция трябва да се развива в съответствие с нарастването на размера на екипа. За екип от двама души прекарването на 50 дни в разработването на вътрешна емулаторна ферма е посредствена идея. Но в същото време, за голям екип изобщо да не се прави непрекъсната интеграция също е лоша идея, защото проблеми с интеграцията, коригиране на комуникация и т.н. ще отнеме още повече време.

Започнахме с идеята, че е нужна автоматизация, защото хората са скъпи, правят грешки и са мързеливи. Но хората също автоматизират. Следователно всички същите проблеми се отнасят за автоматизацията.

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

Но имам статистика: грешките се улавят в 20% от сборките. И това не е защото нашите разработчици пишат код лошо. Това е така, защото разработчиците са уверени, че ако направят някаква грешка, тя няма да попадне в разработката, а ще бъде уловена от автоматизирани проверки. Съответно разработчиците могат да отделят повече време за писане на код и интересни неща, вместо да изпълняват и тестват нещо локално.

Практикувайте непрекъсната интеграция. Но в умерени количества.

Между другото, Николай Нестеров не само прави страхотни доклади, но и е член на програмния комитет AppsConf и помага на другите да подготвят смислени речи за вас. Пълнотата и полезността на програмата на следващата конференция може да се оцени по теми в график. А за подробности заповядайте в Infospace на 22-23 април.

Източник: www.habr.com