Моля, споделете опит от ползване на AUTOMATED BUILD.
Оценявате ли предимствата, за какви проекти го ползвате, ...
Препоръчайте подходящ обзор

Благодаря!

Викаме му continuous integration (CI) - сигурно за него говориш, или по-скоро за част от него.
Аз ползвам и вече многократно хваля TeamCity на jetbrains - за мен е страхотно направен инструмент и е далеч по-удобен от класиката jenkins. Който не го е пробвал, той не го е харесал
Има си много глезотии, но в зависимост от познанията ти по темата може да ти отнеме време да ги откриеш/разбереш/оцениш.
Ако искаш, пиши какъв ти е процеса на работа - екип, сорс контрол, тестване, release-ване, как доставяш на "клиентите", как получаваш "задачите" и ще опитам да кажа какво съм открил и как го ползвам.

Благодаря, дори самото поставяне на тези въпроси е голяма крачка

Това ==> изречение го пиша накрая - по-долу обяснението е много разпиляно, мисля, че целият проблем е в общата ми организация - не знам дали има такава среда, която да се справи с това


Ние сме малка фирмичка, общо 5-6 човека, 2.5 програмисти, при необходимост ползваме посточнни външни подизпълнители.
За ембедед имаме собствен апаратнонезависим фреймурк и HAL части адаптирани за различни процесори (ST, Atmel, Microchip, ...).
Ползваме TortoiseSVN.
С клиентите, които се отнасят сериозно, комуникираме с Mantis.

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

