Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>Здравствуйте, AlexNek, Вы писали:
AN>>Здравствуйте, Qbit86, Вы писали:
Q>>>Здравствуйте, AlexNek, Вы писали:
AN>>>>А также когда их брать?
Q>>>Когда угодно. У тебя стоит ссылка на пакет версии 3.4.0.128. То, что на билд-сервере появляются версии 3.4.0.129, 3.4.0.130, etc твою программу не ломает. То же, что и со сторонними библиотеками. Скажем, используешь ты NUnit 2.5.9.10348. То, что вышла новая версия NUnit 2.5.10.11092 никоим образом на твою программу повлиять не может, пока ты сам не решишь обновиться. AN>>Во внутренности NUnit мне не нужно лезть. Допустим получил я от библииотеке 0, а должно быть 5. Лезешь с отладкой и видишь что 0 ну никак не может получится. А это просто версии исходников и либы не совпадают. A_A>Нужно собирать либу с такой версией, чтобы можно было найти реальные исходники.
Кто и как будет проверять версию Длл-ки при входе в функцию?
AN>>>>А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.
Q>>>Не понял вопрос. Твоя переиспользуемая библиотека теперь выглядит так же, как не твоя переиспользуемая библиотека. От которой у тебя нет, и не нужны исходники. Все проекты всегда ссылаются на точную версию строгоименованной библиотеки. AN>>Кажется, я уловил проблему. Все будет работать когда ВСЕ проекты подключены как Длл-ки (исключая вариант с отладкой кода). Но если я разработчик и мне нужно иметь актуальную версию Длл-ки, то их получается уже две версии. Одна собранная по исходникам, другая из репозитория. Дя какого-то небольшого количества еще можно все отследить, но когда и тех и других достаточно много да и еще со сложными зависимостями, остается только ждать накладки. AN>>Должен быть всегда один источник и смешанная работа просто не допускается. Или всегда абсолютно все свои текущие проекты как Длл-ки с сервера или все подключения через проекты (кроме чисто библиотечных, считаемых как бы не своими). То есть если есть иерархия проектов, то вся ветка либо/либо, но никак не комбинация в ветке. A_A>Да. перемешивать нельзя — бардак будет еще тот.
А как тогда работать разработчику Длл-ки? Причем один разработчик часто отвечает за более чем одну Длл-ку?
Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>А какая СКВ позволяет делать это автоматически?
Любая распределенная.
A_A>Я хочу сделать новую версию общей части для одного клиента:
В это время другой программист захотел сделать тоже самое.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Re[6]: Как лучше подключать подпроекты - DLL или исходники ч
Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>В изначальном посте о необходимости версионирования исходников не было сказано, A_A>поэтому вариант с подключением сорцов из транка как SVN:externals является нормальным.
Подключения без фиксирования ревизии не может быть нормальным.
Ибо ты потом не сможешь вытащить ту же версию исходников, с которой собирал.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AlexNek, Вы писали:
A_A>>1) Если нет человека с такой должностью — нужно завести должность и взять человека AN>А зачем, когда можно вполен обойтись без него просто использую другой подход.
Так в чем проблема? Используйте тот подход, который для Вас более выгоден. A_A>>2) Совмещать кому-то из существующих AN>Совмещать несколько празличных заданий особенно в стрессе релиза чревато.
+1
A_A>>Брать тогда, когда нужна новая функциональность. A_A>>На каждую версию создавать ветки в СВН — если хочешь чтобы код соответствовал бинарникам(в моей практике это было не нужно). AN>Уж сколько помню всегда с этим были проблемы.
+1
A_A>>Извини, но с таким подходом к разработке надо улучшать процессы разработки. A_A>>Создается новая версия библиотеки -> она выкладывается куда-то в шару -> делается описание внесенных изменений -> идут уведомления клиентам о новой версии. AN>Дело не идет о библиотеке и внешних клиентах, там все по другому. Разговор о команде разрабатывающей достаточно большой проект, скажем с полтинником подпроектов. И все проиходит именно на этапе разработки.
Вот именно в этом случае пригодится юзание библиотек.
Если был бы простенький проект на 2-3 человека с 10-15 проектами — тогда бы овчинка выделки не стоила и юзание сорцов по ссылке было удобнее.
Re[5]: Как лучше подключать подпроекты - DLL или исходники ч
Здравствуйте, AlexNek, Вы писали:
AN>Значит голос за Длл-ки?
А как быть тогда с совмещением ссылок на Длл-ки и проекты?
Можно по-детальней?
Что делать разработчику именно этой Длл-ки в проекте?
тут есть два варианта:
1)Длл-ка принадлежит другой команде — вносится тикет на создание в ней фичи и ждем, когда эта команда нам выдаст новую длл-ку.
2)длл-ка наша — мы сами с ней делаем что хотим и не ждем никогда
И что делать остальным когда исходники уже в репозитории, но бильд длл-ок еще не готов. Ждать пока не будет все готово и после все брать?
Тут надо это дело автоматизировать, конечно.
Унас так:
1)коммитим исходники
2)берем номер нового билда
3)меняем на клиенте версию на новую
4)запускаем батник
И все.
А если в это же время закоммитились другие изменения, которые нужно пока избежать? (Допустим они исправили генерацию данных, и неправильные данные для теста уже получить просто невозможно)
Это сложный вопрос. Опять же:
1) Если длл-ка ваша — то вы всегда в курсе всех изменений
2) Тут надо отслеживать все изменения с текущей версии по ту, которую хотите заюзать.
То есть нужно отслеживать два источника: исходники и бинарники, и к тому же учитывать иерархию бинарников.
1) Если длл-ка ваша — вы следитие только за сорцами — на версии вам пофиг
2) Следите только за изменениями в функционале и версиями — на сорцы вам пофиг
С такими юз-кейсами ссылки на версионированные исходники, имхо, будут нести большой геморрой.
Тут на помощь конечно приходит CI, NuGet и хорошее покрытие тестами общего фцнкйионала.
Re[5]: Как лучше подключать подпроекты - DLL или исходники ч
Здравствуйте, AlexNek, Вы писали:
AN>Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>>Здравствуйте, AlexNek, Вы писали:
A_A>>>>ИМХО, однозначно только использовать подключение библиотек. A_A>>>>Назовем ради примера: A_A>>>>общая часть — сервер, A_A>>>>пользователи общей части — клиенты. AN>>>То есть пример практически не связанного кода. Максимум — протоколы обмена, видимо. A_A>>Отнюдь не только. Библиотеки .NET Framework — это связанный код с твоими проектами или нет? AN>А у меня есть исходники .NET Framework в проекте?
Догадываюсь, что нету.
Так значит юзание библиотек является достаточным.
Здравствуйте, AlexNek, Вы писали:
Q>>>>Можно пристально посмотреть в сторону svn:externals. AN>>>Админ, блин подключил так дев ехпресс, так теперь в каждом проекте своя копия. Ужас просто. A_A>>На сервере лежит только одна копия исходников, а на клиенте — да, на каждый svn:externals плюс одна локальная копия. A_A>>Почему ужас-то? Места на диске не хватает? AN>Допустим я обновляю версию бибилотеки, но вначале чисто для теста, как будет у меня работать. Теперь вместо одной замены нужно делать Х. Либо я могу для отладки просто сбилдить Длл-ки из исходников локально. Опять надо искать механизм подмены всех версий.
В случае ссылок на исходники количество телодвижений будет тоже.
А механизм подмены версий искать — да, надо — но это уже другая тема. Q>>>>И вообще, повлиять на руководство в сторону приобщения к правильным и удобным инструментам. AN>>>Для этого нужно полностью менять/перестраивать все сопутствующее окружение которое настраивалось и подключалось разными людьми в течении многих лет. A_A>>Идешь к руководству с аргументами типа: после этих изменений мы будем меньше тратить времени на разработку -> и тут варианты: A_A>>время на разработку уменьшится — экономия бабла для заказчика AN>ну это еще нужно доказать что время на разработку действительно Существенно уменьшится, в чем я несколько сомневаюсь. A_A>>заказчик будет получать продукты быстрее — сможет выходить на рынок с новым продуктом раньше — получение новых прибылей для заказчика A_A>>система будет более стабильна(будет меньше возможных багов) — вероятность потери клиентов для заказчика снизится — заказчик будет меньше терять бабла AN>Как система контроля версий влияет на количество багов?
Я говорю не за СКВ, а за исключение потенциальной возможности изменений исходников людьми, которые не должны этого делать в данный момент.
A_A>>С такими аргументами нормальное руководство утверждает. AN>А кто, сколько времени и на что будет перестраивать все остальное?
делаете предварительные исследования в свободное от работы время(это на самом деле вам же, разработчикам, нужно )
закидываете ссылками, что это можно сделать
берете время
делаете
Здравствуйте, AlexNek, Вы писали:
Q>>>>Когда угодно. У тебя стоит ссылка на пакет версии 3.4.0.128. То, что на билд-сервере появляются версии 3.4.0.129, 3.4.0.130, etc твою программу не ломает. То же, что и со сторонними библиотеками. Скажем, используешь ты NUnit 2.5.9.10348. То, что вышла новая версия NUnit 2.5.10.11092 никоим образом на твою программу повлиять не может, пока ты сам не решишь обновиться. AN>>>Во внутренности NUnit мне не нужно лезть. Допустим получил я от библииотеке 0, а должно быть 5. Лезешь с отладкой и видишь что 0 ну никак не может получится. А это просто версии исходников и либы не совпадают. A_A>>Нужно собирать либу с такой версией, чтобы можно было найти реальные исходники. AN>Кто и как будет проверять версию Длл-ки при входе в функцию?
Тут поможет перегрузка функций, если уж совсем никак.
AN>>>>>А будет ли обеспечено, что исходники всех разработчиков будут точно сообтветствовать бинарникам.
Q>>>>Не понял вопрос. Твоя переиспользуемая библиотека теперь выглядит так же, как не твоя переиспользуемая библиотека. От которой у тебя нет, и не нужны исходники. Все проекты всегда ссылаются на точную версию строгоименованной библиотеки. AN>>>Кажется, я уловил проблему. Все будет работать когда ВСЕ проекты подключены как Длл-ки (исключая вариант с отладкой кода). Но если я разработчик и мне нужно иметь актуальную версию Длл-ки, то их получается уже две версии. Одна собранная по исходникам, другая из репозитория. Дя какого-то небольшого количества еще можно все отследить, но когда и тех и других достаточно много да и еще со сложными зависимостями, остается только ждать накладки. AN>>>Должен быть всегда один источник и смешанная работа просто не допускается. Или всегда абсолютно все свои текущие проекты как Длл-ки с сервера или все подключения через проекты (кроме чисто библиотечных, считаемых как бы не своими). То есть если есть иерархия проектов, то вся ветка либо/либо, но никак не комбинация в ветке. A_A>>Да. перемешивать нельзя — бардак будет еще тот. AN>А как тогда работать разработчику Длл-ки? Причем один разработчик часто отвечает за более чем одну Длл-ку?
А в чем проблема-то?
Просто надо больше комунницировать, чтобы о таких изменениях все были в курсе.
Почитайте про scrum.
Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>>А какая СКВ позволяет делать это автоматически? WH>Любая распределенная.
давайте уточним, что мы имеем ввиду одно и тоже.
Имеем:
1)Общий функционал, который лежит в своем репозитории.
2)Куча проектов, раскиданных по разным репозиториям, которые будут юзать этот общий проект(как физическую ссылку в VS)
и эти все проекты будут версионироваться.
Нужно:
1)Сделать версионирование общего функционала
2)Иметь возможность быстрого переключения версий общего функционала
3)Запретить некоторым юзерам менять общий функционал
Как распределенная скв будет делать это автоматически?
A_A>>Я хочу сделать новую версию общей части для одного клиента: WH>В это время другой программист захотел сделать тоже самое. WH>
В обоих случаях топикстартера это возможно.
Re[7]: Как лучше подключать подпроекты - DLL или исходники ч
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>>В изначальном посте о необходимости версионирования исходников не было сказано, A_A>>поэтому вариант с подключением сорцов из транка как SVN:externals является нормальным. WH>Подключения без фиксирования ревизии не может быть нормальным. WH>Ибо ты потом не сможешь вытащить ту же версию исходников, с которой собирал.
дык, я солидарен, что если требуется версионирование общей части, то подключение исходников как
SVN:externals несет в себе больше возможных неприятностей, чем юзание библиотек
Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>>Если на любые изменения в сервере делать ветки в СКВ
Да не надо никакие ветки вручную делать, предполагалось просто, что у разных людей ссылки на ревизии разной степени свежести.
A_A>>и менять ссылки у клиентов на новый урл, то да — в данной ситуации различий нет. :beer:
Пошла какая-то мешанина из сборки сервера и деплоймента сервера в продакшн. Или я чего-то не понял? Давай рассмотрим пример проще, не клиент-сервер, а БиблиотекаПримитивов и ВысокоуровневаяОбёртка. Чтоб без урлов.
A_A>Кстати, в этом случае тебе придется делать отдельные билд-конфигурации на CI для каждой ветки.
Здравствуйте, Andrii_Avramenko, Вы писали:
Q>>У тебя есть ссылка на dll'ку, методы в которой хочешь пройти пошагово. Но у тебя нет PDB. Значит его нужно отдельно собрать из исходников. Т.е. опять же решить проблему, какая версия исходников соответствовала той версии dll'ки, на которую у тебя ссылка.
A_A>Поставлять PDB вместе с DLL. A_A>Мы так и делаем — в NuGet пакете PDB вместе с DLL.
Откровенно говоря, я не знаю деталей внутреннего устройства PDB и тонкостей их распространения вместе в библиотеками. Но во всех (немногочисленных, но без исключения) NuGet-пакетах, которые таки содержали PDB-файлы, при открытии последних видны строки типа «C:\Users\VasyaPupkin\SomeProject\SomeModule\SomeClass.cs». Простите мне моё невежество, но, емнип, я никогда не использовал чужие pdb. Скажите, они вообще работают? И если да, то как? Я так понимаю, они нужны для связи символов с исходниками. И судя по тому, что я вижу внутри pdb-файла, они связывают символы с исходниками разработчика, а не моим комплектом исходников.
Глаза у меня добрые, но рубашка — смирительная!
Re[8]: Как лучше подключать подпроекты - DLL или исходники ч
Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>1)Сделать версионирование общего функционала
А версионник у нас чем занимается?
A_A>2)Иметь возможность быстрого переключения версий общего функционала
А версионник нам на что? Они прекрасно справляются с вытаскиванием другой равизии.
A_A>3)Запретить некоторым юзерам менять общий функционал
Зачем запретить?
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AlexNek, Вы писали:
AN>PDB то будет идти с Длл-кой, но вот гарантировать совместимость исходников с ними, да проблема. AN>И кстати, как сгенерить PDB без DLL-ки?
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>>>Если на любые изменения в сервере делать ветки в СКВ
Q>Да не надо никакие ветки вручную делать, предполагалось просто, что у разных людей ссылки на ревизии разной степени свежести.
A_A>>>и менять ссылки у клиентов на новый урл, то да — в данной ситуации различий нет.
Q>Пошла какая-то мешанина из сборки сервера и деплоймента сервера в продакшн. Или я чего-то не понял? Давай рассмотрим пример проще, не клиент-сервер, а БиблиотекаПримитивов и ВысокоуровневаяОбёртка. Чтоб без урлов.
A_A>>Кстати, в этом случае тебе придется делать отдельные билд-конфигурации на CI для каждой ветки.
Q>Нет. Есть конфигурация для клиента и сервера.
Тогда разницы нет, за исключением случая, что девелопер ВысокоуровневойОбёртки может внести изменения и закоммитить код БиблиотекиПримитивов.
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Andrii_Avramenko, Вы писали:
Q>>>У тебя есть ссылка на dll'ку, методы в которой хочешь пройти пошагово. Но у тебя нет PDB. Значит его нужно отдельно собрать из исходников. Т.е. опять же решить проблему, какая версия исходников соответствовала той версии dll'ки, на которую у тебя ссылка.
A_A>>Поставлять PDB вместе с DLL. A_A>>Мы так и делаем — в NuGet пакете PDB вместе с DLL.
Q>Откровенно говоря, я не знаю деталей внутреннего устройства PDB и тонкостей их распространения вместе в библиотеками. Но во всех (немногочисленных, но без исключения) NuGet-пакетах, которые таки содержали PDB-файлы, при открытии последних видны строки типа «C:\Users\VasyaPupkin\SomeProject\SomeModule\SomeClass.cs». Простите мне моё невежество, но, емнип, я никогда не использовал чужие pdb. Скажите, они вообще работают? И если да, то как? Я так понимаю, они нужны для связи символов с исходниками. И судя по тому, что я вижу внутри pdb-файла, они связывают символы с исходниками разработчика, а не моим комплектом исходников.
pdb дает нам возможность узнать номера строк в файлах при исключениях
версию исходников мы узнаем из версии пакета
Это конечно мало поможет, если версия будет очень старой, но если версия последняя — можно пофиксить, как говорится "не отходя от кассы исключения"
Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>Тогда разницы нет, за исключением случая, что девелопер ВысокоуровневойОбёртки может внести изменения и закоммитить код БиблиотекиПримитивов.
Ещё может легко и непринуждённо по ней отлаживаться. Найти какой-нибудь мелкий баг, не отходя от кассы его исправить.
Глаза у меня добрые, но рубашка — смирительная!
Re[9]: Как лучше подключать подпроекты - DLL или исходники ч
Здравствуйте, WolfHound, Вы писали:
A_A>>3)Запретить некоторым юзерам менять общий функционал WH>Зачем запретить?
потому что они джуниоры и не имеют еще достаточной квалификации, чтобы менять критически важную для проекта часть
Здравствуйте, Qbit86, Вы писали:
Q>Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>>Тогда разницы нет, за исключением случая, что девелопер ВысокоуровневойОбёртки может внести изменения и закоммитить код БиблиотекиПримитивов.
Q>Ещё может легко и непринуждённо по ней отлаживаться. Найти какой-нибудь мелкий баг, не отходя от кассы его исправить.
Здравствуйте, Andrii_Avramenko, Вы писали:
A_A>pdb дает нам возможность узнать номера строк в файлах при исключениях
А также пути этих файлов в папке разработчика. Мне однажды так удалось выйти на разработчика одной библиотеки — выгуглился по Windows-аккаунту, который фигурировал в путях к исходникам.
A_A>pdb дает нам возможность узнать номера строк в файлах при исключениях
Мне важнее уметь зайти в код вызываемой функции. Т.е. чтоб отладчик с помощью этого *.pdb умел связывать *.dll и *.cs. Насколько я понимаю, это достигается тем, что в pdb вшивается информация об окружении конкретного разработчика (в частности пути к исходникам, которые среда должна открыть в процессе отладки), который сгенерировал этот pdb-файл.
A_A>версию исходников мы узнаем из версии пакета
Версия пакета покажет только номер ревизии, которая уникальная только в рамках одного клона репозитория (в случае распределённых VCS). Уникальный по всем репозиториям changeset id представляет из себя 40-символьный хэш, его так просто в версию пакета не запихнёшь, нужна заморачиваться с кастомным атрибутом, например. Потом лезть в манифест dll-ки, чтоб его узнать.
Т.е. принципиальная возможность идентифицировать версию исходников по бинарнику быть должна, но постоянно пользоваться таким способом — удовольствие сомнительное.
