ну то есть билд - это же новая версия?

Тесты гонять например

есть скрам - то это раз в 2 недели

для того чтоб катать на стейджинг

если это тесты - это автоматическая система делает

чтоб сразу было видно результат

fail fast

При CI/CD все билдится много раз в день

но она не обязана каждый раз снова билдить

Обязана, иначе можно пропустить регрессионный баг

ну а без докера как?

но она не обязана каждый раз снова билдить

тесты прошли, поехали на стейджинг

не переустанавливали же линукс всякий раз с тестами

ну вот докер решет пробелму «не преустанавливать линкус каждый раз»

потому что линукс уже есть, в него просто надо положить файлы

ну а без докера как?

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

и вместо того чтоб плодить вот это: а давайте щас гит дёрнем, а чо у нас на стейджинге сломалось? у меня локально всё работает!

а тут стянул локально имадж, нажал compose up и посмотрел что конкретно сломалось

и не надо тянуть тридцать гигов виртуалок

патамушта я долбоёб

@demeliorator запинь это?))

™

Хотя это не девопс чатик, тут такой юмор не оценят :(

@demeliorator запинь это?))

передать опыт молодым поколениям!

мой опыт больше про питон/пхп, как я это вижу : есть (1) система (на базе линукс), там (2) какой-то софт и либы, которые нам нужны для установки зависимостей, есть софт, от которого зависит проект (php/python, mysql/mariadb/postgresql/.., apache/nginx), (3) есть непосредственно наш проект и либы на том же питоне/пхп как зависимости... вот нам нужно реально трогать только (3) каждый раз, (1) и (2) можно обновлять только 1 раз в 2 недели

перед релизом

то есть пусть оно там хоть 10 минут билдится, пофиг же

а (3) - это просто копирование файлов

и каждые 2 недели перед релизом на боевой сервер, да, перебилдим с нуля всё и проверим, что ничего не упало

а вот каждый день - зачем это всё билдить?

а (3) - это просто копирование файлов

Это не просто копирование файлов. 1. Копирование файлов 2. Чистка и прогрев кеша 3. Сборка ассетов 4. Накатка миграций Как минимум

Даже на пхп проекте этот процесс может минут 5 идти.

И если собрался такой контейнер то дальше он за 10 секунд разлетается по девам/стейджам/продам

ну, с моей точки зрения нет проблем в том чтобы кешировать (1), (2) , а 3 всегда собирать заново без кешей на базе состояния после (2)

и для этого всего вовсе не стоило городить какие-то те вещи, которые в докере сделаны

кому очень нужно - могли бы кешировать

вообще никаких докерфайлов не нужно было делать, должен был быть просто .sh файл с набором команд

и если кому-то надо - он бы мог в промежутках между командами это кешировать

можно было бы даже хелпер сделать для этого

Тут речь не о том что это какая-то нерешаемая проблема, а о том что получается сэкономить 100% времени, 50% системных ресурсов и всяких таких затрат. Быстрее выше сильнее.

нужен кеш - вставляй такую-то команду

Но если у компании девиз - медленнее ниже примитивнее, то да, можно и sh скриптом все проблемы решать.

И даже перейти с git на svn обратно ;)

так а в чём тут примитивность, если кеш не нужен?

есть, скажем, ночные сборки

какой смысл каждый час что-то там билдить?

ночью оно само билдится, на незагруженном сервере

пусть хоть 4 часа билдится, кому какая разница там

Ночные сборки это инновации 10летней давности. Сейчас - разработчик сделал push в гит - система все пересобрала и прогнала тесты.

А девопс кнопочкой в интерфейсе послал свежий контейнер на прод через 10 минут.

нужен кеш - вставляй такую-то команду

так вот докер это за тебя по сути и делает

А девопс кнопочкой в интерфейсе послал свежий контейнер на прод через 10 минут.

оно само послалось через blue green deployment, ну или через постепенную нагрузку.

с нормальнйо инвалидацией

потому что твоё описание нынче не модно

есть, скажем, ночные сборки

ночные сборки это 90 год

автоматические тесты после пуша в гите это хорошо, я согласен, но даже если там просто 1 ядро выделено - оно справится с билдом

сейчас уже почти 2020

в 2020 году надо иметь инфраструктуру которую можно катать полностью за минуты, а не за три недели

все ошибки всё равно протестировать автоматически не получится

и не тратить время разработчиков на игру «А УМЕНЯ СОБИРАЕТСЯ»

вот

нужна команда тестировщиков, которые вручную всё тестируют

по этому когда ты катаешь постоянно, сразу, ты всё говно сразу видишь

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

автоматические тесты после пуша в гите это хорошо, я согласен, но даже если там просто 1 ядро выделено - оно справится с билдом

Когда в проекте 10-20 разработчиков и они весь рабочий день пишут код и делают пуш, скажем каждый час, получается что 10*8 = 80 пушей в день = 80 билдов в день.

ну вот яндекс он как раз выливает в продакшн сразу же после коммита и сборки и проверки тестов

ERROR: S client not available

и куча же багов

на том же маркете сколько багов было

и отлично

error rate привысил порог, катанули назад

за секунду

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

на том же маркете сколько багов было

А если бы у них были ночные сборки - багов было бы меньше или больше?

ну вот яндекс он как раз выливает в продакшн сразу же после коммита и сборки и проверки тестов

Эт тебе кто сказал? оО

так а не проще ли просто 1 раз в 3 недели релизить? какая потребность в том, чтобы релизить по несколько раз в день?

с маркетинговой точки зрения лучше 1 раз в 1-3 недели

тогда можно рассылку сделать

всем сказать, что какие мы молодцы, вот для вас сделали

Когда в проекте 10-20 разработчиков и они весь рабочий день пишут код и делают пуш, скажем каждый час, получается что 10*8 = 80 пушей в день = 80 билдов в день.

и чоу?

так а не проще ли просто 1 раз в 3 недели релизить? какая потребность в том, чтобы релизить по несколько раз в день?

можно выкатывать фичи на 1% и смотреть

у меня по всем продуктам 100+ билдов в день получается

так а не проще ли просто 1 раз в 3 недели релизить? какая потребность в том, чтобы релизить по несколько раз в день?

То есть чтобы увидеть на a/b тестах что новая фича непопялурна, придется ждать 3 недели?

с маркетинговой точки зрения лучше 1 раз в 1-3 недели

A/B тестирование, не?

ну, если 3 недели для кого-то это большой срок - можно раз в неделю

так а не проще ли просто 1 раз в 3 недели релизить? какая потребность в том, чтобы релизить по несколько раз в день?

Девопсы, лови его!

не, я понимаю, что модно раз в час

и я понимаю, как это технически сделать

это не модно, это необходимо

но я не понимаю реальной потребности в этом

У тебя есть отдел маркетинга?

не, я понимаю, что модно раз в час

Не модно, а экономически выгодно.

но я не понимаю реальной потребности в этом

три недели пилить фичу в слепую, или за три дня собрать и хуйнуть на 100 человек и увидеть что не так

потом хуйнуть ещё раз

потом когда на 100 работат, хуйнуть на 10к

так почему же вслепую? бета-тестеры там всякие

а потом через три недели отполированную живым опытом фичу на всех

им ранний доступ