Хубаво е че имате поне SVN, макар се съвременните инструменти работят по-добре с гит (не че старите са били наобратно - просто "старите" не са имали нужда от кой знае какво - концепцията "ми ще го пускаме нощем/почивните дни" не изисква кой знае колко).
Понеже не съм много добър в "преподаването", ще ти препоръчам да прочетеш за CI системите и каква е концепцията - знаейки целите, т.е. виждайки цялата картинка, ще ти е лесно да разбереш защо определени неща се правят по даден начин. Има една книжка на един пич от дивизията за принтери (laser jet) на HP, която е много зарибяваща - ама не се сещам кое къде беше - ако я намеря ще я постна.
Та, каква е идеята - искаме да слгобим накрая един продукт - наричаме го "фирмуер". Може да е цялостен продукт, т.е. комплект от фирмуер, хардуер, документация, сертификати и прочие, но за простота гледаме само софтуера.
Този фирмуер трябва да го разделим на части - тъй де, той вече е разделен на такива - библиотеки (компоненти), интеграции на тия компоненти в продукт. Да приемем че вече имаме правилно разделени софтуерни компоненти - т.е. множество "репозитори"-та за всеки компонент (на свн-а, или на гит, или ...). Т.е. имаме 1 компонент <-> 1 репо (URL). Това репо става един проект в нашия билд сървър (т.е. бягаме от варианта "един проект ползва 10 репота, събира сорса и билдва нещо голямо" - това е важно).
При правилна организация се оказва че тоя проект няма как да го билднеш - липсват ти неговите "зависимости" - други компоненти, които той ползва. Тук идва още една важна точка - не се изкушавай да ползваш примерно svn externals за да си "доставиш" външни файлове (от други репозиторита/компоненти). Това се решава на ниво билд инструменти - т.е. ползват се екстрите на билд сървъра (teamcity) да ни ги докарат.
Разделянето на малки и самостоятелни (single responsibility) компоненти/сорсове помага за "бързи" билдове - при CI се гони постановката билдването да се случва само когато има нужда, т.е. когато има промяна в кода (т.е. само след commit от някой девелопер). Никакви "нощни" или ръчно стартирани билдове - в момента в който напишеш "нещото" и го качиш в svn-а билд сървъра трябва да види промяната и да "запали". Затова споменах че svn е малко тромав - проверките за промени (polling) са по-тежки (товарят svn сървъра) и бавни, а сигнализирането наобратно - svn сървъра да се обажда на билд сървъра, т.е. server side hook, иска да има административен достъп до сървъра и е по-трудно, отколкото в една gitlab, gitea, bitbucket, ... и подобни.
Но, все пак, значи качваш нова ревизия, и едно малко проектче - билда на библиотеката ти за modbus примерно, затичва (билдва се). Това иска "environment" (където тичат компилаторите, променливи, sysroot и т.н.), но на него ще се върнем по-късно - засега да кажем че билдваш все за stm32 някакъв и не го мислиш - настроил си тоя компилатор и билда вади libmodbus.a файл.
Тук свършва проекта за този компонент (modbus библиотеката) - в този проект не мислиш за други - за HMI дисплея дето ще произвеждаш и в него ще имаш тая библиотека - това е извън репо-то на libmodbus, няма го и в билд сървър проекта с име "libmodbus" - изходът на проекта е "libmodbus.a" (и хедъри, примерно).
Имаш следващ проект, отново със собствено репо, който се казва примерно "myHMI" - има си собствени сорсове, но на тях за да се билдне/линкне му трябва оня libmodbus.a и хедъра му. На ниво билд сървър (CI система) си има и се ползват механизми за "dependencies". Т.е. в проекта "myHMI" имаш описано репото "svn://myHMI", но и отделно има и описано, че от друг проект с име "libmodbus" трябва да се вземе артифакт с име libmodbus.a - проектът myHMI не знае че тоя "артифакт" (т.е. изход от друг проект) се е получил чрез билд от някакви сорсове - за него е готов файл и просто има референция към него.
Когато commit-неш в libmodbus, щото си оправил бъг примерно, се започва нов билд - билд сървъра вижда че има промяна и почва да билдва (примерно вика make) и след края на make му е казано да обяви за изход (артифакт) файла libmodbus.a (дето го е изкарал make-а). В проекта myHMI имаш място да опишеш от какви си зависим - какво ти трябва, за да свършиш работата (която е да изкараш myHMI.exe примерно). Когато обявиш тази зависимост/връзка, свестните CI системи си правят "едно наум" и почват да дебнат - ако някой от проектите описани като зависимости (libModbus) се обади че е билднал нова версия на файла "libmodbus.a", то билд сървъра взима тоя файл и го прехвърля в другия проект (myHMI), след което пуска наново билд на myHMI, за да извади myHMI.exe.
На това му се вика build chain, или build pipeline. Описва се с въздесъщия насочен ацикличен граф (DAG).
Ако някой качи в другото репо - на myHMI, примерно hmi.c, също ще започне билд - само че в този случай ще се билдне само myHMI репото - няма да има нужда от ребилдване на libmodbus. Логично звучи, но няма да повярваш колко други билд сървъри не го могат...
Има и друго (обратното) - ако качиш в libmodbus.c нещо, ама това нещо е в коментар в кода или някъде, дето компилатора го маха (мъртъв код), е много вероятно излезлия файл libmodbus.a да не се смени изобщо (като хеш), съответно умните системи ще кажат "готово" - без да пускам наново билда на следващите myHMI. Да отворя скоба - ако libmodbus.a се сменя без да има промяна в сорса, значи сме омазали нещо - много има изписано по тоя проблем, и много често той възниква защото някой е решиш да вгради датата и часа на билда в сорса (за някакъв принт примерно) - това е принципно грешно и трябва да се маха от кода - такава идентификация трябва да носи само ревизия/хеш на кода, никога дата/час на билда. Някой билд системи (примерно ptxdist за линукс) използва трикове, за да решат тоя проблем - ползват един пакет наречен faketime, чрез който лъжат компилатора и инструментите "колко е часа" - винаги му дават някакво константно време/дата.

Има и други особености - това, което описах по-горе е доста прост "граф" - по-сложно става, когато имаш няколко HMI-панела примерно, единия с линукс, другия с виндоус, третия без нищо (примерно stm32), и всички тия, разбира се, трябва да преизползват твоя libmodbus проект. По възможност - без да пипаш в репо-то на либмодбъс, а, когато хванеш техниките на CI, няма да се налага да пипаш и в билд проекта на libmodbus - така ще си подготвил нещата, че извън проекта ще можеш да накараш libmodbus да излезе за arm, за x86-win и за други дивотии. Т.е. графа може да се разклонява след libmodbus - към "вин", "линукс" и "стм". Отделно, може да искаш да изкараш различни фирмуери за различни "варианти" - примерно за "low–cost_stm32_HMI.hex" и друг - "high_end_full_blown_stm32_HMI.hex".
Очаква се че като ти се обадят че модбъса нещо не баца и си намерил проблема, ти отваряш сорса и пляскаш по главата - ей тука трябваше да е "5", сменяш го и комит-ваш. Дигаш краката, пиеш едно кафе и след няколко минути имаш няколко хекса, дето ги пращаш (за тестване, или направо на клиента да флаши) - CI система се е "тригерирала" по комит-а ти и е изкарал всички нови хексове, екзета и т.н.
В хубавата (ама имагинерна) реалност тия хексове са минали през няколко теста, и се е генерирал ласкателен тест протокол тип "цветя и рози" - т.е. като глътнеш кафето, те чака всите хексове, протоколи и т.н. Ходиш за една вафла и си гледаш кефа.

