aol-nnov статью прочитал, как она относится к нашему разговору - понять не смог.
Я говорил о том, что для нас release often - это стабильный master, в который абы что не попадает, и с которого почти в любой момент можно выкатить релиз. Что мы и делаем в среднем по 2-3 раза в день. Но это не мешает отдельным разработчикам и даже командам делать долгие и тяжелые фичи.
> и изящность её решения просто поражают воображение!
ну сами сказали про линейность истории и минимум мёрж-коммитов) я потому вам SVN и предложил, там история линейна, зачем усложнять жизнь Git-ом) ну или Git используйте как SVN, коммитьте и пушьте в мастер, разницы особой нет с точки зрения модели ведения разработки.
Я тоже перед первым коммитом стараюсь делать фичебранч с максимально свежего мастера, но с учётом того что фичебранч будет тестироваться, скорее всего мастер уже успеет уйти вперёд, и мёрж-коммита физически не избежать.
Максим по соглашению (сам язык этого не требует) у событий должна быть сигнатура вида (object sender, EventArgs args), поэтому лучше всё-таки унаследоваться от EventArgs. Вы можете создать простейший класс:
class FormEventArgs : EventArgs
{
private readonly FormData formData;
public FormEventArgs(FormData formData)
{
this.formData = formData;
}
public FormData FormData
{
get { return formData; }
}
}
Максим саму структуру вы никак не приведёте, если по-нормальному, то создайте класс-наследник от EventArgs и поместите туда поле типа структуры. Впрочем, не совсем понятно зачем вам это)
aol-nnov Если у вас линейность истории, пользуйтесь SVN) Ну или если нужна стабильная ветка, то держите master и stable, зачем вам тогда фичебранчи вообще) Резко упадёт порог вхождения в процесс.
Фичи бывают разные. Когда вам, к примеру, нужно перелопатить сериализацию всех сохраняемых сущностей, коих может быть эдак 600 классов, а потом еще написать тесты, которые проверят вдоль и поперёк новый подход к сериализации и убедиться, что пользовательские данные не дай бог не испортятся насовсем - врядли вы это сделаете меньше чем за 2 месяца). Не говоря уже о том, что в этой же задаче может аукнуться старый технический долг. Ну или например вы переделываете дизайн сайта, а у вас одних less файлов на мегабайт, из которых вы половину переписали, не говоря уже о написанных с нуля контролах и виджетах. Треть нового дизайна не выкатишь, и половину тоже, даже если заработает, выглядеть будет не очень)).
aol-nnov и да, в чём проблема отката-то? Мёрж коммит откатывается и всё, это и есть "один коммит в мейнлайне" как вы выразились. Как можно "влить 100500" коммитов в "основную ветку", если есть мёрж-коммит, т.е. одна точка соединения мастера и фиче-ветки?
aol-nnov не согласен насчёт скваша всего и вся. Коммит должен выполнять одно осмысленное изменение. Оно может быть на 1 строчку, может быть на 1000 строк в разных файлах. В идеале он еще не должен ломать проект. Понятно что баги будут, но стоит стремиться не коммитить заведемо неработающий код. Вот как раз в таких случаях squash бывает полезен - слепить проблемный коммит и новый нормальный.
Тут мы плавно переходим к вопросу бисекта. Во-первых скошить всё не стоит потому что проблему с фичей нужно не только констатировать, но еще и чинить. Фичи могут делаться по 2 месяца и коммитов может быть штук 100, и мёржить в мастер это не всегда возможно. Если же после мёржа находится баг, то как раз бисект прекрасно может помочь, особенно если программист который делал фичу ушёл в отпуск (вот очень похожая ситуация была у нас летом). В случае нормальных коммитов, т.е. таких которые а) хотя бы собираются нормально и не ломают абсолютно всё; б) которые вносят осмысленные атомарные изменения; поиск проблемного коммита превращается в полуавтоматическую задачу, и пофиксить возможно получится даже без дебага.
Если сквошить как предлагаете вы, то bisect в смёрженных бранчах бесполезен по определению. Мне кажется это неудачный подход.
> "унифицированные", которые позволяют совершать общие действия, но без специфики БД(ADO.NET)?
нет, не правильно. Вы противопоставляете ADO.NET и ODP.NET, это не верно. ADO.NET это НЕ провайдер, это набор интерфейсов. Конкретный провайдер (например, ODP.NET) реализует эти интерфейсы. Нет "специализированных" и "унифицированных" провайдеров. В теории конечно можно написать провайдер, который работает сразу с несколькими СУБД или просто оборачивает какую-то другую технологию доступа (см. провайдеры OleDb и Odbc), но всё равно это будет реализация ADO.NET интерфейсов.
Ещё раз: ADO.NET это НЕ провайдер, это фреймворк доступа к данным, который, помимо прочего, определяет общие унифицированные ИНТЕРФЕЙСЫ для доступа к данным. ODP.NET это провайдер, реализующий эти интерфейсы, конкретно для работы с Oracle.
Если всё еще непонятно, то приведу аналогию. Есть USB интерфейс, есть какой-нибудь собственный разъём на телефонах какого-нибудь Самсунга. USB-интерфейс - это ADO.NET, собственный разъём на телефоне - это сетевой протокол Оракла (который отличается от сетевого протокола какого-нибудь Постгреса). ODP.NET - это кабель-адаптер, на одном конце которого - USB, на другом - штекер для Самсунговского разъёма. Этот "кабель" позволяет подключить телефон к компьютеру - соединить конкретную СУБД и ваше приложение. Если вам нужна другая СУБД (телефон другого производителя) - вы берёте другой кабель, с одной стороны у которого всё также USB-штекер (ADO.NET-интерфейсы), а с другой - штекер для разъёма другого производителя.
Вы с самим дотнетом-то знакомы? Я рассчитывал что ссылки на MSDN прояснят ситуацию)
Smilleey конечно, некоторые вендоры (да тот же Близзард) имеют свою инфраструктуру развёртывания и установки, включая проверку обновлений, даунлоадеры, патчи и всё остальное, но таким обычно заморачиваются только крупные компании, у которых сотни тысяч установок и куча непростых требований.
Smilleey не совсем понимаю, зачем вести именно разработку во внутренней сети. Во внутреннюю сеть достаточно перенести манифесты и файлы приложения. Правда да, могут потребоваться административные учётки. А как вы вообще разворачиваете приложение без участия администраторов, интересно?) Они хоть не против?))
И да, можно поглядеть и на MSI. Это более замороченный вариант, то такой установщик выложить можно вообще как обычный файл. Но тогда вам в приложении нужно будет самостоятельно выполнять проверку обновлений примерно по той же схеме, что вы предложили с EXE, только всё-таки не EXE, а MSI. Версионировать EXE плохая идея: сейчас вам нужен только он, завтра понадобится версионировать и другие сборки, и в конце концов к установщику вы и придёте. Или потратите на разработку деплоя столько же времени, сколько на само приложение.
> Уровни бизнес логики и доступа к данным
Что конкретно у вас на этих уровнях? Их далеко не всегда разделяют. Какие сервисы и классы где расположены? Сущности и доступ к БД через ADO.NET или орм-ку - на уровне данных?
source2003 вы работали с конкретными СУБД, а не с СУБД "NoSQL" и "SQL". Было бы логично указать, с чем вы работали. Если SQL-базы еще более менее похожи друг на друга, то по термину "NoSQL" вообще непонятно, что вы делали - то ли в Монге хранили JSON-документы, то ли пользовались time-series базами, то ли кэшировали запросы в каком-нибудь Redis. Вот это я вам и хотел сказать. Тут одних key-value СУБД столько уже, что целую таблицу можно составлять, не говоря уже о других базах под грифом "NoSQL"
Если слегка преувеличить, ваш вопрос звучит как "Я пользовался стулом (SQL) и другой мебелью (NoSQL). Почувствовал разницу, но до сих пор не могу понять, когда лучше пользоваться стулом, а когда - прочей мебелью". Слишком уж много всего входит в понятие "прочая мебель".
bogdanstefanjuk Если не собираетесь прямо вот завтра устраиваться на работу, т.е. действительно еще есть время поучиться, учите C#, .NET вообще и .NET Core в частности, а также новый ASP.NET Core. Первые программки можно написать консольными или на WinForms, чтобы не заморачиваться сразу с вебом. Наличие работы проверяется на сайтах вакансий, а также выяснением стека технологий фирм в вашем городе. В моём таких достаточно. Сам C# много где еще можно увидеть, особенно в зрелых коммерческих продуктах, но и ASP.NET должен вновь стать популярным, ибо теперь он будет действительно кроссплатформенным.
При таком вендоре как MS и таких вложениях технология врядли исчезнет в ближайшие лет 10. А на больший срок планировать смысла нет, слишком уж быстро ландшафт меняется, всё равно переучиваться придётся (хотя популярности Джавы можно позавидовать).
Максим Иванов и да, собственно альтернативой EAV и является документаная модель данных и документная СУБД (большинство из них работают с JSON или XML документами).
Я говорил о том, что для нас release often - это стабильный master, в который абы что не попадает, и с которого почти в любой момент можно выкатить релиз. Что мы и делаем в среднем по 2-3 раза в день. Но это не мешает отдельным разработчикам и даже командам делать долгие и тяжелые фичи.
> и изящность её решения просто поражают воображение!
ну сами сказали про линейность истории и минимум мёрж-коммитов) я потому вам SVN и предложил, там история линейна, зачем усложнять жизнь Git-ом) ну или Git используйте как SVN, коммитьте и пушьте в мастер, разницы особой нет с точки зрения модели ведения разработки.
Я тоже перед первым коммитом стараюсь делать фичебранч с максимально свежего мастера, но с учётом того что фичебранч будет тестироваться, скорее всего мастер уже успеет уйти вперёд, и мёрж-коммита физически не избежать.