не терабайты исходников же

хотя если это было лет 10 назад может и норм

нет не 10

около 5

так и что вы там 8 часов компилили?

сколько было разработчиков?

весь проект

около 40

сумарно +-8

ну не так много... как локально запускали?

локально тоже 8+ часов ждали?

там ситуация в том была что

что тесты гоняешь в junit и вроде все ок

вливаешь в репу

ночью репа пересобиралась утром всем email

мы у себя на dev пересобирали куски

основная адища была с gwt

ну то есть... UI тесты?

или что?

нет у нас ui тестов не было (мы их skip)

> утром всем email

но что-то ж падало?

ну да бывало что падает потом фиксишь

что падало то7

на билд сервере UI тесты гонялись?

и они рандомом фэйлились?

нет не ui тесты

а что?

и причем тут тогда gwt?

gwt долго собирается довольно

особенно если такой ебанутый интерфейс

я согласен что можно было и лучше

но у нас было так

там было много ебанутых решений

я напомню

ты привел этот пример к "время билда увеличится"

а у тебя насколько я понял львинут долю времени отжирала компиляция gwt

ок 1 простой пример

ты написал код

написал unit test

все ок твой код ок

(или наоборот)

ты его подключаешь в spring

прописывая в xml или еще куда то

и?

и комитишь в проект

ночью запускается проект и оказывается ты что то не так прописал и spring это не воспринимает

на этапе сборки

а зачем ночью?

ты предлагаешь полностью пересобрать ?

допустим сборка проекта занимает у тебя минут 10-20

чтобы тебе что то получить готовое надо servlet

это по сути war

что бы тесты запустить мне все это не нужно

ну так я и говорю

тесты ты запустил

код работает

3 уровня пирамиды спокойно работают без war,а вот для e2e уже надо да

я все еще не понимаю твоей мысли в контексте обсуждения тестов

если ты хочешь что бы от тестов был прок - надо получать от них обратную связь

и чем быстрее тем лучше

я знаю чуваков у которых юнит тестами покрыто только самое важное, а все остальное - приемочные тесты

в 1 поток выполняются 4 часа

потому они просто на отдельном серваке их гоняют в 12 потоков.

постоянно

в итоге любой человек который запушил что-то в мастер узнает о том что он что-то сломал в течении максимум 20-ти минут

что приемлимо

нет не решаемых проблем, просто в некоторых случаях чтобы создать решение надо много времени

в итоге любой человек который запушил что-то в мастер узнает о том что он что-то сломал в течении максимум 20-ти минут

это должен быть один человек всегда, разве нет?:D

нет не решаемых проблем, просто в некоторых случаях чтобы создать решение надо много времени

я вот вообще не понял морали истории

я с тобой согласен что надо фитбэк как можно раньше

это должен быть один человек всегда, разве нет?:D

в смысле?

и даже наша костыльная сборка и компиляция только класса

в большинстве случаев хватало

в смысле?

ну смысле иметь доступ к апруву пулреквестов, хех

и многие ошибки мы вылавливали в частичной сборки

ну смысле иметь доступ к апруву пулреквестов, хех

trunk-based development

continious integration

например на правил файлы если они в одном модуле ништяк

пересобирать его

пошел кофе налил

сделал что то криво 80% ошибок было тут

оставшиеся 20% могли остаться незамеченными

оставшиеся 20% могли остаться незамеченными

и?

и тесты делали свою роль

без тестов 80% могут остаться незамеченными

они обнаружали ошибки

и?

я не понимаю что ты пытаешься донести

вот от слова совсем

стоит ли 80% ошибок найденных автотестами того чтобы их внедрять

то "полюбил тесты" то "билды по 8 часов"

на разных проектах можно получить разный овтет

стоит ли 80% ошибок найденных автотестами того чтобы их внедрять

стоит

потому что повторюсь, без этих автотестов у тебя вообще непонятны риски от слова совсем

ну раз так значит надо внедрять

а раз команда не джуны

вопрос уже как реализовать эти самые автотесты что бы было эффективно

то она должна понимать профит