Другите екстри идват от самосебе си - обадил ти се е клиента за оная "5"-ца, ти си комитнал, кафето си е супер, ама цъфва е-mail - проекта ХХХ за някакъв индустриален контролер с модбъс е гръмнал (билда или теста). Пак пляскаш главата, сещаш се че имало и такова устройство, и то също ползвало libmodbus, и в някакъв момент се сещаш че оня ми ти контролер хич няма как да работи с "5", иска максимум 4, щото е чепат. Евентуално намираш решение, комитваш пак, и след няколко минути всичко се е билднало успешно - спокоен пращаш и отиваш за нещо по-силно от кафето. Т.е. избягваш сценария, в който след година шефа идва и казва - "дай ми хекс за ХХХ че клиента е закъсал и съм го спазарил да кихnе яко". Добре, ще билдна - ааа, то не се билдва, има една "5"-ца, има още 789 промени, дето трябва да се оправят преди тоя проект да се билдне пак... Оправдаваш се "ама нали го бяхме спрели тоя продукт...", но парите са си пари и шефа вежливо ти предлага да спиш в офиса няколко седмици че да може да си вземе новата жипка.

Edit: това е публичен сървър на teamcity - за мен беше интересно да разгледам различни проекти:
https://teamcity.jetbrains.com/

мдаа... какви ли не неща му идват на човек в петък вечер
gicho, ако пък поста ти е сериозен то тогава имам два въпроса:
1. Колко време отнема билд, пълен ребилд, на проект при теб? Дай някакъв пример.
2. Колко души работят по този проект? Колко души къмитват към репозиторитата от които се сглобява проекта.

CI не е задължително да бъде напълно "automated" нали? По-важното е да continuous и integrated.

Къмитване към репозитори НЕ БИВА да е твърдо обвързано с билдване. Камо ли с билдване на сет от рилийз байнърита, които някой менажер да засилва към клиентите.
Всички опити за подобни CI, които съм виждал са едни каши забъркани и при това все недовършени(защо ли).
Така че... анатема, нека хората да са спокойни, че като къмитнат нещо, няма да засилят цялата машинария.

