Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Skorodum, Вы писали:
S>>Мне вообще странно, что людям, занимающимся разработкой ПО за деньги, надо объяснять преимущества подхода Infrastructure as code CC>Да потому что багов в этом коде образуется немеряно.
Нет. Там декларативный подход и обычно оно либо работает, либо нет, примерно так:
* взять Ubuntu 16.04,
* установить git, cmake, gcc, etc
* "cmake && make"
* опубликовать
Ошибки там могут быть только в запятых, путях и отступах и они фатальны.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Skorodum, Вы писали:
CC>>>VM + snapshot тут будет куда более подходящее решение. S>>Ну примерно так и делается CC>Напомню что речь как раз шла не об откате на снапшот а на переустановку скриптами всего build environment с нуля. CC>Что как раз и вызывало недоумение "нафига так корячиться".
Потому что это проще, чем откатываться, ваш кэп. Вот серьезно, расскажи как у вас задокументированно какое ПО установленно на виртуальные билд-сервера. Комментарий к образу виртуальной машины?
У нас это КОД в проекте, и если он не соотвествуют тому, что должно быть для сборки, то проект просто не соберется.
Здравствуйте, CreatorCray, Вы писали:
C>>И реальные инженеры (а не 1С-ники), которые работают с системами в сотни миллионов строк кода, это понимают и пытаются ограничить последствия ошибок. CC>Ошибки надо обнаруживать и чинить, а не городить систему в которой они не проявляются до поры до времени.
Все ошибки нельзя исправить. Просто из-за того, что при исправлении появятся новые.
Так что инженеры делают так, чтобы одна ошибка не вызывала критичный сбой всей системы.
In November 2001, a consortium was formed with a board of stewards to further the development of Eclipse as open-source software. It is estimated that IBM had already invested nearly $40 million by that time
Вот так вот, само по себе разработалось, сами по себе 40 лямов потратились...
Здравствуйте, IID, Вы писали:
IID>Это админы деградировали до аникейщиков. На билдсервере к копаются все кому захочется, ставят "софт для решения своих задач".
Так это у вас рано или поздно такая ситуация будет, просто потому, что она не исключена Как у вас задокументированно состояние билд-серверов?
У нас нет физических серверов, а установка ПО, это строчки кода в исходниках проекта, вся история полностью отражена в системе контроля версий.
IID>Права нарезать не могут, ошибку найти не могут.
Права доступа тут проблему не меняют никак. Всегда есть люди которые могут что-то изменить без особых следов.
IID>Могут только переустанавливать.
Могут автоматизировать и документировать процесс на 100%.
Здравствуйте, CreatorCray, Вы писали:
C>>И реальные инженеры (а не 1С-ники), которые работают с системами в сотни миллионов строк кода, это понимают и пытаются ограничить последствия ошибок. CC>Ошибки надо обнаруживать и чинить, а не городить систему в которой они не проявляются до поры до времени.
Одно другое не отменяет. В больших системах часть ошибок на момент релиза еще необнаружена. Более того, часть сбоев принципиально неустранима. Например, сеть никогда не бывает надежной на 100%. Что бы у пользователей, в продакшне, во время эксплуатации не сложилось вообще все, необходимо ограничивать последствия сбоев.
В обычном софтостроении до сих пор со смехом смотрят на резервирование(теория надежности). В больших системах это естественное решение.
Здравствуйте, IID, Вы писали:
IID>Ты не ответил на вопрос. КАЖДАЯ сборка ? IID>Т.е. вы каждый билд откатываете сервер на голую ОС, потом разворачиваете тулчейн, ставите over9000 всяких dev пакетов и т.д. и т.п ? ЗАЧЕМ ? (Кажется кто-то заврался.)
Для того, что бы гарантировать отсутствие влияния нескольких билдов. Если цена ошибки высока, то и не такое можно встретить.
Здравствуйте, IID, Вы писали:
S>>>Кажется кто-то не знает как работают взрослые CC>>Ну и как же называется эта "взрослая" компания? IID>Присоединяюсь к вопросу. IID>Компания, в которой "наиболее типичная проблема" это установка КЕМ-ТО софта на билд сервер для решения своих задач
Здравствуйте, Ikemefula, Вы писали:
I>Для того, что бы гарантировать отсутствие влияния нескольких билдов. Если цена ошибки высока, то и не такое можно встретить.
В том числе и чтобы исключить ситуацию "ничего не знаю, у меня все работает" (например в документации по сборке забыли описать зависимость от чего-то либо необходимость какого-то хитрого патча).
У нас есть гарантия, что как документированно — так и собирается, т.к. код, описывающий сборку, и есть документация, и если он устарел, то сборка не пройдет после первого же коммита.
Здравствуйте, Skorodum, Вы писали:
I>>Для того, что бы гарантировать отсутствие влияния нескольких билдов. Если цена ошибки высока, то и не такое можно встретить. S>В том числе и чтобы исключить ситуацию "ничего не знаю, у меня все работает" (например в документации по сборке забыли описать зависимость от чего-то либо необходимость какого-то хитрого патча). S>У нас есть гарантия, что как документированно — так и собирается, т.к. код, описывающий сборку, и есть документация, и если он устарел, то сборка не пройдет после первого же коммита.
А что у вас за проект, если не секрет ? Или хотя бы область деятельности.
Здравствуйте, CreatorCray, Вы писали:
CC>Ошибки надо обнаруживать и чинить, а не городить систему в которой они не проявляются до поры до времени.
Ну так вам и описывают самый правильный для этого подход, при котором ошибка сразу же обнаружится.
Здравствуйте, Ikemefula, Вы писали:
I>А что у вас за проект, если не секрет ? Или хотя бы область деятельности.
Наша область дейятельности это радары и обработка сигналов, но это тут никакой специфики не играет: C/С++/Qt/pyhton/git/CMake и Azure для CI. Все компилится для Win/Mac/Linux и embedded.
Azure работает, не надо думать о свох физических серверах, но медленный (особенно при попытке использовать Docker) и "vendor lock" в чистом виде.
До этого у меня были БД и компилятор: там C++/Qt/git/QBS + Docker + локальный Gitlab. По мне так локальный Gitlab — лучше чем Azure для СI в С++ мире: средство заточенное на решение одной задачи, имеется полный контроль и куда быстрее, но надо не бояться админить сервер. У Azure большой плюс это VSTS (универсальное хранилище, удобно бинари туда пихать, например специфичную версию Qt).
Здравствуйте, ·, Вы писали:
IID>>установка КЕМ-ТО софта на билд сервер для решения своих задач ·>Любопытно. А откуда у вас софт на билд-серверах появляется?
Биткоин майнеры "для решения своих задач" на билд серверах не появляются совсем
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
·>Любопытно. А откуда у вас софт на билд-серверах появляется?
Очень просто. Ниоткуда не появляется.
Никакого левого софта у нас там нет. И доступа к изменению чего-либо тоже почти ни у кого нет (буквально 2-3 человека).
Кроме того, идея запускать на билд-сервере какие-то скрипты/бинари (включая свежесобранные билд-хелперы) из репозитория — чревата дырами в безопасности.
Здравствуйте, Skorodum, Вы писали:
CC>>Ошибки надо обнаруживать и чинить, а не городить систему в которой они не проявляются до поры до времени. S>Ну так вам и описывают самый правильный для этого подход, при котором ошибка сразу же обнаружится.
у тебя совсем память не работает ?
выше был пример "замыливания" от Сайберакса , и его справедливая критика.
Обнаружится он при втором прогоне, когда наступят на какашку от первого.
Но второй прогон памперс от первого выбросит и не увидит кровавого поноса.
Здравствуйте, Skorodum, Вы писали:
S>У нас нет физических серверов, а установка ПО, это строчки кода в исходниках проекта, вся история полностью отражена в системе контроля версий.
Строчки кода и переустановка при каждом билде это ортогональные вещи.
IID>>Права нарезать не могут, ошибку найти не могут. S>Права доступа тут проблему не меняют никак. Всегда есть люди которые могут что-то изменить без особых следов.
Какой бардак
IID>>Могут только переустанавливать. S>Могут автоматизировать и документировать процесс на 100%.
Нет, не могут. Могли бы — сделали бы последовательные билды стабильными. Без костылей с полной переустановкой.
IID>·>Любопытно. А откуда у вас софт на билд-серверах появляется? IID>Очень просто. Ниоткуда не появляется.
Я не спрашиваю про левый софт. Я спрашиваю как на билд-сервере появляется какой-либо софт?
IID>Никакого левого софта у нас там нет. И доступа к изменению чего-либо тоже почти ни у кого нет (буквально 2-3 человека).
Т.е. у вас происходит именно это: "установка КЕМ-ТО [2-3 человека] софта на билд сервер для решения своих задач [задачи билда]". Верно?
IID>Кроме того, идея запускать на билд-сервере какие-то скрипты/бинари (включая свежесобранные билд-хелперы) из репозитория — чревата дырами в безопасности.
А какая должна быть идея о том что там можно запускать и как это контролируется?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, CreatorCray, Вы писали:
IID>>>установка КЕМ-ТО софта на билд сервер для решения своих задач CC>·>Любопытно. А откуда у вас софт на билд-серверах появляется? CC>Биткоин майнеры "для решения своих задач" на билд серверах не появляются совсем
Поздравляю! Великое достижение! А небиткойн майнеры там появляется телепатически?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай