Здравствуйте, Serginio1, Вы писали:
S>Вот я смотрю на проект .Net 6. Там только один XML это .csproj
Угу. Это ключевое. У тебя один проект. Если проектов хотя бы сотня, то становится гораздо интереснее как всем этим рулить. И все эти визуальные штуки идут лесом, даже уже ни запомнить, ни в доках ни нарыть какие правильные кнопочки нажимать.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Используй для программного создания любой файл. Все в твоих руках.
Это не проблема. Я конечно сам не занимаюсь MSBuild, но если бы постоянно это делал, я бы автоматизировал максимально этот процесс.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, rosencrantz, Вы писали:
R>Если вы знаете что и как нужно сделать, вы это сделаете и на уродливом XML. Если не знаете, визуальный редактор вам никак не поможет. Если здесь и есть какое-то противостояние, оно не по поводу "GUI вместо текста", а по поводу "сделать без подготовки против уууу, надо читать документацию".
Нет. Вся прелесть GUI в том, что весь интерфейс перед глазами: доступные параметры, их варианты, комбинации, пошаговая настройка, типовые шаблоны конфигураций (basic/advanced или вспомним Minimal/Full/Custom в инсталляторах).
Всё это упрощает работу и позволяет делать и находить что-то, даже не имея опыта. Текстовые конфиги — без мануалов или опыта и строчки не напишешь, точка.
Понятно, что у возможностей GUI есть предел, и GUI обёртки над wget/curl выглядят откровенно нелепо (потому что UI нужно уметь проектировать) и ненужно (потому что "wget http://host.com/file.txt" легко запомнить и легко написать), но всё же GUI именно что "помогает" что-то делать. А место CLI — в задачах автоматизации, а не как многие пытаются навязать CLI как единственный правильный интерфейс.
Pzz>Заметим, что формат .INI-файла появился еще и до XML и до JSON, 100500 лет назад. Он простой и понятный. В нем еще и комментарии предусмотрены в удобном виде, в отличии от JSON-а. Ничто не мешало использовать именно его кроме того, что вот именно ему не повезло стать модным форматом.
INI — двухмерный (секции и пары ключ-значение). Деревья и массивы в нём не предусмотрены, поэтому JSON взлетел, а не INI.
Здравствуйте, flаt, Вы писали:
F>Здравствуйте, rosencrantz, Вы писали:
R>>Если вы знаете что и как нужно сделать, вы это сделаете и на уродливом XML. Если не знаете, визуальный редактор вам никак не поможет. Если здесь и есть какое-то противостояние, оно не по поводу "GUI вместо текста", а по поводу "сделать без подготовки против уууу, надо читать документацию".
F>Нет. Вся прелесть GUI в том, что весь интерфейс перед глазами: доступные параметры, их варианты, комбинации, пошаговая настройка, типовые шаблоны конфигураций (basic/advanced или вспомним Minimal/Full/Custom в инсталляторах).
Это не весь интерфейс.
F>Всё это упрощает работу и позволяет делать и находить что-то, даже не имея опыта. Текстовые конфиги — без мануалов или опыта и строчки не напишешь, точка.
Нет такой цели — делать без опыта и без чтения документации.
F>Понятно, что у возможностей GUI есть предел, и GUI обёртки над wget/curl выглядят откровенно нелепо (потому что UI нужно уметь проектировать) и ненужно (потому что "wget http://host.com/file.txt" легко запомнить и легко написать), но всё же GUI именно что "помогает" что-то делать. А место CLI — в задачах автоматизации, а не как многие пытаются навязать CLI как единственный правильный интерфейс.
Он помогает ровно настолько же, насколько "Си++ за 21 день" помогает стать программистом.
Здравствуйте, ·, Вы писали:
·>Конечно, настроить нужно — указать адреса, пароли, явки. А дальше у тебя хоть каждые пол часа будут проверяться версии, зависимости, лицензии и т.п. ·>Ты же предлагаешь делать всё вручную, описывая в доках со скриншотами как это делать. Нет, спасибо, я слишком ленивый чтобы этим заниматься.
Я вообще не понимаю зачем это автоматизировать. Мне не нужны последние версии библиотек только потому, что они вышли.
От того, что у меня в проекте появится PR, который в файле проекта версии библиотек перепишет, я его не одобрю.
Если с текущей версией библиотеки есть проблема, то я почитаю чего там менялось, попробую обновиться и перепроверю, что проблема ушла.
Если всё работает нормально, то зачем мне обновляться?
·>Так он это делает сам, автоматически.
Сначала нужно вручную его настроить, а потом не забыть, что обновляется он с какой-то периодичностью.
Выложишь свою библиотеку в свой закрытый репозиторий и жди, когда индекс обновится? Или скорее всего плюнешь и просто пропишешь нужную версию вручную?
·>Ты видимо не понял. pom.xml это и есть документация по сборке, которую читает и выполняет машина. Если там что-то не указано, оно просто не собирается.
Это ты видимо не понял. Как заказчику проверить, что исполнитель ему предоставил собирающиеся исходники и вообще их собирает?
Завтра он захочет отдать проект на доработку другому разработчику и окажется, что на руках у него не всё, что нужно для сборки?
По-моему логично заказчику на своей стороне настроить сборку, тестировать и использовать то, что у него собралось, а не что подрядчик прислал или на своей стороне настроил.
·>У меня будет ошибка "не могу скачать артефакт XXX с сервера YYY — доступ запрещён". И там уже обычно ясно куда и к кому идти и какие пароли для чего искать. ·>У тебя будет ошибка "Нет такого XXX". Дальше что? Куда идти?
Я новому сотруднику предоставлю настроенное рабочее место и документацию о том где что брать.
Ну, вот пришёл новый человек и получил ошибку доступа к репозиторию и что? Пойдёт к своему руководителю и спросит доступ.
Будет ошибка, что нет такого-то пакета — точно так же пойдёт и спросит чего не собирается проект.
Не вижу никакой разницы.
·>Более того, в больших организациях будет какой-нибудь AD, где работнику дают права на сервера и это сразу доступно с его компа, settings.xml поддерживается инфраструктурой. Да и вообще обычно RO-доступ есть по умолчанию.
И конфиг Nuget внезапно прекрасно через AD прокидывается.
Здравствуйте, karbofos42, Вы писали:
K>·>Конечно, настроить нужно — указать адреса, пароли, явки. А дальше у тебя хоть каждые пол часа будут проверяться версии, зависимости, лицензии и т.п. K>·>Ты же предлагаешь делать всё вручную, описывая в доках со скриншотами как это делать. Нет, спасибо, я слишком ленивый чтобы этим заниматься. K>Я вообще не понимаю зачем это автоматизировать. Мне не нужны последние версии библиотек только потому, что они вышли.
Ты тут выше требовал, что тебе непременно нужно 42.7.0, а текущее 42.6.0 тебя не устраивает, т.к. на mvnrepository ты увидел, что вышла новая версия 6 дней назад. Я тоже тебя не понял — зачем, но пытался предложить тебе решение.
K>От того, что у меня в проекте появится PR, который в файле проекта версии библиотек перепишет, я его не одобрю. K>Если с текущей версией библиотеки есть проблема, то я почитаю чего там менялось, попробую обновиться и перепроверю, что проблема ушла. K>Если всё работает нормально, то зачем мне обновляться?
Уменьшать технический долг. Иначе когда тебе понадобится обновиться, выяснится, что при переходе с очень старой версии на нужную всё сломалось и вообще неясно как чинить.
Плюс часто это обязуют делать при обнаружении дыр. Тот же mvnrepository ведёт список Vulnerabilities для библиотек.
K>·>Так он это делает сам, автоматически. K>Сначала нужно вручную его настроить, а потом не забыть, что обновляется он с какой-то периодичностью.
Как и любой автоматический билд... Или собираешь ты тоже вручную?
K>Выложишь свою библиотеку в свой закрытый репозиторий и жди, когда индекс обновится? Или скорее всего плюнешь и просто пропишешь нужную версию вручную?
Индекс для автокомплита, чтобы в процессе набора кода тебе что-то показалось сразу. Апдейт явно провеяет новые версии напрямую.
K>·>Ты видимо не понял. pom.xml это и есть документация по сборке, которую читает и выполняет машина. Если там что-то не указано, оно просто не собирается. K>Это ты видимо не понял. Как заказчику проверить, что исполнитель ему предоставил собирающиеся исходники и вообще их собирает?
Эээ.. что за хрень? А какой-нибудь Newtonsoft.Json у себя на серверах собираешь? И Студию?
K>Завтра он захочет отдать проект на доработку другому разработчику и окажется, что на руках у него не всё, что нужно для сборки?
Т.е. исходников с msbuild-файлом не хватает? Ну это проблема msbuild.
K>По-моему логично заказчику на своей стороне настроить сборку, тестировать и использовать то, что у него собралось, а не что подрядчик прислал или на своей стороне настроил.
Нет, не логично. Или ты gentoo-шник?
K>·>У меня будет ошибка "не могу скачать артефакт XXX с сервера YYY — доступ запрещён". И там уже обычно ясно куда и к кому идти и какие пароли для чего искать. K>·>У тебя будет ошибка "Нет такого XXX". Дальше что? Куда идти? K>Я новому сотруднику предоставлю настроенное рабочее место и документацию о том где что брать. K>Ну, вот пришёл новый человек и получил ошибку доступа к репозиторию и что? Пойдёт к своему руководителю и спросит доступ.
Именно. Он спросит про конкретный сервер, конкретный credentials. Так или иначе придётся как-то оформлять информацию о том какие источники артефактов требуются для каждого конкретного проекта. Лучше это оформлять как часть исходников проекта, а не некая абстрактная документация хз где и хз насколько устаревшая.
Есть такие системы, что при заходе на запрещённый сервер появляется "access denied" и ссылочка "создать тикет". Т.е. к тебе не человек придёт, к тебе придёт запрос заапрувить доступ к ресурсу такому-то человеку.
K>Будет ошибка, что нет такого-то пакета — точно так же пойдёт и спросит чего не собирается проект. K>Не вижу никакой разницы.
Разница в том, что будет инфа о том _где_ этот пакет лежит.
K>·>Более того, в больших организациях будет какой-нибудь AD, где работнику дают права на сервера и это сразу доступно с его компа, settings.xml поддерживается инфраструктурой. Да и вообще обычно RO-доступ есть по умолчанию. K>И конфиг Nuget внезапно прекрасно через AD прокидывается.
А в чём тогда проблема-то тогда? Если тебе очень хочется спрятать информацию о репозиториях, чтоб враг не догадался, ты её можешь разместить в settings.xml на каждом конкретном компе, а не в pom.xml самих проектов. Или вообще через командную строку передавать, пока никто не смотрит.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Ты тут выше требовал, что тебе непременно нужно 42.7.0, а текущее 42.6.0 тебя не устраивает, т.к. на mvnrepository ты увидел, что вышла новая версия 6 дней назад. Я тоже тебя не понял — зачем, но пытался предложить тебе решение.
Я хотел просто актуальную версию из репозитория в новом проекте, а не то, что закэшировалось локально, пока я над другим проектом работал.
Это не значит, что мне в старом проекте нужно что-то автоматом подтягивать.
·>Уменьшать технический долг. Иначе когда тебе понадобится обновиться, выяснится, что при переходе с очень старой версии на нужную всё сломалось и вообще неясно как чинить. ·>Плюс часто это обязуют делать при обнаружении дыр. Тот же mvnrepository ведёт список Vulnerabilities для библиотек.
Хочешь — реагируешь, не хочешь — забиваешь.
·>Как и любой автоматический билд... Или собираешь ты тоже вручную?
Каким образом индекс для помощи в наборе xml связан с билдом?
Я и без него могу вручную добавить зависимость и билду не нужен этот самый индекс.
·>Индекс для автокомплита, чтобы в процессе набора кода тебе что-то показалось сразу. Апдейт явно провеяет новые версии напрямую.
И вот зачем мне эта возня на ровном месте? Что мешало сделать нормально без дополнительныз телодвижений?
·>Эээ.. что за хрень? А какой-нибудь Newtonsoft.Json у себя на серверах собираешь? И Студию?
Я не плачу за написание этой библиотеки и пользуюсь теми же публичными пакетами, что и куча других разработчиков.
·>Т.е. исходников с msbuild-файлом не хватает? Ну это проблема msbuild.
Ну, вот у меня был в жизни опыт, когда организация платила за разработку библиотеки.
Подрядчик им присылал готовый jar-файл, исходники в каком-то виде присылались.
Потом организация решила сама подправить что-то в коде, оказалось, что исходники не собираются, в pom.xml прописаны какие-то серверы подрядчика.
Неделю ковырялись, чтобы это в принципе собралось.
Чья это проблема была? maven плохой? Или просто нужно контролировать что тебе присылают?
·>Нет, не логично. Или ты gentoo-шник?
Ну, доверяй дальше подрядчикам и надейся, что оплаченная разработка в принципе соберётся, а не так, что и деньги потратил и какие-то бинарники есть, а подправить мелкий баг нельзя, т.к. оно не собирается.
·>Разница в том, что будет инфа о том _где_ этот пакет лежит.
Это вопрос организации рабочих процессов и в идеале этих вопросов не должно возникать, т.к. подобные вещи должны той же AD настраиваться.
У меня вот сейчас есть претензия от админов, что я не в тот репозиторий собираю пакеты.
Сейчас они вручную перекинули, но и учётку при этом не дают, чтобы я всё у себя настроил как нужно.
Типа потом разберёмся, а пока так пойдёт.
И что мне в этом случае даёт знание адреса репозитория?
·>А в чём тогда проблема-то тогда? Если тебе очень хочется спрятать информацию о репозиториях, чтоб враг не догадался, ты её можешь разместить в settings.xml на каждом конкретном компе, а не в pom.xml самих проектов. Или вообще через командную строку передавать, пока никто не смотрит.
В том, что я вижу как на Java все вокруг хардкодят репозитории в pom.xml и им пофиг на возможную смену окружения.
Ладно я с этим всем не так плотно работал и многого ещё не знаю, но люди в разных организациях этим занимаются и им нормально.
K>Ну, вот у меня был в жизни опыт, когда организация платила за разработку библиотеки. K>Подрядчик им присылал готовый jar-файл, исходники в каком-то виде присылались. K>Потом организация решила сама подправить что-то в коде, оказалось, что исходники не собираются, в pom.xml прописаны какие-то серверы подрядчика. K>Неделю ковырялись, чтобы это в принципе собралось. K>Чья это проблема была? maven плохой? Или просто нужно контролировать что тебе присылают?
ты натягиваешь виндовый мир .net на жава, в жава мире такое случиться не может, т.к. исходники по определению это то, где работают unit и integration тесты. это только в виндовс мире исходники проверяют визуально и не ожидают в них тестов.
ну и в 21 кантора имела подрядчика, но не имела CI/CD. явно история выдуманная.
Здравствуйте, karbofos42, Вы писали:
K>·>Ты тут выше требовал, что тебе непременно нужно 42.7.0, а текущее 42.6.0 тебя не устраивает, т.к. на mvnrepository ты увидел, что вышла новая версия 6 дней назад. Я тоже тебя не понял — зачем, но пытался предложить тебе решение. K>Я хотел просто актуальную версию
Как это согласуется с "Мне не нужны последние версии библиотек"? Т.е. не нужно, но очень хочется...
K>Это не значит, что мне в старом проекте нужно что-то автоматом подтягивать.
Ну не подтягивай. Я тебе уже показал как можно вручную проверить локально наличие свежего, без автоджобов.
K>·>Уменьшать технический долг. Иначе когда тебе понадобится обновиться, выяснится, что при переходе с очень старой версии на нужную всё сломалось и вообще неясно как чинить. K>·>Плюс часто это обязуют делать при обнаружении дыр. Тот же mvnrepository ведёт список Vulnerabilities для библиотек. K>Nuget при сборке выдаёт предупреждение вида: K>Хочешь — реагируешь, не хочешь — забиваешь.
Как реагировать-то? Вручную? И кто эти варнинги читает и обращает внимание? Это должен быть не варнинг где-то среди сотен-тысяч строк вывода типичного билда, а PR висящий для ревью.
K>·>Как и любой автоматический билд... Или собираешь ты тоже вручную? K>Каким образом индекс для помощи в наборе xml связан с билдом?
Никак. Ты контекст потерял.
K>Я и без него могу вручную добавить зависимость и билду не нужен этот самый индекс.
Билду и не нужен индекс.
K>·>Индекс для автокомплита, чтобы в процессе набора кода тебе что-то показалось сразу. Апдейт явно провеяет новые версии напрямую. K>И вот зачем мне эта возня на ровном месте? Что мешало сделать нормально без дополнительныз телодвижений?
Нормально это как? Вручную?
K>·>Эээ.. что за хрень? А какой-нибудь Newtonsoft.Json у себя на серверах собираешь? И Студию? K>Я не плачу за написание этой библиотеки и пользуюсь теми же публичными пакетами, что и куча других разработчиков.
Ну за Студию-то платишь, надеюсь. И вполне вероятно, что используешь платные библиотеки.
K>·>Т.е. исходников с msbuild-файлом не хватает? Ну это проблема msbuild. K>Ну, вот у меня был в жизни опыт, когда организация платила за разработку библиотеки. K>Подрядчик им присылал готовый jar-файл, исходники в каком-то виде присылались. K>Потом организация решила сама подправить что-то в коде, оказалось, что исходники не собираются, в pom.xml прописаны какие-то серверы подрядчика.
А было бы лучше, если бы просто не собиралось и "не могу найти зависимость"?
K>Неделю ковырялись, чтобы это в принципе собралось.
Непонятно, почему починкой этого не занялся подрядчик.
K>Чья это проблема была? maven плохой? Или просто нужно контролировать что тебе присылают?
Можно, но не нужно в общем случае. Часто не нужно билды настраивать у себя, так изредка проверить локально, что собирается, если доверия к качеству подрядчика нет.
K>·>Нет, не логично. Или ты gentoo-шник? K>Ну, доверяй дальше подрядчикам и надейся, что оплаченная разработка в принципе соберётся, а не так, что и деньги потратил и какие-то бинарники есть, а подправить мелкий баг нельзя, т.к. оно не собирается.
Это больше юридическая проблема, чем техническая.
K>·>Разница в том, что будет инфа о том _где_ этот пакет лежит. K>Это вопрос организации рабочих процессов и в идеале этих вопросов не должно возникать, т.к. подобные вещи должны той же AD настраиваться. K>У меня вот сейчас есть претензия от админов, что я не в тот репозиторий собираю пакеты. K>Сейчас они вручную перекинули, но и учётку при этом не дают, чтобы я всё у себя настроил как нужно. K>Типа потом разберёмся, а пока так пойдёт. K>И что мне в этом случае даёт знание адреса репозитория?
Это знание зафиксированно в исходнике. Админы у себя баги поправят и ты в исходнике это всё поправишь и будет всё работать по уму, а не через одно место.
Если этого не будет в исходнике, то кто и как об этом будет знать? Куда и как деплоить? Откуда брать зависимости? Как поддерживать и валидировать актуальность этой инфы?
K>·>А в чём тогда проблема-то тогда? Если тебе очень хочется спрятать информацию о репозиториях, чтоб враг не догадался, ты её можешь разместить в settings.xml на каждом конкретном компе, а не в pom.xml самих проектов. Или вообще через командную строку передавать, пока никто не смотрит. K>В том, что я вижу как на Java все вокруг хардкодят репозитории в pom.xml и им пофиг на возможную смену окружения.
Ну я говорю, что это не обязательно. Репозитории можно в разных местах определять.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Как это согласуется с "Мне не нужны последние версии библиотек"? Т.е. не нужно, но очень хочется...
Мне не нужно автоматически обновлять библиотеки в существующих проектах, но предпочитаю в новых проектах изначально брать последние версии.
В существующих обновление версии может привести к необходимости допиливания и на это нужно время.
В новых ломаться пока ещё нечему и сразу пишешь на последней версии, т.к. там исправлены баги или что-то новое добавлено, что может пригодиться.
·>Ну не подтягивай. Я тебе уже показал как можно вручную проверить локально наличие свежего, без автоджобов.
Напоминаю, что речь шла о том, что в Nuget это всё есть изначально, без "вручную".
Можно много чего сделать, только мне больше нравятся инструменты, в которых мне удобно, а не про которые нужно документацией обложиться и что-то там изображать, чтобы было сносно.
·>Как реагировать-то? Вручную? И кто эти варнинги читает и обращает внимание? Это должен быть не варнинг, а PR висящий для ревью.
Можно настроить, чтобы варнинги считались ошибками и тогда такое не соберётся и придётся реагировать.
А обработка PR — это не вручную?
А править работу с библиотекой, если в новой версии интерфейсы поменялись и устарели используемые методы — это не вручную?
Чего мне в PR ревьюить, если изменение версии библиотеки — это просто в одном файле цифра поменялась и это справедливо и для MSBuild и для maven и для gradle?
·>Никак. Ты контекст потерял.
По-моему это ты потерялся в своих автоматизациях, которые вручную нужно делать.
·>Нормально это как? Вручную?
Я уже писал: научить репозиторий запросам поиска, чтобы этим всем он занимался, а не каждый клиент выкачивал себе индексы и что-то там с ними делал.
·>Ну за Студию-то платишь, надеюсь. И вполне вероятно, что используешь платные библиотеки.
За исходники студии не плачу. Мне серьёзно вот нужно пояснять разницу между покупкой массового продукта и оплатой разработки под свои хотелки?
·>Непонятно, почему починкой этого не занялся подрядчик.
Потому что он прекратил своё существование или с ним не захотели продлевать договор.
По документам они всё давно предоставил, акты все подписаны, претензий нет.
По факту никто не проверял исходники и что им предоставляли.
Подрядчик же присылал собранные бинарники, они работали — значит всё хорошо же, зачем процесс контролировать и думать о возможности собрать самому или другому подрядчику?
·>Можно, но не нужно в общем случае. Часто не нужно билды настраивать у себя, так изредка проверить локально, что собирается, если доверия к качеству подрядчика нет.
Ага. И бэкапы нужно иногда только делать, ведь мы покупаем качественное железо и доверяем ему.
·>Это больше юридическая проблема, чем техническая.
Даже в школе не прокатывают отмазки типа кошка тетрадку сожрала.
Я просрочку по своему договору не смогу оправдать тем, что меня кинул подрядчик
или у него всё железо изъяли или единственный его разработчик заболел и умер и теперь некому билд сделать в короткие сроки.
Нормальные люди взвешивают риски, продумывают возможные сценарии, а из этого потом рождаются задания техническим специалистам, которые всё это реализуют и решают появляющиеся технические проблемы.
·>Это знание зафиксированно в исходнике. Админы у себя баги поправят и ты в исходнике это всё поправишь и будет всё работать по уму, а не через одно место. ·>Если этого не будет в исходнике, то кто и как об этом будет знать? Куда и как деплоить? Откуда брать зависимости? Как поддерживать и валидировать актуальность этой инфы?
Какое знание где зафиксировано?
У меня в проекте зафиксирован репозиторий, который жив и работает.
Только по факту нужно прописать другой репозиторий, о котором мне никто ничего не сказал и я не знал о его существовании.
Они могли старый репозиторий отключить и я бы сидел с ошибкой, что нет доступа к репозиторию.
Теперь в десятке проектов нужно будет менять репозиторий, а если я захочу собрать старую версию ПО, то придётся опять мудрить, т.к. там не тот репозиторий прописан.
·>Ну я говорю, что это не обязательно. Репозитории можно в разных местах определять.
Ну, вот Nuget плохой, т.к. с ним чаще работают через GUI.
Значит maven плохой, т.к. чаще репозитории прописывают в pom.xml, а не выносят во внешние файлы
Здравствуйте, Gt_, Вы писали:
Gt_>ты натягиваешь виндовый мир .net на жава, в жава мире такое случиться не может, т.к. исходники по определению это то, где работают unit и integration тесты. это только в виндовс мире исходники проверяют визуально и не ожидают в них тестов.
Ты хоть пытался прочитать на что я отвечал?
Gt_>ну и в 21 кантора имела подрядчика, но не имела CI/CD. явно история выдуманная.
CI/CD был, только в него отправляли готовый бинарник от подрядчика, а не собирали библиотеку сами.
Потому что зачем самому собирать? Ты же студию сам не компилируешь?
Gt_>>ты натягиваешь виндовый мир .net на жава, в жава мире такое случиться не может, т.к. исходники по определению это то, где работают unit и integration тесты. это только в виндовс мире исходники проверяют визуально и не ожидают в них тестов.
K>Ты хоть пытался прочитать на что я отвечал?
ты утверждал что подрядчик передавал исходники не имея понятия, что такое исходник в жава мире.
на деле никто не посмотрел что индусы выслали, виндовый своп или исходники.
Gt_>>ну и в 21 кантора имела подрядчика, но не имела CI/CD. явно история выдуманная.
K>CI/CD был, только в него отправляли готовый бинарник от подрядчика, а не собирали библиотеку сами.
люди не отличающие исходники от бинарников, наступили на грабли.
в эпоху индюшачьего аутсорса и шифрователей это конечно умно пускать бинарники.
K>Потому что зачем самому собирать? Ты же студию сам не компилируешь?
если эту студию пишет мой подрядчик, понятно что из исходников буду собирать. инчае грабли новичка неизбежны.
Здравствуйте, karbofos42, Вы писали:
K>·>Как это согласуется с "Мне не нужны последние версии библиотек"? Т.е. не нужно, но очень хочется... K>Мне не нужно автоматически обновлять библиотеки в существующих проектах, но предпочитаю в новых проектах изначально брать последние версии. K>В существующих обновление версии может привести к необходимости допиливания и на это нужно время. K>В новых ломаться пока ещё нечему и сразу пишешь на последней версии, т.к. там исправлены баги или что-то новое добавлено, что может пригодиться.
Т.е. личные предпочтения и заморочки. Т.е. не нужно, но очень хочется. Ну тут наука бессильна.
K>·>Ну не подтягивай. Я тебе уже показал как можно вручную проверить локально наличие свежего, без автоджобов. K>Напоминаю, что речь шла о том, что в Nuget это всё есть изначально, без "вручную".
GUI — это вручную, по определению.
K>·>Как реагировать-то? Вручную? И кто эти варнинги читает и обращает внимание? Это должен быть не варнинг, а PR висящий для ревью. K>Можно настроить, чтобы варнинги считались ошибками и тогда такое не соберётся и придётся реагировать.
Это будет сломанный билд и шоустоппер. Спасибо, не надо.
K>А обработка PR — это не вручную?
Что за обработка?? Это называется peer review. И PR будет в любом случае. Вопрос сколько ручного труда потребуется для создания этого PR. По уму этот PR создаётся автоматически. У тебя этим придётся заниматься тебе — почитать логи билда, найти там варнинги. Выкачать проект локально, прописать новую версию зависимости, закоммитить, запушить и получить в итоге ровно тот же PR, который всё равно нужно так же "обрабатывать", что бы это ни значило.
K>А править работу с библиотекой, если в новой версии интерфейсы поменялись и устарели используемые методы — это не вручную?
Именно, что _если_.
K>Чего мне в PR ревьюить, если изменение версии библиотеки — это просто в одном файле цифра поменялась и это справедливо и для MSBuild и для maven и для gradle?
Ну можешь и автомерж сделать, если очень хочется.
K>·>Никак. Ты контекст потерял. K>По-моему это ты потерялся в своих автоматизациях, которые вручную нужно делать.
Нет. Перечитай, тут все ходы записаны.
K>·>Нормально это как? Вручную? K>Я уже писал: научить репозиторий запросам поиска,
А кто эти запросы будет составлять и посылать? И зачем?
K>чтобы этим всем он занимался, а не каждый клиент выкачивал себе индексы и что-то там с ними делал.
Я уже отвечал. Это делает versions update — смотрит последние версии зависимостей проекта и сообщает что есть нового. Индексы нужны для быстрого набора кода.
K>·>Ну за Студию-то платишь, надеюсь. И вполне вероятно, что используешь платные библиотеки. K>За исходники студии не плачу. Мне серьёзно вот нужно пояснять разницу между покупкой массового продукта и оплатой разработки под свои хотелки?
Тогда обычно работники пушат исходник в твой гит и оттуда всё собирается у тебя, если у подрядчика нет инфры.
K>·>Непонятно, почему починкой этого не занялся подрядчик. K>Потому что он прекратил своё существование или с ним не захотели продлевать договор. K>По документам они всё давно предоставил, акты все подписаны, претензий нет. K>По факту никто не проверял исходники и что им предоставляли. K>Подрядчик же присылал собранные бинарники, они работали — значит всё хорошо же, зачем процесс контролировать и думать о возможности собрать самому или другому подрядчику?
Ну ламеры, что сказать. Тут никакой инструмент не поможет. С таким же успехом чувак без всякого msbuild restore/publish мог собирать локально, зависимости держать в C:\TEMP и слать вам бинари почтой на сидюке.
K>·>Можно, но не нужно в общем случае. Часто не нужно билды настраивать у себя, так изредка проверить локально, что собирается, если доверия к качеству подрядчика нет. K>Ага. И бэкапы нужно иногда только делать, ведь мы покупаем качественное железо и доверяем ему.
Я это к тому, что инструментально это никак не проверяется. Если вы получаете только бинари, а исходники только по актам.
K>или у него всё железо изъяли или единственный его разработчик заболел и умер и теперь некому билд сделать в короткие сроки.
Ну это у школьников только такие проблемы. Исходники собираются на билд-серверах, и раз билд-сервер смог (не важно чей) собрать, то смерть тут не проблема.
K>Нормальные люди взвешивают риски, продумывают возможные сценарии, а из этого потом рождаются задания техническим специалистам, которые всё это реализуют и решают появляющиеся технические проблемы.
Да, при подписании-то актов о приёмке специалисты куда-то потерялись.
ИЧСХ, даже в такой откровенно идиотской ситуации вы смогли за неделю всё восстановить. Ложечки-то нашлись!
K>·>Это знание зафиксированно в исходнике. Админы у себя баги поправят и ты в исходнике это всё поправишь и будет всё работать по уму, а не через одно место. K>·>Если этого не будет в исходнике, то кто и как об этом будет знать? Куда и как деплоить? Откуда брать зависимости? Как поддерживать и валидировать актуальность этой инфы? K>Какое знание где зафиксировано?
Куда и как деплоить. Откуда брать зависимости. Как поддерживать и валидировать актуальность этой инфы.
K>У меня в проекте зафиксирован репозиторий, который жив и работает.
Ты заявлял, что он зафиксирован не в проекте, а в твоих локальных настройках нугета. Ты уж определись.
K>Только по факту нужно прописать другой репозиторий, о котором мне никто ничего не сказал и я не знал о его существовании. K>Они могли старый репозиторий отключить и я бы сидел с ошибкой, что нет доступа к репозиторию. K>Теперь в десятке проектов нужно будет менять репозиторий, а если я захочу собрать старую версию ПО, то придётся опять мудрить, т.к. там не тот репозиторий прописан.
Ну в mvn можно переопределить через командную строку. И все эти "не тот репозиторий" есть в git-истории проекта — все ходы записаны.
K>·>Ну я говорю, что это не обязательно. Репозитории можно в разных местах определять. K>Ну, вот Nuget плохой, т.к. с ним чаще работают через GUI.
Потому что не через GUI работать сложнее и многие автоматизируемые действия приходится делать вручную.
K>Значит maven плохой, т.к. чаще репозитории прописывают в pom.xml, а не выносят во внешние файлы
Это не беда. Если прописанное не работает — значит неактуальная инфа, не повезло, придётся делать то, что делаешь ты сейчас постоянно — выяснить где-то как-то актуальную инфу и вписать её.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Что за обработка?? Это называется peer review. И PR будет в любом случае. Вопрос сколько ручного труда потребуется для создания этого PR. По уму этот PR создаётся автоматически. У тебя этим придётся заниматься тебе — почитать логи билда, найти там варнинги. Выкачать проект локально, прописать новую версию зависимости, закоммитить, запушить и получить в итоге ровно тот же PR, который всё равно нужно так же "обрабатывать", что бы это ни значило.
А у тебя что в автоматическом PR будет? Изменение в файле проекта, что изменилась версия какой-то библиотеки и ты это будешь смотреть и ревьюить?
·>А кто эти запросы будет составлять и посылать? И зачем?
А кто скачивает индексы из репозитория на локальную машину?
Кто составляет запросы к этим локальным индексам?
Кто периодически запрашивает у репозитория новые индексы?
А зачем всё это делать, если можно это возложить на репозиторий?
·>Тогда обычно работники пушат исходник в твой гит и оттуда всё собирается у тебя, если у подрядчика нет инфры.
Чьи работники пушат в мой гит?
С чего вдруг у подрядчика, который занимается разработкой ПО, нет своей инфраструктуры?
·>Ну ламеры, что сказать. Тут никакой инструмент не поможет. С таким же успехом чувак без всякого msbuild restore/publish мог собирать локально, зависимости держать в C:\TEMP и слать вам бинари почтой на сидюке.
Только что ты говорил, что самому у себя собирать неправильно.
Цитаты:
"Обычно по-другому делается — ты билдишь у себя, а клиентам даёшь доступ к своему репо — он оттуда и тянет всё готовенькое."
"Эээ.. что за хрень? А какой-нибудь Newtonsoft.Json у себя на серверах собираешь? И Студию?"
·>Я это к тому, что инструментально это никак не проверяется. Если вы получаете только бинари, а исходники только по актам.
Исходники получали вместе с бинарниками, только ведь проект не на убогом .NET с NuGet, а нормальный Java + maven.
Зачем самим у себя собирать, если разработчики готовые бинарники дают? Или всё же внезапно нужно у себя собирать, а не надеяться на сторонних разработчиков с их инфраструктурой?
·>Ну это у школьников только такие проблемы. Исходники собираются на билд-серверах, и раз билд-сервер смог (не важно чей) собрать, то смерть тут не проблема.
Ну, где-то на чьих-то билд-серверах они собираются, мне то с этого что, если этого сервера у меня нет?
·>Да, при подписании-то актов о приёмке специалисты куда-то потерялись.
Так эти "специалисты" считали, что не нужно самим собирать, а нормально проверять только готовые бинарники.
К бинарникам проблем и не было.
·>ИЧСХ, даже в такой откровенно идиотской ситуации вы смогли за неделю всё восстановить. Ложечки-то нашлись!
Ага. Только пришлось и инфраструктуру поднимать и код править. Потому что у кого-то где-то билд-сервер это собирал, вот у нас же есть все pom.xml, в которых вся нужная документация для сборки и ничего больше не надо.
·>Ты заявлял, что он зафиксирован не в проекте, а в твоих локальных настройках нугета. Ты уж определись.
У меня внезапно есть проекты как на .NET, так и на Java.
В Java-проекте вот репозиторий прописан в pom.xml, т.к. во всех книгах и примерах так пишут и какие соседние проекты смотрел — такая же фигня.
Так чем мне помогает документация в виде фиксации репозитория в pom.xml, если сейчас во всех проектах это нужно переделывать, т.к. админы решили другой репозиторий развернуть?
·>Ну в mvn можно переопределить через командную строку. И все эти "не тот репозиторий" есть в git-истории проекта — все ходы записаны.
И на каждый чих в итоге лезь и разбирайся как это сделать.
Сначала вроде разобрался как в pom.xml указывать, потом разбирайся как через командную строку перегрузить. Очень удобно и продуктивно.
·>Потому что не через GUI работать сложнее и многие автоматизируемые действия приходится делать вручную.
Кому сложнее, а кому удобнее.
Автоматизацией занимаются далеко не все.
Скорее всего, кто-то один на проекте это всё будет настраивать, а у остальных просто всё работает.
И так происходит что в Java, что в .NET, что в остальных проектах.
Или будут сказки о том, что все разработчики, использующие maven, умеют не только зависимости добавлять и копипастить что-то из интернетов, но и сами легко плагин напишут и реализуют сложный сценарий сборки?
Здравствуйте, Gt_, Вы писали:
Gt_>ты утверждал что подрядчик передавал исходники не имея понятия, что такое исходник в жава мире. Gt_>на деле никто не посмотрел что индусы выслали, виндовый своп или исходники.
У тебя какая-то буйная фантазия.
Проект был отечественный, на Java + maven, подрядчик передавал и исходный код и собранные бинарники, к винде имел отношение в виде возможности запуска под ней.
Подрядчик разрабатывал и собирал всё на чём-то из Linux.
Gt_>люди не отличающие исходники от бинарников, наступили на грабли. Gt_>в эпоху индюшачьего аутсорса и шифрователей это конечно умно пускать бинарники.
Чукча не читатель? Или чисто поумничать пришёл, чтобы поспорить со мной о том, о чём я раньше сам и писал?
Здравствуйте, karbofos42, Вы писали:
K>·>Что за обработка?? Это называется peer review. И PR будет в любом случае. Вопрос сколько ручного труда потребуется для создания этого PR. По уму этот PR создаётся автоматически. У тебя этим придётся заниматься тебе — почитать логи билда, найти там варнинги. Выкачать проект локально, прописать новую версию зависимости, закоммитить, запушить и получить в итоге ровно тот же PR, который всё равно нужно так же "обрабатывать", что бы это ни значило. K>А у тебя что в автоматическом PR будет? Изменение в файле проекта, что изменилась версия какой-то библиотеки и ты это будешь смотреть и ревьюить?
Да. И в описании PR будет этот самый варнинг NU1903.
K>·>А кто эти запросы будет составлять и посылать? И зачем? K>А кто скачивает индексы из репозитория на локальную машину? K>Кто периодически запрашивает у репозитория новые индексы?
IDE.
K>Кто составляет запросы к этим локальным индексам?
Редактор кода в IDE.
K>А зачем всё это делать, если можно это возложить на репозиторий?
Репозиториев может быть несколько. Запросы надо слать ко всем. Это будет тормозить. И представь себе какая должна быть мощная инфра.
K>·>Тогда обычно работники пушат исходник в твой гит и оттуда всё собирается у тебя, если у подрядчика нет инфры. K>Чьи работники пушат в мой гит? K>С чего вдруг у подрядчика, который занимается разработкой ПО, нет своей инфраструктуры?
Ты так написал.
K>·>Ну ламеры, что сказать. Тут никакой инструмент не поможет. С таким же успехом чувак без всякого msbuild restore/publish мог собирать локально, зависимости держать в C:\TEMP и слать вам бинари почтой на сидюке. K>Только что ты говорил, что самому у себя собирать неправильно. K>Цитаты: K>"Обычно по-другому делается — ты билдишь у себя, а клиентам даёшь доступ к своему репо — он оттуда и тянет всё готовенькое." K>"Эээ.. что за хрень? А какой-нибудь Newtonsoft.Json у себя на серверах собираешь? И Студию?"
Это обычно так. У тебя какой-то вырожденный случай наёмных работников через третьих лиц.
K>·>Я это к тому, что инструментально это никак не проверяется. Если вы получаете только бинари, а исходники только по актам. K>Исходники получали вместе с бинарниками, только ведь проект не на убогом .NET с NuGet, а нормальный Java + maven. K>Зачем самим у себя собирать, если разработчики готовые бинарники дают? Или всё же внезапно нужно у себя собирать, а не надеяться на сторонних разработчиков с их инфраструктурой?
Верно — в обычных случаях это правильный подход. Ведь ты Newtonsoft.Json и много других либ берёшь в виде бинарников, и не жужжишь.
K>·>Ну это у школьников только такие проблемы. Исходники собираются на билд-серверах, и раз билд-сервер смог (не важно чей) собрать, то смерть тут не проблема. K>Ну, где-то на чьих-то билд-серверах они собираются, мне то с этого что, если этого сервера у меня нет?
Почему тебя Newtonsoft билд-сервера не беспокоят?
K>·>Да, при подписании-то актов о приёмке специалисты куда-то потерялись. K>Так эти "специалисты" считали, что не нужно самим собирать, а нормально проверять только готовые бинарники. K>К бинарникам проблем и не было.
Ну что хотели, то и получили. Не вижу чего их не устраивает.
K>·>ИЧСХ, даже в такой откровенно идиотской ситуации вы смогли за неделю всё восстановить. Ложечки-то нашлись! K>Ага. Только пришлось и инфраструктуру поднимать и код править. Потому что у кого-то где-то билд-сервер это собирал,
Э. И? Если вы никогда не собирали и у вас ничего для сборки никогда не было — как оно у вас магически появится? Хоть с mvn, хоть с msbuild? В следующий раз впишите в акт приёмки docker-image билд-сервера.
K>вот у нас же есть все pom.xml, в которых вся нужная документация для сборки и ничего больше не надо.
Ну да. У вас ничего больше и не было, и у вас таки всё заработало через неделю. ЧТД.
K>·>Ты заявлял, что он зафиксирован не в проекте, а в твоих локальных настройках нугета. Ты уж определись. K>У меня внезапно есть проекты как на .NET, так и на Java. K>В Java-проекте вот репозиторий прописан в pom.xml, т.к. во всех книгах и примерах так пишут и какие соседние проекты смотрел — такая же фигня. K>Так чем мне помогает документация в виде фиксации репозитория в pom.xml, если сейчас во всех проектах это нужно переделывать, т.к. админы решили другой репозиторий развернуть?
А какая альтернатива? Переделывать на всех локальных машинах и билд-серверах?
K>·>Ну в mvn можно переопределить через командную строку. И все эти "не тот репозиторий" есть в git-истории проекта — все ходы записаны. K>И на каждый чих в итоге лезь и разбирайся как это сделать. K>Сначала вроде разобрался как в pom.xml указывать, потом разбирайся как через командную строку перегрузить. Очень удобно и продуктивно.
А что ты предлагаешь? Порыться в емейлах и найти где там предыдущий разработчик рассказывал что куда надо делать?
K>·>Потому что не через GUI работать сложнее и многие автоматизируемые действия приходится делать вручную. K>Кому сложнее, а кому удобнее. K>Автоматизацией занимаются далеко не все. K>Скорее всего, кто-то один на проекте это всё будет настраивать, а у остальных просто всё работает. K>И так происходит что в Java, что в .NET, что в остальных проектах. K>Или будут сказки о том, что все разработчики, использующие maven, умеют не только зависимости добавлять и копипастить что-то из интернетов, но и сами легко плагин напишут и реализуют сложный сценарий сборки?
А какие варианты-то? Сложный сценарий сборки появится магически? Но в целом да, вики-страничку с инструкцией наот**ись написать проще, чем плагин.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
K>У тебя какая-то буйная фантазия. K>Проект был отечественный, на Java + maven, подрядчик передавал и исходный код и собранные бинарники, к винде имел отношение в виде возможности запуска под ней. K>Подрядчик разрабатывал и собирал всё на чём-то из Linux.
в терминах жава подрядчик передал мусор, а не исходники. да, для виндового мира игр это норм посмотреть на расширение файла и ошибочно принять мусор за исходники, при этом запускать бинарники. в корпоративном жава мире такого не бывает.
K>Чукча не читатель? Или чисто поумничать пришёл, чтобы поспорить со мной о том, о чём я раньше сам и писал?
я пришел тебя просветить о том что папочка которая даже не собирается это не исходники в терминах жава. то что ты раньше писал явно на ходу выдумано.
Здравствуйте, Gt_, Вы писали:
K>>У тебя какая-то буйная фантазия. K>>Проект был отечественный, на Java + maven, подрядчик передавал и исходный код и собранные бинарники, к винде имел отношение в виде возможности запуска под ней. K>>Подрядчик разрабатывал и собирал всё на чём-то из Linux.
Gt_>в терминах жава подрядчик передал мусор, а не исходники. да, для виндового мира игр это норм посмотреть на расширение файла и ошибочно принять мусор за исходники, при этом запускать бинарники. в корпоративном жава мире такого не бывает.
Для виндового мира запустил проект в студии и запустил. Если, не заработало, значит подрядчик какую то туфту подкинул!
А тестировать хоть на линуксе Установка Linux в Windows с помощью WSL
Хошь на виндовс.
и солнце б утром не вставало, когда бы не было меня
Что мешает ей же сформировать запрос на поиск пакетов в репозитории, а не самостоятельно с индексами возиться?
·>Репозиториев может быть несколько. Запросы надо слать ко всем. Это будет тормозить. И представь себе какая должна быть мощная инфра.
По моим субъективным ощущениям, с пакетами maven работает медленнее, чем NuGet, и возни с ним больше.
·>Ты так написал.
Или ты это придумал. Подрядчик у себя на своей инфраструктуре как-то собирал же бинарники.
·>Это обычно так. У тебя какой-то вырожденный случай наёмных работников через третьих лиц.
Каких ещё наёмных работников? Обычный такой случай, когда одна компания заказывает у другой разработку ПО.
Или все всегда нанимают себе штат программистов, чтобы они всё на свете делали?
·>Почему тебя Newtonsoft билд-сервера не беспокоят?
Потому что это массовый продукт, по которому можно у людей спросить и сообща разобраться, если будут какие-то проблемы.
Ну и повторяю, что за его исходники я не платил, а когда компания нанимает другую, то обычно хочет иметь исходники проекта,
чтобы потом его можно было развивать и не обязательно силами того же подрядчика.
·>Э. И? Если вы никогда не собирали и у вас ничего для сборки никогда не было — как оно у вас магически появится? Хоть с mvn, хоть с msbuild? В следующий раз впишите в акт приёмки docker-image билд-сервера.
Так надо было собирать у себя, чтобы всегда было рабочее окружение в наличии и точно знать, что тесты есть, проходят, проект собирается.
Ты же мне рассказываешь, что так нормально, разработчик у себя на своей инфраструктуре должен собирать и отдавать готовое.
А как заказчику проверять, что ему реальные исходники прислали, а не набор файлов?
По-моему тут проще заказчику собирать присланные исходники и тестировать получившийся результат, а не верить подрядчику и брать его бинарники.
·>Ну да. У вас ничего больше и не было, и у вас таки всё заработало через неделю. ЧТД.
Только этот pom.xml пришлось редактировать и исходники править.
Если бы pom.xml отсутствовал, то времени ушло на 10 минут больше, т.к. пришлось бы ещё прописать зависимости, исходя из директив import.
·>А какая альтернатива? Переделывать на всех локальных машинах и билд-серверах?
При желании это всё пробрасывается через AD централизованно и не нужно лазить по всем проектам и там переписывать адрес репозитория.
Вопрос в выбранной организации инфраструктуры.
Для NuGet тоже можно в каждый проект конфиг положить и поиметь те же плюсы и минусы.
·>А что ты предлагаешь? Порыться в емейлах и найти где там предыдущий разработчик рассказывал что куда надо делать?
В приличных заведениях есть базы знаний. Подозреваю, что кто осилил автоматизировать сборку, PR и т.п. завёл хотя бы уж какую wiki и минимальную документацию, которой сможет воспользоваться новый сотрудник.
Всё равно всегда будут нюансы типа настройки VPN на домашнем компе, которые придётся документировать.
Даже если будет подготовлен скрипт, который сам всё сделает, нужно его куда-то положить и написать где брать, как запускать.
·>А какие варианты-то? Сложный сценарий сборки появится магически? Но в целом да, вики-страничку с инструкцией наот**ись написать проще, чем плагин.
Каждый сотрудник пишет этот сложный сценарий сборки? Ну, вот Java-джуна возьмём и он на maven сможет изобразить что-то?
Или всё же он сможет только зависимость добавить и на этом всё?
На MSBuild тоже народ делает сложные сценарии, только не думаю, что таких людей очень много.
Лично мне удобнее писать на каком-нибудь Powershell или Cake, чем возиться с xml, но тут опять вопрос предпочтений.
Ну, и сложные сценарии именно сборки достаточно редко встречаются.
Основные сложности идут в собирании всего в кучу, когда разные версии инсталляторов нужно собрать, разные какие-то ресурсы добавить, завесить собранный комплект куда-то на сервер и т.д.
Сама сборка у меня как-то обычно разруливается простой передачей ключей/профилей, а не нагромождением чего-то сложного.
Можно конечно в одну кучу собрать и компиляцию и деплой, но по-моему это в итоге неудобно и превращается в кашу.
Я тоже тебя не понял — зачем, но пытался предложить тебе решение.