Отнема според ... различно. Пълен ембедед линукс релийз излиза след около 2 часа (ако няма "задръстване" по билд агентите, но такива рядко се случват, щото не се билдва по разписание, ами на промяна) - това включва всичко - бутлоадър, кърнел, rootfs, в който влизат няколко десетки библиотеки и изпълними файлове. Оптимистично - по няколко минути, има и такива, който са готови 20-тина секунди след комит-а. Сещаш се, че бутлоадър и кърнел билдваме много рядко - така че тия два часа ги виждам веднъж в годината. Да не говорим, че не приемам за нормално дадена билд система да има нужда от clean - това показва че тя има бъг (след като се дъни на инкрементален такъв и иска почистване). В тоя случай лека-полека тая система изчезва и се подменя с друга, която дава гаранции за работата си. Така например платформата, дето ни прави rootfs-ите, и бяха орязани правомощията и сега само пакетира билд-нати извън нея артифакти - преди това билдваше тях като нейни проекти, но никак не се справяше да открива кое и дали е променено, и ни принуждаваше да правим винаги пълно почистване.
Колко народ - макс 4-5 глави, но рядко повече от 2-ма работят върху един и същи "проект" (примерно библиотека някаква).
Комит-и - рядко са повече от 10-тина на ден, често има и седмици без комит в даден компонент. Но комит-ването в някой базов компонент често може да вкара наведнъж билд на 40 проекта след него - който са обявили че го ползват. Имай предвид, че всичко се цепи на малки репо-та, връзките между които са явно указани и разписани като build dependencies в teamcity и то знае кое на кого влияе, и кой какъв точно вид иска. Т.е. при комит в някой проект teamcity вижда кой следващи по чейн-а я ползват тая библиотека, и от тия следващите се връща обратно (reverse.dep му викат) "изисквания". Т.е. ако направя нов изпълним фирмуер, и в него искам да ползвам нов компилатор/архитектура, е достатъчно да подам обратно към libmodbus име на обкръжение, в което да си намери подходящото gcc (т.е. да му дефинирам cross compile). Така, без да пипам libmodbus, имайки неговия makefile базиран на CC/CXX/..., мога да си "поискам" билд за произволна архитектура (е, стига да има подходящо gcc/llvm за нея). Хитрото е, че ако има 10 продукта (фирмуера), от които 5 ползват един компилатор, и останалите 5 друг, то teamcity ще направи само два билда - по един с всеки уникален компилатор, и ще резултата ще го подаде на 5-те. Хитро?
CI трябва да е автоматично - най-малкото, защото е шантаво да имаш всичко подготвено да тича автоматично, и умишлено "да прекъснеш" веригата - какво печелиш? Това "неавтоматично" ползване може да е индикация, че нещо в тоя процес има нужда някой да свърши нещо ръчно - например да въведе стойност на параметър за билда. А това означава, че може и да не го въведе, и да го сбърка, и ...
Комит-ването е задължително обвързано с билд, в смисъла че билда е първия тест, с който се сблъсква новото творение. Разбира се, това е абсолютния минимум - винаги след билда тръгват и тестове с новоизлюпената версия. Ако имаш предвид че билд вече си направил на твоето пц преди комита, това е недостатъчно - не може да се има доверие на този билд по много причини:
- няма гаранция, че каквото си билднал, си го качил после
- няма гаранция, че каквото си качил, си го билднал преди това
- няма гаранция, че си билднал всички конфигурации и всички зависими проекти - такива, в които участва твоя код/проект - в примера горе, една библиотека може да участва в билда на десетки други; онези от laserjet на HP казват, че при откриване на счупен билд или тест репотата се замразяват - никой не може да качва докато не се върне "зеления" статус; ако това не се направи може да влязат още 50 комита от други разработчици и нещата стават дебели
- обкръжението, в което билдваш на твоя компютър, е "нестабилно" или негарантирано - минал ъпдейт на виндоуса, на някой инструмент, някой решил да качи или смъкне версията на cmake примерно, да сложи .... съответно, обкръжението, в което се билдва на билд сървъра е гарантирано - докер контейнер, vagrant виртуална машина или подобни - все неща (обкръжения), който са описани декларативно (dockerfile, vagrantfile), и които сами по себе си се билдват все едно са код - при мен си има репота с текстови dokerfile-ове, например arm-none-gcc под дебиан; тия репота са закачени към билд проекти (все едно са сорсове), тия билд проекти са конфигурирани да билдват контейнери от докерфайловете - като комит-на в докерфайла нещо се билдва нова версия на контейнера, която се ползва от билдовете; всеки билд си пише с кой контейнер е вървял - гарантирано мога да повторя билда във съвсем същото обкръжение (това цялото се вика "Infrastructure As A Service" подход)
- билда на твоето пц не изпълнява изискванията за проследимост - нямаш стриктна система, която да ти гарантира че артифакта е от еди коя си версия на сорса, че е билднат с еди какви си променливи на обкръжението - не е ясно дали можеш да го повториш същия след време

Сет от релийз бинарита билдвам, но не ги давам (все още) на клиентите - това би било Continuous Deployment, и е малко страховито в нашата област. Но в web услугите е масова практика. При мен тия бинарита са просто "рилийз кандидати", които се дават на QA отбора да ги тества интеграционно. Ако те дадат успешен протокол го засилвам да му бият парафите. Самите QA играчи също се стараят да следват системата с автоматичен тест - т.е. да влязат като стъпка в процеса.
Често ми се случва да кажат "трябва да сменим еди какво си, след колко време ще го имаме? знаем, че, колкото и да е малка промяната, докато пуснеш да се билдва имиджа, че после да направиш разните скриптове и описания, все отнемаше по ден-два?" - и сега ми е голямо удоволствие да кажа "след 10 до 15 минути ще имаш линк да си вземеш новия пакет с промяната"... Изпадат в ступор, и питат "ама как става това"?

