Здравствуйте, IID, Вы писали:
IID>Строчки кода и переустановка при каждом билде это ортогональные вещи.
Нет. Это то, как это реализовано. Код описывает всю инфрастуктуры и все шаги для сборки, и это часть проекта.
S>>Права доступа тут проблему не меняют никак. Всегда есть люди которые могут что-то изменить без особых следов. IID>Какой бардак
Так это у вас так У вас в любом случае есть люди с доступом к билд-серверам и их действия в общем случае в истории проекта не отображаются вообще.
IID>Нет, не могут. Могли бы — сделали бы последовательные билды стабильными.
Так у нас все сделано
IID>Без костылей с полной переустановкой.
Дело не в переустановке, а в отношении к инфраструктуре сборки. У вас это отдельная вещь, у нас — неотъемлемая часть проекта с полной историей.
Минусы вашего подхода очевидны, но вы с Креатором упираетесь почему-то.
Здравствуйте, ·, Вы писали:
·>Т.е. у вас происходит именно это: "установка КЕМ-ТО [2-3 человека] софта на билд сервер для решения своих задач [задачи билда]". Верно?
Верно. Только существенную часть ты в скобки поместил.
IID>>Кроме того, идея запускать на билд-сервере какие-то скрипты/бинари (включая свежесобранные билд-хелперы) из репозитория — чревата дырами в безопасности. ·>А какая должна быть идея о том что там можно запускать и как это контролируется?
Самое простое и правильное — билсервер никогда и ничего не исполняет из репозитория.
Если очень надо — придётся кропотливо настраивать права. Чтобы исполяемое могло сделать ровно то, что ему разрешено. И то это не панацея, LPE никто не отменял.
А тут вы бессильны, потому как даже пробел в пути диагностировать не можете (из обсуждения выше), предпочитая сносить всё дотла.
Ты просто представь на секунду, что такой бардак случится в каком-нибудь Apple, MS или Google ?
Достаточно устроиться сотрудником, и через заливки в GIT можно атаковать билдсервер, красть сертификаты (или хотя бы подписывать свой код ими), ослаблять шифрование, вносить закладки (невидимые, вносимые в момент компиляции пропатченным в памяти компилятором).
Здравствуйте, IID, Вы писали:
IID>·>Т.е. у вас происходит именно это: "установка КЕМ-ТО [2-3 человека] софта на билд сервер для решения своих задач [задачи билда]". Верно? IID>Верно. Только существенную часть ты в скобки поместил.
Т.е. кликать мышой в RDP можно (лишь бы рука не дрогнула). А описать в виде скрипта — внезапно дыра в безопасности. Ну точно подвал в НИИ и турбопаскаль.
IID>>>Кроме того, идея запускать на билд-сервере какие-то скрипты/бинари (включая свежесобранные билд-хелперы) из репозитория — чревата дырами в безопасности. IID>·>А какая должна быть идея о том что там можно запускать и как это контролируется? IID>Самое простое и правильное — билсервер никогда и ничего не исполняет из репозитория.
Почему? (Хинт: репозиториев можно ВНЕЗАПНО иметь несколько — для кода проекта и для инфраструктуры. У разных репов могут быть разные права доступа, способы верификации, ревью, sign-off изменений).
А как это у вас контролируется? Лишь бы рука не дрогнула?
IID>Если очень надо — придётся кропотливо настраивать права. Чтобы исполяемое могло сделать ровно то, что ему разрешено. И то это не панацея, LPE никто не отменял. IID>А тут вы бессильны, потому как даже пробел в пути диагностировать не можете (из обсуждения выше), предпочитая сносить всё дотла.
Как вы это диагностируете?
IID>Ты просто представь на секунду, что такой бардак случится в каком-нибудь Apple, MS или Google ?
Гугл вроде как один из пионеров IaC.
IID>Достаточно устроиться сотрудником, и через заливки в GIT можно атаковать билдсервер, красть сертификаты (или хотя бы подписывать свой код ими), ослаблять шифрование, вносить закладки (невидимые, вносимые в момент компиляции пропатченным в памяти компилятором).
У вас что, в любой репо любой сотрудник может заливать всё что угодно? Вот и нашли в чём у вас проблема. Чините.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Skorodum, Вы писали:
S>Код описывает всю инфрастуктуры и все шаги для сборки, и это часть проекта.
Это всё прекрасно, но нафига при каждом билде всё переустанавливать ?
Актуальность своих билд-скриптов можешь проверять отдельными тестами.
Кроме того сборка на билд-сервере может существенно отличаться от сборки на машинах разработчиков.
И твои билдсерверные "инструкции" сгодятся только для подтирки задницы.
Например все исходники и ключи доступны только нескольким инженерам аудита и безопасности, основная часть доступна core team, остальные используют SDK. И прочие возможные вариации.
Эпл, например, даже fingerprint-ит ключевые вещи, чтобы вычислить потенциальную утечку.
S>У вас в любом случае есть люди с доступом к билд-серверам и их действия в общем случае в истории проекта не отображаются вообще.
Они не устанавливают на билд-сервер что-попало, в отличе от вас.
S>Минусы вашего подхода очевидны, но вы с Креатором упираетесь почему-то.
Да бог с ним, с нашим подходом. Вы сначала сумейте показать плюсы своего. Пока что заметно только раздутое ЧСВ и упорное нежелание конструктивно отвечать (тот же пример с замыливанием ошибки).
Здравствуйте, IID, Вы писали:
IID> Достаточно устроиться сотрудником, и через заливки в GIT можно атаковать билдсервер, красть сертификаты (или хотя бы подписывать свой код ими), ослаблять шифрование, вносить закладки (невидимые, вносимые в момент компиляции пропатченным в памяти компилятором).
Для этого тебе придется войти в сговор с очень большим числом людей (что теоретически возможно, но на практике практически нереально), а воспроизводимые сборки позволяют разрывать контур внесения "ошибки" практически в любом месте и достаточно дешево.
Билд-сервер (во "взрослой" компании) — это не одиночная физическая машинка, а сотни и тысячи физических серверов на каждом из которых может быть запущено множество разнообразных задач (сборки, тестирования, разработки и т.д.) в разной степени изоляции. Никто не ходит на эти сервера по ssh, ничего не устанавливает/обновляет/настраивает — их в 99.99% случаев обслуживает автоматика.
Здравствуйте, Cyberax, Вы писали:
C>Это один из примеров. Другой пример (как раз для Windows, ага) был, когда кривософт устанавливал сборку в .NET GAC.
И? Ради одной проблемки раз в год вы тратите по несколько лищних минут на каждый билд? Ах да, я ж забыл что речь про язык курильщика, где билды идут часами на 100500процессорных машинах.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Это один из примеров. Другой пример (как раз для Windows, ага) был, когда кривософт устанавливал сборку в .NET GAC.
НС>И? Ради одной проблемки раз в год вы тратите по несколько лищних минут на каждый билд? Ах да, я ж забыл что речь про язык курильщика, где билды идут часами на 100500процессорных машинах.
Одна ошибка раз в год может спокойно перевесить суммарную стоимость всех билдов вместе взятых.
Здравствуйте, IID, Вы писали:
S>>Код описывает всю инфрастуктуры и все шаги для сборки, и это часть проекта. IID>Это всё прекрасно, но нафига при каждом билде всё переустанавливать ?
Чтобы 100% гарантировать, что текущий билд никак не зависит от предыдущих. Это самый простой и дешевый способ. Очевидно почему?
IID>Актуальность своих билд-скриптов можешь проверять отдельными тестами.
Это никакой гарантии не даёт. Думаю, что очевидно почему.
IID>Кроме того сборка на билд-сервере может существенно отличаться от сборки на машинах разработчиков.
И что? Разработчики обычно разрабатывают как им удобно, нередко каждый по-своему.
IID>Например все исходники и ключи доступны только нескольким инженерам аудита и безопасности, основная часть доступна core team, остальные используют SDK. И прочие возможные вариации.
Угу. И соответственно отдельные репы с ограниченным доступом.
S>>У вас в любом случае есть люди с доступом к билд-серверам и их действия в общем случае в истории проекта не отображаются вообще. IID>Они не устанавливают на билд-сервер что-попало, в отличе от вас.
Они устанавливают что получится как попало куда попало.
S>>Минусы вашего подхода очевидны, но вы с Креатором упираетесь почему-то. IID>Да бог с ним, с нашим подходом. Вы сначала сумейте показать плюсы своего.
Полный контроль над процессом билда и окружением, история всех изменений, привычный процесс внесения изменений (пулл-реквесты, ревью и т.п.). Элементарно делать откаты к любой версии. Диффы, надёжная структурированная история. Безопасные эксперименты. Восстановление окружения с нуля (сдохло железо — не беда, нажали кнопочку — всё снова поднялось на другом серваке). Масштабирование (как эти твои 2-3 человека вносят гарантированно идентичные изменения на нескольких билд-серверах?)
В общем, я не понимаю, почему надо рассказывать о преимуществах vcs вроде бы взрослым людям.
IID>Пока что заметно только раздутое ЧСВ и упорное нежелание конструктивно отвечать (тот же пример с замыливанием ошибки).
Вот тут
человек вообще согласился, что одна ошибка — не считается.
Если хочется, то девовские билды можно делать инкрементально и ловить такие баги, а релизные — с нуля.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Образ ВМ, снапшоты? Не, не слышал.
Это решение, но не идеальное: как документировано состояние ВМ? Нет никакой гарантии, что описанный процесс сборки в каком-нибудь README.md и ВМ полностью соотвествуют друг другу. ВМ полностью отвязана от проекта.
Следующий логичный шаг после "ВМ и снапшотов" это создавать ВМ или контейнеры из описания, которое хранится в самом проекте. Всякие Travis, Azure, и прочие GitLab эту задачу и решают.
Здравствуйте, IID, Вы писали:
IID>Это всё прекрасно, но нафига при каждом билде всё переустанавливать ?
Это уже детали реализации и зависит от используемой инфраструктуры. При использовании Docker'а можно брать закэшированные образы. С Azure это не работает, там приходится брать готовые образы ВМ и доустанавливать необходимое.
Главное суть — инфраструктура необходимая для сборки описана в проекте.
IID>Актуальность своих билд-скриптов можешь проверять отдельными тестами.
Бред какой-то. Результат работы процесса сборки это продукт. Каждый шаг сборки либо проходит, либо нет, любая ошибка означает провал всей сборки.
IID>Кроме того сборка на билд-сервере может существенно отличаться от сборки на машинах разработчиков.
Может. Это никак не протеворечит факту, что описание для билд-сервера является эталоном и должно воспроизводится где угодно, а как отдельные разработчики извращаюся — абсолютно не важно.
IID>И твои билдсерверные "инструкции" сгодятся только для подтирки задницы.
Ну у кого как
IID>Например все исходники и ключи доступны только нескольким инженерам аудита и безопасности, основная часть доступна core team, остальные используют SDK. И прочие возможные вариации.
И?
IID>Эпл, например, даже fingerprint-ит ключевые вещи, чтобы вычислить потенциальную утечку.
И?
S>>У вас в любом случае есть люди с доступом к билд-серверам и их действия в общем случае в истории проекта не отображаются вообще. IID>Они не устанавливают на билд-сервер что-попало, в отличе от вас.
В отчличии от вас у нас любые изменения для "билд-серверов" (которых у нас и физически нет, BTW) отражаются в системе контроля версий.
IID>Да бог с ним, с нашим подходом. Вы сначала сумейте показать плюсы своего.
Да много раз уже показали, но вам религия не позволяет видеть
IID>Пока что заметно только раздутое ЧСВ
Это как раз сторонники МС этим страдают и нежеланием учится и адоптироваться.
IID>и упорное нежелание конструктивно отвечать (тот же пример с замыливанием ошибки).
Ну вообще-то это ты ярлыки навешиваешь и упорно не отвечаешь на вопрос как у вас документирвано состояние билд-серверов.
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Это один из примеров. Другой пример (как раз для Windows, ага) был, когда кривософт устанавливал сборку в .NET GAC. НС>И? Ради одной проблемки раз в год вы тратите по несколько лищних минут на каждый билд?
Минут? Контейнер запускается за секунды. Это же не Винда.
НС>Ах да, я ж забыл что речь про язык курильщика, где билды идут часами на 100500процессорных машинах.
Часами у нас даже Буст не строится.
Здравствуйте, IID, Вы писали:
IID>Это всё прекрасно, но нафига при каждом билде всё переустанавливать ?
Если делать через docker, промежуточные шаги кешируются и образы переиспользуются. Если не было изменений в пререквизитах то время тратится только на последний билд-степ.
IID>Актуальность своих билд-скриптов можешь проверять отдельными тестами.
Здравствуйте, Michael7, Вы писали:
M>Просто по определению не выйдет стандартизировать поведение сборщиков других языков. Но на самом деле все еще интереснее. Например, Qt строго формально вообще не на C++ написана. Используются некоторые расширения, которых нет в языке, а компилируется компилятором C++ только после того как специальный препроцессор (qmake) развернет их. И вот как это со стандартом совместить? Не говоря о том, что заставить комитет никого не может, следование стандарту в общем-то добровольное.
Qt как раз таки написана на С++ и использует кодогенерацию. Ничего плохого в этом нет. А кодогенерация есть много где, отличный пример — тот же google protobuf.
Здравствуйте, Skorodum, Вы писали:
НС>>Образ ВМ, снапшоты? Не, не слышал. S>Это решение, но не идеальное
Оно куда идеальнее, чем накатывать на голый образ тулы при каждой сборке.
S>: как документировано состояние ВМ? Нет никакой гарантии, что описанный процесс сборки в каком-нибудь README.md и ВМ полностью соотвествуют друг другу.
Если тебя одолевает паранойя по поводу того, что враги подменят образ внезапно, то всегда можно собирать образ/контейнер при помощи того же CI, но строго только при изменении скриптов подготовки ВМ.
Здравствуйте, Ikemefula, Вы писали:
НС>>И? Ради одной проблемки раз в год вы тратите по несколько лищних минут на каждый билд? Ах да, я ж забыл что речь про язык курильщика, где билды идут часами на 100500процессорных машинах. I>Одна ошибка раз в год может спокойно перевесить суммарную стоимость всех билдов вместе взятых.
Вопрос не в стоимости, вопрос в трате времени разработчиков. Ну и с такой паранойей надо не С++ использовать точно, ибо шансов наломать дров в коде намного порядков больше, чем в криптах сборки.
Здравствуйте, Cyberax, Вы писали:
C>>>Это один из примеров. Другой пример (как раз для Windows, ага) был, когда кривософт устанавливал сборку в .NET GAC. НС>>И? Ради одной проблемки раз в год вы тратите по несколько лищних минут на каждый билд? C>Минут? Контейнер запускается за секунды. Это же не Винда.
При чем тут контейнер? Окончательно утерял нить разговора? Речь шла не про контейнер, а про apt get gcc. А контейнер и для vs приготовить несложно.
НС>>Ах да, я ж забыл что речь про язык курильщика, где билды идут часами на 100500процессорных машинах. C>Часами у нас даже Буст не строится.
Ну да, облако то свое, можно 100500 процессорные машинки под билд использовать.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Оно куда идеальнее, чем накатывать на голый образ тулы при каждой сборке.
Это уже детали реализации. При использовании тех же контейнеров все будет кэшировано и без изменения файла, описывающего контейнер, никаких реальных накатываний не будет.
НС>Если тебя одолевает паранойя по поводу того, что враги подменят образ внезапно, то всегда можно собирать образ/контейнер при помощи того же CI, но строго только при изменении скриптов подготовки ВМ.
Дела не во врагах, а в следовании DRY принципу. Инфраструктура для сборки должна быть кодом и должа быть частью проекта. Раньше такое было невозможно, теперь — легко и удобно.
Здравствуйте, Skorodum, Вы писали:
НС>>Оно куда идеальнее, чем накатывать на голый образ тулы при каждой сборке. S>Это уже детали реализации.
S> При использовании тех же контейнеров
Вы прям как то дружно с Кибераксом потеряли контекст.
НС>>Если тебя одолевает паранойя по поводу того, что враги подменят образ внезапно, то всегда можно собирать образ/контейнер при помощи того же CI, но строго только при изменении скриптов подготовки ВМ. S>Дела не во врагах, а в следовании DRY принципу. Инфраструктура для сборки должна быть кодом и должа быть частью проекта.
У вас в любом случае есть люди с доступом к билд-серверам и их действия в общем случае в истории проекта не отображаются вообще.
