Комментарии 20
Выбран странный способ решения проблемы.
1. Народ вот пишет собственный менеджер пакетов на F# Paket. Довольно успешно все это решает на корню.
2. Порядок компиляции вроде можно менять и вроде даже через GUI.
3. Вы получите 2 версии одной библиотеки после деплоя. Не очень хорошая идея.
Он же может вытащить сорс библиотеки с GitHub.
1. Народ вот пишет собственный менеджер пакетов на F# Paket. Довольно успешно все это решает на корню.
2. Порядок компиляции вроде можно менять и вроде даже через GUI.
3. Вы получите 2 версии одной библиотеки после деплоя. Не очень хорошая идея.
Он же может вытащить сорс библиотеки с GitHub.
Хмм… У меня в статье речь не о том, чтобы сменить пакетный менеджер, а о том, чтобы проверять ряд вещей, где проверки nuget конфигурация — это просто пара пунктов. Ведь твой тул не сможет проверить, что, например, все файлы на диске включены в проект, верно?
Про замену nuget — ок, я не исследовал этот вопрос.
Про замену nuget — ок, я не исследовал этот вопрос.
Ну если я правильно понял, то пример 1 и 2 он покрывает. Если зависимость (т.е. библиотека) прописана правильно, то
восстановит ее. В вашем случает вместо Resharper импортом будет заниматься сам менеджер пакетов. Как, на пример, HTTP dependency. Ну или
скачает и установит все заново.
Хотя если делать просто, то можно в свойствах проекта просто прописать pre-build action и через xcopy гарантированно копировать файлы (он ругается если не находит).
Эту часть я не совсем понял. Почему при отсутствии файлов проект вообще прошел тесты и запустился на CI сервере. Даже если это только зеленые тесты существующей функциональности то как получилось что и ПМ и кодер пропустили эту часть.
Что как бы говорит о мотивации в команде.
Либо неправильных процессах. Т.к. тот кто последний использовал ныне не используемые файлы должен был их удалить.
paket auto-restore
восстановит ее. В вашем случает вместо Resharper импортом будет заниматься сам менеджер пакетов. Как, на пример, HTTP dependency. Ну или
paket update [--force|-f]
скачает и установит все заново.
Хотя если делать просто, то можно в свойствах проекта просто прописать pre-build action и через xcopy гарантированно копировать файлы (он ругается если не находит).
Например, один раз при неправильном git merge у нас из проекта с модульными тестами выпало около трети файлов. Заметили это, конечно, не сразу, к тому времени мы упустили уже несколько багов.
Эту часть я не совсем понял. Почему при отсутствии файлов проект вообще прошел тесты и запустился на CI сервере. Даже если это только зеленые тесты существующей функциональности то как получилось что и ПМ и кодер пропустили эту часть.
Что как бы говорит о мотивации в команде.
Либо неправильных процессах. Т.к. тот кто последний использовал ныне не используемые файлы должен был их удалить.
Не понимаю… Зачем приводить командные строки? Допустим, у нас проектов 50. В 30 их них есть пакет А. В 20 нет. И также допустим, что мы хотим начать использовать какой-то интерфейс из пакета А в одном из 20 проектов. В случае, когда нет ошибок программиста, надо всегда подумать и подключить dll правильно, с помощью командной строки: Install-Package для nuget или packet для другого пакетного менеджера. Это будет правильно, спору нет. Я же показываю ситуацию, когда dll подключена в обход менеджера пакетов, т.е. ошибка программиста. В случае SolutionCop система автоматом поймает такую ситуацию. А как ты рассказываешь, что надо опять человеку подстраховать (ага, в век автоматизации).
В проекте, допустим, 300 файлов. После неправильного мержа пропало около 200. Так как это unit тесты, на них никто особо не ссылается, а значит в результате пропажа не видна после прогона тестов. merge проходит мимо code review, а потому получаем вот такую штуку. И как ПМ должен был не пропустить? Проверять каждый merge?
Почему при отсутствии файлов проект вообще прошел тесты и запустился на CI сервере.
В проекте, допустим, 300 файлов. После неправильного мержа пропало около 200. Так как это unit тесты, на них никто особо не ссылается, а значит в результате пропажа не видна после прогона тестов. merge проходит мимо code review, а потому получаем вот такую штуку. И как ПМ должен был не пропустить? Проверять каждый merge?
Занимаясь автоматизацией билдов, я проверял статусы пару раз каждый день, плюс регулярные проверки тим-лида. Потеря 200 файлов — это сокращение тогдашнего билда минут на 10, и уменьшение числа тестов. Так что ошибка обнаруживается за 4-8 часов.
Но в целом, если тула ставится из коробки, настраивается один раз на солюшн и отнимает меньше у.е. времени при билде — вполне себе нормальный инструмент. Проблемы с версиями и отсутствием либ редкие, но времени на исправление могут отнять немало.
Но в целом, если тула ставится из коробки, настраивается один раз на солюшн и отнимает меньше у.е. времени при билде — вполне себе нормальный инструмент. Проблемы с версиями и отсутствием либ редкие, но времени на исправление могут отнять немало.
Я же показываю ситуацию, когда dll подключена в обход менеджера пакетов, т.е. ошибка программиста.
Ошибка программиста это в первую очередь подключение dll в обход менеджера пакетов. Даже если оставить несчастный Paket в покое и у вас супе-пупер закрытые библиотеки для собственного пользования )) то всегда можно прописать собственные фиды в NuGet (https://docs.nuget.org/create/hosting-your-own-nuget-feeds), снять (myGet & Co) или даже поднять собственный NuGet сервер. И забыть про все проверки.
а значит в результате пропажа не видна после прогона тестов.
Пропавшие Unit будет видно как минимум на Code Coverage ;)
merge проходит мимо code review, а потому получаем вот такую штуку. И как ПМ должен был не пропустить? Проверять каждый merge?
Вот смотрите, кто-то (скорее всего ПМ) эти тесты заказал (ну не робот же) и скорее всего они ему нужны, раз уж ему выделили на это ресурсы (людей/часы).
Перед началом каждой итерации/спринта/фазы/и тд. мы ставим себе цель и задаем метрики. В случае тестов это повышение качества и стабильности кода. Допустим покрыть тестами этот модуль, было 200 нужно 300.
В конце итерации кто-то (ПМ) должен проверить сделана ли работа и что получилось. И подумать что делать дальше.
Это его работа. Как докажете шефам что не устроили себе каникулы за счет работодателя?
меня вот кстати напрягает что нельзя пакет поставить сразу для солюшена. ну вот серьёзно. есть у меня какой-нибудь NLog (или log4net). я не хочу руками его ставить в каждый солюшен. никак нельзя его сразу всюду? ну только без советов в духе «достаете повершел»
Можно кликнуть правой по солюшену и выбрать «Manage NuGet packages for solution...». А там уже проставить чекбоксы.
На уровне солюшена открываете управление пакетами NuGet и ставите галочки напротив всех проектов, куда надо этот пакет добавить. Делов то.
Слушайте, вы мне прям жизнь спасли. Ведь она там и правда есть эта кнопка. А я её искал и не находил.
Справедливости ради, Melz опередил меня с ответом на пару секунд.
ну да, и было бы клева пакет с гитхаба подключать
НЛО прилетело и опубликовало эту надпись здесь
Ну на самом деле довольно часто. Если проект большой то части пишутся как библиотеки и подключаются к гуи.
Или допустим если разработка идет под разные платформы, логика выносится в общий проект. В Win8 такое было: телефон, планшет, десктоп.
Или допустим если разработка идет под разные платформы, логика выносится в общий проект. В Win8 такое было: телефон, планшет, десктоп.
> На работе мне достался такой солюшен
> я просто объединил все проекты в один, стало гораздо проще
Видимо у вас был очень маленький проект-прототип на котором это не имеет смысла.
На средних и больших проектах (да и на маленьких тоже), где много слоев абстракции, под сотню модулей, разбитие на солюшены жизненно необходимо.
> я просто объединил все проекты в один, стало гораздо проще
Видимо у вас был очень маленький проект-прототип на котором это не имеет смысла.
На средних и больших проектах (да и на маленьких тоже), где много слоев абстракции, под сотню модулей, разбитие на солюшены жизненно необходимо.
Самая элементарная вещь — инкапсуляция. Модификатор internal защищает код проекта от внешнего доступа. Если все проекты слить — защита падет. Размываются интерфейсы, увеличивается вероятность прострелить себе ногу.
Чуть менее элементарная — конфликты слияния. Когда в один проект коммитят 20 разработчиков, при добавлении\переименовании\добавлении файлов конфликты слияния будут возникать чаще, чем при разработке «каждый разраб пилит свой проект». Каждый конфликт слияния — это потеря времени минимум одного человека.
Есть еще переносимость. Если часть кода используют несколько приложений, разумнее выделить её в проект\сервис, поддерживать и изменять будет проще.
Поиск коммита поломавшего солюшн. Локализовав ошибку с точностью до проекта, можно банально посмотреть последние коммиты и узнать в каком из них ошибка. В один проект из 20 коммитят где-то раз в 20 меньше, чем в один проектосолюшн.
Время сборки. Билд слитого-из-20 проекта может длиться пару минут, в то время как билд малого проекта — несколько секунд.
Время тестирования. Модульные тесты на проект проходят быстрее модульных тестов на солюшн. Если разрабатываете малыми итерациями, гонять тесты всего солюшна может быть накладно.
Работать со слитым проектом можно, но это неудобнее, чем работать с 20 малыми проектами: больше времени на поиск ошибок, больше времени на тесты\билды, выше вероятность ошибки. Как верно заметили ниже, если проект небольшой — проблем нет. Если же проект кроссплатформенный\пишется большой командой\содержит много логики — стоит разбить его на проекты.
Чуть менее элементарная — конфликты слияния. Когда в один проект коммитят 20 разработчиков, при добавлении\переименовании\добавлении файлов конфликты слияния будут возникать чаще, чем при разработке «каждый разраб пилит свой проект». Каждый конфликт слияния — это потеря времени минимум одного человека.
Есть еще переносимость. Если часть кода используют несколько приложений, разумнее выделить её в проект\сервис, поддерживать и изменять будет проще.
Поиск коммита поломавшего солюшн. Локализовав ошибку с точностью до проекта, можно банально посмотреть последние коммиты и узнать в каком из них ошибка. В один проект из 20 коммитят где-то раз в 20 меньше, чем в один проектосолюшн.
Время сборки. Билд слитого-из-20 проекта может длиться пару минут, в то время как билд малого проекта — несколько секунд.
Время тестирования. Модульные тесты на проект проходят быстрее модульных тестов на солюшн. Если разрабатываете малыми итерациями, гонять тесты всего солюшна может быть накладно.
Работать со слитым проектом можно, но это неудобнее, чем работать с 20 малыми проектами: больше времени на поиск ошибок, больше времени на тесты\билды, выше вероятность ошибки. Как верно заметили ниже, если проект небольшой — проблем нет. Если же проект кроссплатформенный\пишется большой командой\содержит много логики — стоит разбить его на проекты.
Я бы предпочёл чтобы работало например как плагин к SonarQube/SonarLint чем настраивать надцатый анализатор кода.
Отличное решение! Спасибо вам большое. Прикрутил к своим проектам.
Раньше такое геморрой был все эти проверки делать вручную. Особенно вечная проблема: у Васи собирается, а у Пети нет, потому что где-то закралась ссылка не в то место. А то что бывает устаревший AutomaticPackagesRestore, я даже не подозревал :)
Раньше такое геморрой был все эти проверки делать вручную. Особенно вечная проблема: у Васи собирается, а у Пети нет, потому что где-то закралась ссылка не в то место. А то что бывает устаревший AutomaticPackagesRestore, я даже не подозревал :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
SolutionCop