Моето впечатление е, че хората са "по-спокойни" когато знаят, че някой "бди" на тях. Разбира се, това е изпитание за тестовете - много вероятно е някой да почне да комит-ва без дори да билдне - "ама то нали машинарията ще се обади ако има проблем?". Т.е. нож с две остриета е и може да накара хората да не комитват със седмици и месеци, от страх. По-добре да засилят машинарията на билд сървърите, отколкото да прецакат работата на колегите си с неподходящ комит.
Машинарията е там точно за да работи, а не да бездейства. Конкретен случай - проект за билдване и тестване, преместен да билдва през нощта, "щото нямало нужда толкова често". Хубаво, ама девелопер прави нещо и комитва през деня. На сутринта телефоните зазвъняват, че някой си на майната си сме му счупили проекта с последния комит. Хубаво, ама човекът, който може да го оправи, съответния ден е отпускар...И деня, разбира се, е преди някакви наши празници, т.е. ония оттатък ще имат още няколко работни дни, в които ние няма да фиксираме нищо, и те ще имат оправдание, че ние сме забавили нещата. Човекът се връща след това, натискаме го да си оправи нещата, той поглежда, казва - ами да, аз го билднах един каква си конфигурация, те искат в друга, там счупено. И съвсем резонно той пита "Ама защо не съм получил информация за проблем?" Еми, щото спряхме една изградена и работеща автоматична система, и я забавихме.
Излишно е да казвам, че след това почнаха да се вслушват и да правят билдовете и тестовете "при комит". Просто дава по-своевременна информация.
Да не говорим, че ако хората правят проектите без мисълта за автоматичен тригер от сорс контрол, правят големи бози, и си казват - ще билдваме нощем, хубаво. Проектите стават примерно няколко стотин, някой от тестовете тичат много часове. Оказва се, че доката се изтъркалят нощем (да му дойде реда), минават седмици. Отделно, като си сложат "нощем", никой не се и сеща да мисли за оптимизация в смисъл "тоя тест няма нужда да го пускаме, защото нито фирмуера, нито тествите планове, са се сменили" - значи билдваме/тестваме многократно едно и също нещо - загубено време, което, ако всичко е на тригер от сорса, се използва по-ефективно.
Това е като да спорим дали event-базирано или polling да изграждаме системите...

Това, което teamcity има, и много му се радвам, се казва "pre-tested commit". Заключава се в това ти, като дивелопър, да поискаш "тайно" (частно) да се извърши тест на локалните ти промени, преди още да си ги качил. Можеш да направиш пач на промените, можеш (ако си на гит) да ги commit-неш без да пушваш, и да кажеш на teamcity "билдвай и тествай еди кой си проект". Той прехвърля пач-а до агента, който ще билдва (тайно, без минаване през сорс контрол сървъра), пуска целия процес - тайно (другите не го виждат дори в web интерфейса), и накрая ти казва "браво, всичко е на 6" - или "я виж там кво си омазал, че тогава пробвай пак". Като направиш 5 итерации и си го докарал до успех, можеш да го качиш. Ама оня ми ти вади още един коз от ръкава - като пускаш "частния" билд, ти показва една чавка да избереш по желание и тя пита "като ти направя тоя частен билд, ако мине успешно всичко, искаш ли направо да го пуш-на това?"

Бъзикаш ли ме? Аз си мисля, че даже сме изостанали. Доста от нашите "партньори" ползват такива системи и, доколкото имам достъп, съвсем добре се справят. Погледни оня линк към безплатния сървър - виж какви проекти вървят. Вярно е че повечето не са точно ембедед, и при нас предизвикателствата са повече, но това прави работата интересна.

Continuous в CI идва да рече "непрекъснат" - е това ако не значи автоматичен, здраве му кажи. Как така минава за "непрекъснат" процес, в който някой стои и трябва да направи нещо, ама може и да не го направи, ако го е страх? Не е ли "прекъсване" това да излезе кода в 09:45 и да се билдне след една "пауза" - до през нощта, или до следващия петък?

Много полезен за мен обзор.

Благодаря много !

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

Благодаря за препратките към TeamCity на jetbrains и към https://teamcity.jetbrains.com/

(струва ми се, че има и една неточна преценка : "Понеже не съм много добър в "преподаването"" , но я отдавам на високите ти критерии)

gicho,
Има няколко фактора от които зависи дали подобна система за CI ще е целесъобразно да бъде използвана в даден проект. Първите два фктора се покриват от двата ми въпроса, по-горе. Но по-важните са:
1. Какво е нивото на "узрялост"(maturity) на проекта. Т.е. дали правите нещо ново, близо до т.нар. "state of the art", или това е по-скоро вече продукт отколкото проект. И сте по-скоро в режим на поддръжка отколкото на развиване.
2. Каква е степента на хетерогенност(нееднородност) на проекта. Колко различни области допринасят(commit-ват) към един и същи проект.

Ако степента на хетерогенност е над определено ниво и "узрялоста" е под определено ниво, сещаш се ще имаш трудности да определиш зависимостите(dependencies) от които пък зависи CI автоматизацията да работи безотказно.

Като питах колко души къмитват, отговора зависи от това и тези глави дали мислят върху едно и също нещо. Например в предишния проект в който работих, от наша страна имаше около 200 души инженери. между 50 и 100 от тях правят по десетина къмита на ден. Сега си представям всеки от тези commit-и да задейства билд и тест.
Като казваш двама души при вас работят едновременно върху един и същи проект(най-често) това най-вероятно означава опитни инженери, които имат поглед върху цялата картинка(включително и билд системата). Проекта който ползвам за пример от тези 200 инженера едва една дузина имат поглед въху цялата картина. И предвид бързото развитие на проекта, вероятно двама-трима са наистина в час постоянно(continuously ).

Разбира се радвам се за вас, че сте го докарали до там. Но проектите в които съм участвал последните 3-4 години ме карат да не вярвам на автоматичен CI процес.
За сметка на това без автоматичен CI, сме го докарвали до постоянно работоспособен master/trunk. Е вярно че имахме 3-4 билд таргета и само един клиент. За 2 години сме направили и 2-3 fork-a от които да започнат проекти за други клиенти. Коренно различно от това което ти описваш, но пък при нас работеше. И за 2 години издънките се броят на половината пръсти на едната ми ръка, въпреки, че огромната част от работата беше ръчна. А имахме около 240 разнородни компонента, живеещи в отделни репо-та. Около 90% от тези компоненти бяха в развитие. Много малка част от тях сме ползвали без промяна от началото до края на проекта.

Надявам се това което пиша да не се възприема като заявка за спорене, което знам че ти е слабост.
Просто споделяме "опит от ползване" нали така? И естествено това че има "незрели" проекти не е взаимноизключващо се с това да има "узрели" такива.
От всичко което казваш не мога да приема твърдото задействане(trigger-иране) на билд и тест при всеки commit. Точно по причината, че винаги имам проблем с това че голяма част от колегите "се страхуват" да commit-ват. Защото commit-а е "официален". Мажат си на своите PC-та и дори не push-ват. И така нито знаеш какво точно правят, нито до къде са стигнали. А в един отбор е важно хората да споделят и да се кооперират. И една от целите на вершън контрол системите е именно средство за коопериране между хората които работят по едно и също нещо или за един и същи проект/продукт.

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


Е как така се е промъкнало? През целия автомат та чак до клиента?!? Разбрах, че това е било преди да въведете тригер на билд при всеки къмит, но това няма да се случи и ако някой не е засилил байнъритата към клиента.


Това важи за Пе-Це - то на някой девелопор, но не и за машината на интегратора на проекта. Разбира се въпрос на дисциплина и доколко водещия интегратор може да осигури на всеки интегрирана сглобка от версии на сорсове и инструменти. При вашия вариант с "до двама" души на проект не би трябвало това да е проблем.


Ахаа имало вратичка значи. Т.е. разделяме commit-ите(приноса) на официални и неофициални(тайни).
Бъзикам се разбира се. Винаги съм намирал такъв шорткът и аз. Аз му викам "black market" с тестерите и валидаторите. Но това де-факто е заобикаляне на доста от "официалните" процеси и говори за празнини или непроходимости в организацията.

Но щом сте го докарали до такова ниво на автоматизация - поздравления.

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

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

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

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


Няма нужда от притеснение - системата е там, за да слугува. TeamCity може да се настрои в такива ситуации да не билдва всичко - по-точно, първият пуш стартира билд, след това, още докато билда тича и не е завършил, се изсипват примерно още 50 комита. Да, ама не - онзи казва - тия, дето са влезли в build queue-то, и все още не са тръгнали, се препокриват от по-нови комити. Т.е. след като свърши билд на ревизия, той ще почне билд на ревизия 51 директно. Пак казвам, това е опция, и аз не я ползвам често - причината е че някъде към обяд на този ден ще имам счупен билд, и яко чесане на главата коя от хилядите промени сред тия 50 комита, е счупила билда. Това е неприемливо - в този момент или трябва да върна и да почна да билдвам примерно "25"-та ОК ли е? добре, дай 35, тя ОК ли е? Не? Дай да билднем 30-та, а тя е ок, начи дай 32 и т.н. В другия случай има повече чакане (т.е. 50-тия комита (комитър) ще трябва да поизчака за да разбере дали са му ок нещата), но още при билда на 32 ще е ясно че всички от 1 до 32 са ок, точно 32 е счупена, а билдване на 33 до 50 няма да се пусне (ще изкача), докато проблема не се реши. След решението се наслагват следващите промени (от 33 нататък) и се дебне.
Екстрите на системата (на teamcity) са че директно ще срита (прати нотификация/мейл) на изпращача на 32-ра да си събира акъла и да изследва кое в неговите промени прави счупването. Може да се окаже че всичко му е ок с кода, но има нещо недомислено в дизайна, и не той ще е наказания, а някой друг, който е заложил капана много по-рано.
Онова с "pre-tested commit" цели да избегне това затруднение - което изисква да спреш интеграциите в сорса и да ги приложиш след фиксването върху новата база. Ако нечий код не може да влезе без да е минал през билд и тест, той не може да докара системата до счупено състояние.



Страхът от комит е нещо ужасно, и трябва да се бори до последно, тук съм напълно съгласен. Само не споделям средствата, с които ти искаш да го постигнеш. Просто тия pre-tested commit и частните билдове го решават много елегантно. Да не говорим че има стратегии, в които билд сървъра "филтрира" кои бранчове да билдва и всеки може да е спокоен, че неговия персонален бранч няма да е подложен на проверка, ако това го успокоява.



Промъкна се когато хората на искаха да приемат, че билд/тест се прави задължително на commit В историята е вече, но ми беше голям коз за да убедя екипа - в момента в който някой искаше да "не е на комит", само му припомнят случката и няма нужда от други аргументи.
В конкретния случай, кодът се ползваше в много проекти - още на ниво сорс (svn external) - не е излязъл кофти продукт, билд не е имало, чак през нощта се е опитало и е гръмнало. Но същия сорс се ползва от други проекти, в други локации на фирмата, като external - и комит-а е заминал и счупил другите проекти. Което нямаше да се случи, ако комит-налия беше уведомен навреме да го фиксне и качи преди да излезе в отпуска.


Важи или не, не е правилния въпрос - въпросът е "има ли изградена система която да гарантира проследимост и повтаряемост" - може и да стане в твоя вариант, в който "машината на интегратора" са една класна стая компютри, всеки нагласен с отделен и самостоятелен environment, не-ползвани за нищо друго, посветени на интеграцията на даден проект/аргифакт. Малко разхищаващо е, а и не носи нищо - отиваш една сутрин и машината умряла (дъно примерно). Искаш ново ПЦ да я възстановиш - сорса добре, инструментите добре, ама с коя версия на XP-то беше, имали ли internet explorer 6, нямаше ли? Имаше ли .... ? Ако си грамотен си си написал един ферман от какво си инсталирал - на чисто XP сложиш това, после това, после това ... - и тоя ферман, в електронно-четим вид, са тия файлове за докер или вагрант, които могат да ти изкарат това нещо на произволно (виртуално) пц за няколко минути.


Аз го виждам по друг начин - не е необходимо да "дублирам" билд и тест архитектурата както на сървъра, така и при мен - мога поискам от сървъра да изпълни отдалечено някакъв билд - дали ще го комитна или не няма никакво отношение. Предоставям на дивелопърите (за тяхно удобство, не за мое) допълнително улеснение да свършат нещо, без да им се налага да инсталират инструменти и т.н.
Дублирането на процесите на "локални пц" и "на сървъра" е голям проблем - просто е двойна работа. Повечето ползват примерно виндоус, ама 90 процента от билда използва линукс-хост инструменти (тулчейн,...). Каква беше опцията преди - ми сложи си ей тая виртуалка с убунти и работи в нея. "Ама не ми работят shared folders", уф, виж админа да ти ги оправи. "Ама трябва да тегля 10ГБ файл за да проверя промяна от 1 ред..." - ми, трябва, тегли. "Ама аз съм на мобилни данни в Занзибар?" - сори, тегли, клиента чака.

Съгласен съм, че има различни ситуации, различни процеси, различни нагласи в екипите - нека всеки си реши кое е подходящо за него. Автоматизирането на нещо е инвестиция, която не се изплаща, ако това, което си автоматизирал, се използва еднократно - по-добре го направи ръчно. Но такива ситуации са много голяма рядкост - качествените системи (ако не съм споменал, teamcity) позволяват да си имаш темплети/мета-проекти, с които примерно билд на makefile базиран проект е на два клика разстояние - дай сорс url-а, кажи ми къде да взема готовите файлове (което също може да се улесни, ако всички мейкфайлове имат концепция да оставят изхода/артифактите примерно в папка "output").

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

Това зависи от дефиницията на "рутинния труд" - имам предвид че всяко едно предизвикателсто си иска анализ доколко е възможно, или смислено, да се автоматизира. По презумция бих казал всичко, като някъде може и да има изключения, които обаче трябва да "докажат" нуждата да не се впишат във веригата. Все пак, мисля си, щом човек може да го свърши може да се автоматизира - в смисъл, щом можеш да обясниш на някога как да върши "ръчно" тая стъпка, и то обяснението да е такова, че да си спокоен че няма да сбърка, значи можеш и да го "скриптираш"). Ако имаш конкретни такива точки, ще ми е интересно да помислим по темата - определено ми е забавна работата в това направление и търся предизвикателства.

За който се интересува от темата, силно го препоръчвам това "teamcity" - преди него работих основно с jenkins, като прегледах и още няколко подобни системи, но повече са фокусирани върху други "области" - .net, java (maven) и подобни. След месеци копане в женкинса надигнах глава да се огледам за нещо свежо и така стигнах до TC. Та имах възможност да направя сравнение между двете. Огромният плюс на TC е че е правен с мисъл за хората, дето ще го ползват - т.е. фактора "удобство" е много силно застъпен. Дотолкова, че ми е трудно да намеря точка от интерфейса му, където да кажа "ех, що са го направили само да си провери това и ми предложи списък" - където е възможно, това е направено и е дяволски удобно да се ползва.
Та, препоръчвам го и заради друго - много е полезен за да ти "намекне" кой е правилният подход - дава ти лесен инструмент да си избереш примерно зависимост от по-ранен проект, и се сещаш че е безсмислено да правиш pre-build стъпки, които да изтеглят тези неща (дали субмодули/екстърнъли, или wget от някъде).
Има глезотии много - правиш си проекта и светва някакъв warning знак отгоре - цъкаш, и оня ти говори: "направил си нещо, което изкарва файл (обявил си libmodbus.a като изходен артифакт на проекта) - искаш ли да пуснем една проверка на тоя файл, примерно на размера му, и да ти се обадя ако тоя файл скочи или спадне с повече от (примерно) 10% от размера от предишния билд ?" - цъкаш "Ъхъ, искам" и след няколко седмици билда се счупил и той твърди че, видиш ли, някакъв хекс (примерно), дето бил 600Кбайта, сега станал 2Гб... поглеждаш, няма грешка в билд лог-а - мейка вика, абе наред е, няма проблем. Гледаш пак, и виждаш че нЕкой модифицирал линкер скрипта и иска да инициализира цялото адресно пространство с нули (примерно). Ааааа!
Имам проекти, които се билват през конзолно викане на еклипс - проектите са managed еклипс проекти и това е начина, няма как. Само че сума ти народ, вкл. и аз, са се сблъскали с това, че еклипсец.екзе-то връща не-нулев резултат в конзолата, дори когато билда си е съвсем ок, и никой не знае решение на въпроса. Трябва да игнорираш връщаната стойност, иначе няма да видиш успешен билд никога. Но онзи (TC) бърка в задния джоб и ти позволява да анализираш билд изхода (лог-а в конзолата) и да търси текст или regexp за нещо - примерно "failed", и да ти спаси Д-то в тая нелицеприятна ситуация.