Так я про решение этой задачи в вашем конкретном решении по "отдавать версию под каждую фичу" из статьи спрашиваю, зачем мне ссылки на курсы. "Мы оставили это за скобками и БД решением не покрыты" - простая и понятная фраза, хоть и не объясняет как же каждая отдельная фича самостоятельно может существовать, если в реализации фичи задействованы БД.
Тэги в Obsidian как раз иерархичны, иерархия понимается через слэш:
#my/best/tag
будет найден в т.ч. при фильтрации по #my, #my/best
Заметки не имеют иерархии
Так оно всё про семантику, не про каталог. При этом _явная группировка_ карточек складыванием в папку доступна. А развесистое дерево папочек в общем и целом противоречит идеологии и Цеттелькастена, и Obsidian.
сваливая картинки в корень
Есть такое. Как и прочие блобы это всё хочется хранить где-то отдельно.
Я тут нагуглил определение и оно расходиться с Вашим
Приводить результаты гугления пришлось, поскольку вы не дали никакого определения, принятого хотя бы в вашем коллективе.
> Организовать службу (в терминах ITSM) и воплотить (S/D)aaS - это вообще про разное.
Всё верно, тут и не утверждается обратного.
Вынужден повториться: у вас заголовок про некий DaaS, а статья про организацию службы (в терминах ITSM), в связи с чем и возник комментарий с вопросами.
2 принцип. ПодразделениеDevOpsпредставляет из себя сервисную службу.
Это - про ITSM.
4 принцип - Контроль за качеством (MTTD,MTTR, MTTF).
Это - просто DevOps. DORA и DevOps Radar не вводят никаких видов DevOps. Это сам DevOps и есть.
Вы из бардака с постановкой задач делаете просто нормальное подразделение с нормальным управлением, которое занимается решением DevOps задач. Для этого не нужно придумывать новых терминов и вводящих в заблуждение аббревиатур.
Прочитал в заголовке "DevOps as a Service" и пришел почитать именно об этом. О том как любые желающие команды, у которых еще нет никакого DevOps, захотели себе внедрить типовые пайплайны и метрики, куда-то зашли, что-то нажали и у них раскатался из образа контур CI, что-то для CD, какой-то номинальный мониторинг. А прочитал про то, как навести порядок в отделе, где не было никакой управляемости.
Организовать службу (в терминах ITSM) и воплотить (S/D)aaS - это вообще про разное.
Исследование на тему "может это я тупой" по-быстрому нагуглило такое определение
DaaS - "devops as a service" - это такой преднастроенный (но конфигурируемый если надо) набор компонентов, позволяющих быстро организовать "devops".
Да! Это не про подъем с 1го на 2й/3й уровень CMMI. Это про
Программное обеспечение как услуга (software as a service, SaaS) — это облачная модель предоставления ПО, при которой поставщик услуг разрабатывает облачное ПО, обеспечивает его обслуживание, автоматическое обновление и доступность и предоставляет такое ПО заказчикам через Интернет за оплату, пропорциональную объемам использования. src
только про пайплайны туда и обратно.
2018 in review: State of DevOps adoption
Не нашел там никаких "DaaS", "as a service", нашел те же буквы и рассуждения, что есть в "Accelerate" про "High performers vs Low performers". Про то что DevOps помогает. Про DevOps в целом.
Со второй ссылкой
“DevOps as a Service or Do You Really Need a DevOps Team”
Лично мне еще более не понятно, что там происходит и возможно у меня действительно какие-то сложности с буквами:
DaaS is a delivery model that in its core implies to store all the development tools in the cloud platform to make certain that developers use a common toolset and all of the actions are tracked.
Отсюда можно вырулить на "развертывание по требованию", но я не очень понимаю, чего именно. "Development tools in the cloud platform" - рабочие места в облаке, RDP и только те devtools, которые там установлены? Допускаю, но это даже не DevOps, не то что следующий уровень.
With DaaS, you get a dedicated DevOps team that provides developers with documentation and mentorship for helping your in-house IT department to learn new tools and systems.
By using cloud services, everything becomes more data-driven so the team uses the same dataset. This service provides better documentation and quality control.
Автор той статьи, видимо, рассуждает о том, как уйти от вашей локальной толпы велосипедов с толпой же штатных DevOps-инженеров к CI/CD решениям, работающим в облаках (а-ля Azure DevOps). Т.е., пользуясь предложенной терминологией, воспользоваться чьим-то DaaS, а не реализовать какой-то свой.
В вашей статье никаких рассуждений об автоматизации развертывания DevOps-пайплайнов не вижу, только наведение порядка в управлении службой DevOps в терминах ITSM, установление правил и границ.
Если материал про некий DaaS все-таки есть, то было бы здорово увидеть это в статье, в противном случае, возможно стоит скорректировать заголовок и неуместные упоминания "as a service" устранить, оставить только упоминания самого DevOps, которым занимается ваше подразделение.
Есть подход "Clean as you code", который реализован в SonarQube и которого их команда рекомендует придерживаться в целом - он как раз об этом. Чтобы внедрение статического анализа не было равносильно срыву стоп-крана. Код будет анализироваться весь, но ругаться и блокировать PR он будет только на новом коде (фрагменте кода). Так не возникнет необходимости сразу переписывать все, однако неудовлетворяющий требованиям новый код протащить не удастся.
На коленке примерно такое реализовать тоже возможно: при сборке на стороне CI вычисляете дифф между source и target ветками, так понимаете, где были изменения и линтите только это. OP на этот вариант также сослалась.
Линтеры линтят не только пробелы с запятыми, потому в старье найдется скорее всего много чего интересного, это уже можно без паники спокойно закинуть в бэклог как существенный техдолг и также спокойно потом включить в какой-то спринт.
Когда требуется отдать задачу в ревью, инженер двигает ее
вот здесь
задача по code review ставится в Jira
формулировка, похожая на создание новой задачи "делать ревью вон той задачи". Если существующая задача просто двигается в другой статус, то вопросов нет.
Статья понравилась, много здравых рассуждений, но включиться в дискуссию сложновато, поскольку материал обо всем и сразу.
Если хватит сил и желания, то мне, к примеру, было бы интересно узнать детали выстраивания процесса не на уровне идеи, а в нюансах воплощения. Как подружить слова Git, Pull-Request, SonarQube, Quality Gate и обеспечить контроль за исходниками - это понятно, это история распространенная. А вот как подружить слова аналитик, Acceptance Test в постановке, Gherkin, Acceptance Test Review и Quality Gate - это уже нераспространенная история, если у вас существует решение не на уровне должностной инструкции, а такое, которое физически не пустит в работу задачу без определения сценария приемочного теста, если этот тест не прошел ревью, если всё, что связано с постановкой не преодолело связанный с этим Quality Gate, в котором установлены некие конкретные критерии, то про это решение было бы очень интересно узнать. У нас, как-то так получается, что любые заходы к аналитикам заканчиваются на уровне "а, так это че-т делать надо, в чем-то разбираться? не, идея классная, но у нас сейчас другое совещание начнется, давайте завтра. Или лучше знаете что, лучше никогда!"
Благодаря такой прогнозируемости эволюционный подход позволяет четко следовать методологии Канбан и практически неотделим от нее... Например, с помощью таск-трекеров, таких как Kaiten
на практике визуальные составляющие кода отлавливаются и исправляются именно на code review
Это не самый удачный вариант, нужно сдвигать контроль оформления влево. Для большинства популярных языков есть и линтеры, и форматтеры, настройки (соглашения) как правило легко шарятся в виде закоммиченного в папку проекта файла. Разработчику нужно выдать экстеншн или инсталлятор того же инструмента, контроль переложить на CI, который бы не пропускал несоответствия.
задача по code review ставится в Jira
Бывает и такое, что обеденный перерыв ставят и в JIRA, и в календарь Outlook. Но до этого должен был случиться неслабый такой поворот не туда. Если это что-то решает, то почему бы и нет, но пахнет, как говорится, не очень хорошо.
Метод единоличной ответственности инженера
Такое есть, в рассуждениях про QualityGate как правило рассматривается как один из интипаттернов. Назначенный крайним быстро превратится в хранителя единственно правильного мнения и хорошо от этой ситуации не будет никому.
В парном программировании теряем эффективность
Суть рассуждений понятна, но формулировки кажутся не самыми удачными. Есть задачи, над которыми вдвоем сидеть странно и неуместно. Есть задачи, решение которых (далее вольно цитирую вас же) при парном подходе происходит быстрее, решение оказывается лучше, надежнее, эффективнее. И в рассуждениях, видимо, про финансовые затраты имеет смысл учитывать, что один бы делал дольше, сделал бы хуже, на ревью все равно бы двое тратили время, причем второй вникал бы с нуля, потом бы с ненулевой вероятностью все они повторили упражнение, т.к. рефактор и переосмысление непременно случились бы. Рассуждения об эффективности уместны в любом случае, но однозначный вывод возможен только если удастся куда-нибудь какую-нибудь линейку приложить и фактически увидеть, что где-то чего-то больше, а в другой ситуации - меньше.
За счет code review адаптация происходит быстрее
Не смог разгадать этот паззл. Толкать на прод не глядя от только что пришедшего в коллектив сотрудника и никак его не онбордить - это предполагается как альтернатива? Возможно просто не совсем точно сформулировано, но пахнет странным. Как если бы в нового сотрудника молча кидались задачами и только на ревью сообщали "неправильно сделал". Адаптация - она же сама по себе должна существовать, как процесс, тот самый "онбординг". Там же и про местные подходы, архитектуру, инструментарий тоже. А ревью как был самим собой и играл какую-то роль во взаимодействии с остальными разработчиками, тем же элементом процесса и для того же и остался.
В девопс методологию прийти довольно сложно, потому что это не "методология". Пардон за занудство, но если рассказывать про управление разработкой, то желательно термины не путать. Где-то рядом мелькала статья, в которой в очередной раз предлагалось выбрать между методологиями Lean, Agile, Waterfall, так что болевые ощущения возникли мгновенно.
Практики DevOps говорят об устранении согласований в смысле передачи ответственности от Change Approval Board (нечастых заседаний по одобрению возможных изменений с участниками, которые вообще не про разработку) самим командам, но под командами в общем случае имеют ввиду Empowered Team, где уже есть в составе продакт и/или проджект, есть бэклог и приоритезация, есть ревью и тестирование. То есть передача ответственности за одобрение изменения ближе к делу, ближе к контексту и повышение оперативности принятия этих решений.
За TTM рассуждать в районе дискуссии про то, пишем ли мы тесты и делаем ли ревью, дело тоже не особо благодарное, т.к. TTM сильно шире времени исполнения откуда-то взявшейся задачки. LeadTime сократить можно, но поставлять на прод невероятно быстро вместо хот-фиксов хот-баги - это про странные соревнования, победителя которых потом могут и ногами побить. Вместо тестов и ревью говорить, - "да я точно знаю!" - такое себе. Не знает, узнает только на проде.
Что везде нужен разумный подход - да, тут сложно не согласиться.
Клепаете MVP или говноутилиту местного значения на выброс в отдельном репозитории-помойке - фигачьте себе прямо в master, на ходу додумывая концепцию решения. Развиваете энтерпрайз-легаси-монстра - вы через неделю уже понять, что происходит не сможете при таком подходе. Вон, в соседней статье рассуждают про то, как по-крутому можно три месяца искать в легаси-проекте одну строчку, в которой ошибка и этим сломать все дурацкие KPI про коммиты (которые никто в качестве KPI принимать, к слову, не предлагал), продемонстрировав, тем не менее, невероятную эффективность и полезность. Что в итоге смог разобраться - молодец. Три месяца было потрачено, потому что когда-то давно вместо тестов, документации и ревью разрабы рассуждали про то, о чем не спрашивали, и выдали якобы невероятный "тайм-то-маркет" (который, очевидно, мерять и сравнивать никто даже не пытался). А потом штука под названием технический долг настигла их наследников и "тайм-ту-маркет" внезапно стал чудовищным.
Является ли эффективной такая организация разработки, при которой у нас сначала все происходит невероятно быстро, а потом все медленнее и медленнее? Рассуждения о достижении эффективности обычно именно такую ситуацию, такие подходы используют как точку отсчета, как призказку в духе "в стародавние времена все думали, что клепать как попало это очень здорово", чтобы потом через пугающий график роста стоимости внесения изменений рассмотреть наборы практик, которые позволяют прийти к другой ситуации, когда стоимость внесения изменений экспоненциально не растет. Но там честно показывается, что начало в таких подходах медленнее, чем в тяп-ляп и в продакшен. Зато потом нет никакой загнанной лошади, которую проще пристрелить.
В целом, общая мысль статьи - про разумное, но некоторые формулировки кажутся не самыми удачными.
тесты на функциональность, которая меняться никогда не будет
Так для того и пишут тест, чтобы он свалился, если вдруг поведение почему-то изменилось, хотя не должно.
до стилистических мелочей и вкусовщины
Лучше докопаться как можно раньше и выработать принципы, код-стайл. Внедрить форматтер и линтер, статический анализ кода. Иначе потом в это месиво никто добровольно лезть не захочет.
не тратить времени на планирование, если нет дедлайна
А цели есть? Приоритеты? Если имелось ввиду календарное планирование, то понять можно, если планирование в целом, то больше похоже на цитату из сборника с вредными советами. Так не добраться из пункта А в пункт Б, если не брать в руки карту и не прокладывать маршрут, не подгонять отстающих и не возвращать уклонившихся от курса.
Автор в личке ответил, что он скорее имел ввиду особенности Symphony (с которыми я не знаком) и что для описанного случая ORM генерит именно такие модели и именно такие запросы. Но формулировки получились слишком обобщающие, потому и возникают вопросы и к толпе джойнов и в целом к решению. Статья скорее про Symphony, чем про Postgresql и М2М.
А так - да, задачка уровня sqlacademy про поиск записей, у которых есть все теги. Возможно дистинкта не хватает, т.к. там уникальности по тегу на операцию вроде не навешано.
Экстеншен к студии - это для локальной работы, для CI сделан CLI-инструмент, он же доступен желающим для использования в качестве External Tools в VS неподдерживаемой версии или в SSMS, SourceTree. CLI сделать проще, чем Extension, с него и начинали. За основу брали OpenSource проект tsqllint и двигались от плагина для него к полностью своему решению с ~300 правилами. В упомянутом проекте, к слову, можно найти хорошие примеры работы со ScriptDom.
С нугетами работать было бы здорово, если бы инструкция к тому, как заставить это работать хотя быв некоторых случаях не занимала целый экран. Новый Microsoft.Build.Sql SDK находится в зачаточном состоянии, пакет носит статус Preview и нормальная поддержка нугетов все еще где-то в далекой (судя по невысокой активности разработчиков) перспективе. Системные БД они действительно как нугеты опубликовали, но воспользоваться ими смогут только те, у кого COLLATION во всех зависимых проектах - English. Для всех остальных эти нугеты бесполезны, дакпаками из них воспользоваться не получится.
Возвращаюсь к решению по обеспечению контроля за кодом. На стороне CI сделать можно по-всякому и там интеграция с VS или другой IDE, очевидно, не нужна, контроль за тем, что анализ будет выполнен, не нужен - все шаги прописаны явно. А на стороне разработчика у нас все равно толком ничего не работает, т.к. пока он явно из CLI не повыполняет все инструкции, цель достигнута не будет (согласен с тем, что и экстешен он должен ставить сам, сам им пользоваться, но я как раз и обращаю внимание на то, что нет никакой разницы в том, чтобы подстраиваться под замороченные условности аналайзера или разрабатывать в относительно свободном стиле, не привязываться к чему-то полуживому). Кроме того, из-за низкого уровня проработанности SDK/SSDT, как описано выше, в абсолютно все sqlproj придется внести пачку изменений, которые могут там появиться только при ручном редактировании sqlproj-файла или при генерации проекта через boilerplate-утилиту, но в любом случае работать с этим очень неудобно. Далее, если продолжать рассуждать о контроле за кодом, то результат анализа мы отправляем в SonarQube, которому нужен особый json-формат. MSBuild, очевидно, умеет только в текстовый лог, что снова не добавляет удобства, путь через подстраивание под предлагаемый механизм анализаторов ничем не помогает в достижении конечной цели.
И стоит ли оно того в итоге? Аналайзер, оформленный по всем правилам SSDT интересен именно как путь высокой интегрированности с процессом разработки и сборки, а эта цель не достигается даже танцами с бубном. Еще Microsoft.SqlServer.Dac.CodeAnalysis дает доступ ко всей модели проекта в объектном виде, можно (предполагаю, т.к. сюда не добрался в экспериментах) бродить по зависимостям, что очень здорово, но всё вышеперечисленное отбивает всякое желание прорубаться через эти джунгли. В очередной раз потрачу время на заход через Microsoft.SqlServer.Dac.CodeAnalysis я уж точно не раньше, чем будет доведен до продуктового состояния Microsoft.Build.Sql. И совсем будет здорово, если там однажды появятся аналоги CodeFix.
Рассказ про Clickhouse и его возможности мог бы быть интересен, как и сравнение разных реализаций одного и того же в разных СУБД. Но к выводу нас подвели через несколько ложных утверждений, что не добавляет баллов статье.
EAV не тождественно равен нормализации, применен явно не самым удачным образом. Через восемь джойнов фильтр по восьми тегам делать вовсе не нужно (распростаренная задачка на базовые возможности SQL), в самом по-себе M2M никаких заложенных природой проблем нет. Аналоги предложенного решения, как уже упомянули, есть в самом Postgres. Планы выполнения и прочие факты при анализе производительности как раз имеют первоочередное значение, а сравнение 1.5 сек с 0.3 сек при очевидно неодинаковых условиях это как раз вообще не интересно.
Почему-то мы сразу были убеждены, что упёрлись в производительность самого Postgres
при many-to-many превратились бы в смертельные джойны
То, о чем вы пишете, называется ScriptDom и оно входит в поставку DacFx, но самим DacFx не является. Более того, недавно парсер выделен в самостоятельный нугет и теперь его в решения по анализу кода TSQL можно без всех остальных составляющих пакета DacFx затягивать. Объектная модель описана довольно хорошо, вот корректная ссылка на доки.
ScriptDom сам построен на ANTLR, потому противопоставлять их не совсем корректно, хоть мысль и понятна.
SqlCodeAnalysusRule мы не используем, запилили свой линтер "сбоку" в виде экстеншена к студии. В SSDT крайне неудачно реализована работа с code-analyzer'ами, по сравнению с Roselyn тут всё находится на чудовищно допотопном уровне. В частности, согласно официальным докам, скомпилированный аналайзер нужно подсовывать в правильное место в Program Files, что в корпоративном мире (без админских прав на компе) не всегда возможно в принципе. Если для кого актуально, я заводил фича-реквест для разрабатываемого нового SDK/SSDT/не важно куда они это смогут вкорячить, чтобы сделали поддержку аналайзеров как нугетов безо всяких магических путей в Program Files - накиньте лайков.
Спасибо, смысл слов понятен, характер описываемого решения понятен.
Так я про решение этой задачи в вашем конкретном решении по "отдавать версию под каждую фичу" из статьи спрашиваю, зачем мне ссылки на курсы. "Мы оставили это за скобками и БД решением не покрыты" - простая и понятная фраза, хоть и не объясняет как же каждая отдельная фича самостоятельно может существовать, если в реализации фичи задействованы БД.
С базами данных как порешали?
Тэги в Obsidian как раз иерархичны, иерархия понимается через слэш:
#my/best/tagбудет найден в т.ч. при фильтрации по
#my,#my/bestТак оно всё про семантику, не про каталог. При этом _явная группировка_ карточек складыванием в папку доступна. А развесистое дерево папочек в общем и целом противоречит идеологии и Цеттелькастена, и Obsidian.
Есть такое. Как и прочие блобы это всё хочется хранить где-то отдельно.
Приводить результаты гугления пришлось, поскольку вы не дали никакого определения, принятого хотя бы в вашем коллективе.
Вынужден повториться: у вас заголовок про некий DaaS, а статья про организацию службы (в терминах ITSM), в связи с чем и возник комментарий с вопросами.
Это - про ITSM.
Это - просто DevOps. DORA и DevOps Radar не вводят никаких видов DevOps. Это сам DevOps и есть.
Вы из бардака с постановкой задач делаете просто нормальное подразделение с нормальным управлением, которое занимается решением DevOps задач. Для этого не нужно придумывать новых терминов и вводящих в заблуждение аббревиатур.
Прочитал в заголовке "DevOps as a Service" и пришел почитать именно об этом. О том как любые желающие команды, у которых еще нет никакого DevOps, захотели себе внедрить типовые пайплайны и метрики, куда-то зашли, что-то нажали и у них раскатался из образа контур CI, что-то для CD, какой-то номинальный мониторинг. А прочитал про то, как навести порядок в отделе, где не было никакой управляемости.
Организовать службу (в терминах ITSM) и воплотить (S/D)aaS - это вообще про разное.
Исследование на тему "может это я тупой" по-быстрому нагуглило такое определение
Да! Это не про подъем с 1го на 2й/3й уровень CMMI. Это про
только про пайплайны туда и обратно.
Не нашел там никаких "DaaS", "as a service", нашел те же буквы и рассуждения, что есть в "Accelerate" про "High performers vs Low performers". Про то что DevOps помогает. Про DevOps в целом.
Со второй ссылкой
Лично мне еще более не понятно, что там происходит и возможно у меня действительно какие-то сложности с буквами:
Отсюда можно вырулить на "развертывание по требованию", но я не очень понимаю, чего именно. "Development tools in the cloud platform" - рабочие места в облаке, RDP и только те devtools, которые там установлены? Допускаю, но это даже не DevOps, не то что следующий уровень.
Автор той статьи, видимо, рассуждает о том, как уйти от вашей локальной толпы велосипедов с толпой же штатных DevOps-инженеров к CI/CD решениям, работающим в облаках (а-ля Azure DevOps). Т.е., пользуясь предложенной терминологией, воспользоваться чьим-то DaaS, а не реализовать какой-то свой.
В вашей статье никаких рассуждений об автоматизации развертывания DevOps-пайплайнов не вижу, только наведение порядка в управлении службой DevOps в терминах ITSM, установление правил и границ.
Если материал про некий DaaS все-таки есть, то было бы здорово увидеть это в статье, в противном случае, возможно стоит скорректировать заголовок и неуместные упоминания "as a service" устранить, оставить только упоминания самого DevOps, которым занимается ваше подразделение.
Есть подход "Clean as you code", который реализован в SonarQube и которого их команда рекомендует придерживаться в целом - он как раз об этом. Чтобы внедрение статического анализа не было равносильно срыву стоп-крана. Код будет анализироваться весь, но ругаться и блокировать PR он будет только на новом коде (фрагменте кода). Так не возникнет необходимости сразу переписывать все, однако неудовлетворяющий требованиям новый код протащить не удастся.
На коленке примерно такое реализовать тоже возможно: при сборке на стороне CI вычисляете дифф между source и target ветками, так понимаете, где были изменения и линтите только это. OP на этот вариант также сослалась.
Линтеры линтят не только пробелы с запятыми, потому в старье найдется скорее всего много чего интересного, это уже можно без паники спокойно закинуть в бэклог как существенный техдолг и также спокойно потом включить в какой-то спринт.
сбер (нет пруфлинка) -> 3d news (нет пруфлинка) -> the verge (нет пруфлинка) -> блог CEO SO (нет упоминаний исследования)
В оригинале на the verge есть упоминание без ссылки "Annual survey".
Вот ссылка на исследование, раздел про AI: https://survey.stackoverflow.co/2023/#ai
Вот статистика:
вот здесь
формулировка, похожая на создание новой задачи "делать ревью вон той задачи". Если существующая задача просто двигается в другой статус, то вопросов нет.
Статья понравилась, много здравых рассуждений, но включиться в дискуссию сложновато, поскольку материал обо всем и сразу.
Если хватит сил и желания, то мне, к примеру, было бы интересно узнать детали выстраивания процесса не на уровне идеи, а в нюансах воплощения. Как подружить слова Git, Pull-Request, SonarQube, Quality Gate и обеспечить контроль за исходниками - это понятно, это история распространенная. А вот как подружить слова аналитик, Acceptance Test в постановке, Gherkin, Acceptance Test Review и Quality Gate - это уже нераспространенная история, если у вас существует решение не на уровне должностной инструкции, а такое, которое физически не пустит в работу задачу без определения сценария приемочного теста, если этот тест не прошел ревью, если всё, что связано с постановкой не преодолело связанный с этим Quality Gate, в котором установлены некие конкретные критерии, то про это решение было бы очень интересно узнать. У нас, как-то так получается, что любые заходы к аналитикам заканчиваются на уровне "а, так это че-т делать надо, в чем-то разбираться? не, идея классная, но у нас сейчас другое совещание начнется, давайте завтра. Или лучше знаете что, лучше никогда!"
Что ж вы так бедную логику об колено ломаете.
старая шутка
— Поцелуйте меня в затылок
— Зачем?
— Ну, вы тоже издалека начали
Это не самый удачный вариант, нужно сдвигать контроль оформления влево. Для большинства популярных языков есть и линтеры, и форматтеры, настройки (соглашения) как правило легко шарятся в виде закоммиченного в папку проекта файла. Разработчику нужно выдать экстеншн или инсталлятор того же инструмента, контроль переложить на CI, который бы не пропускал несоответствия.
Бывает и такое, что обеденный перерыв ставят и в JIRA, и в календарь Outlook. Но до этого должен был случиться неслабый такой поворот не туда. Если это что-то решает, то почему бы и нет, но пахнет, как говорится, не очень хорошо.
Такое есть, в рассуждениях про QualityGate как правило рассматривается как один из интипаттернов. Назначенный крайним быстро превратится в хранителя единственно правильного мнения и хорошо от этой ситуации не будет никому.
Суть рассуждений понятна, но формулировки кажутся не самыми удачными. Есть задачи, над которыми вдвоем сидеть странно и неуместно. Есть задачи, решение которых (далее вольно цитирую вас же) при парном подходе происходит быстрее, решение оказывается лучше, надежнее, эффективнее. И в рассуждениях, видимо, про финансовые затраты имеет смысл учитывать, что один бы делал дольше, сделал бы хуже, на ревью все равно бы двое тратили время, причем второй вникал бы с нуля, потом бы с ненулевой вероятностью все они повторили упражнение, т.к. рефактор и переосмысление непременно случились бы. Рассуждения об эффективности уместны в любом случае, но однозначный вывод возможен только если удастся куда-нибудь какую-нибудь линейку приложить и фактически увидеть, что где-то чего-то больше, а в другой ситуации - меньше.
Не смог разгадать этот паззл. Толкать на прод не глядя от только что пришедшего в коллектив сотрудника и никак его не онбордить - это предполагается как альтернатива? Возможно просто не совсем точно сформулировано, но пахнет странным. Как если бы в нового сотрудника молча кидались задачами и только на ревью сообщали "неправильно сделал". Адаптация - она же сама по себе должна существовать, как процесс, тот самый "онбординг". Там же и про местные подходы, архитектуру, инструментарий тоже. А ревью как был самим собой и играл какую-то роль во взаимодействии с остальными разработчиками, тем же элементом процесса и для того же и остался.
В девопс методологию прийти довольно сложно, потому что это не "методология". Пардон за занудство, но если рассказывать про управление разработкой, то желательно термины не путать. Где-то рядом мелькала статья, в которой в очередной раз предлагалось выбрать между методологиями Lean, Agile, Waterfall, так что болевые ощущения возникли мгновенно.
Практики DevOps говорят об устранении согласований в смысле передачи ответственности от Change Approval Board (нечастых заседаний по одобрению возможных изменений с участниками, которые вообще не про разработку) самим командам, но под командами в общем случае имеют ввиду Empowered Team, где уже есть в составе продакт и/или проджект, есть бэклог и приоритезация, есть ревью и тестирование. То есть передача ответственности за одобрение изменения ближе к делу, ближе к контексту и повышение оперативности принятия этих решений.
За TTM рассуждать в районе дискуссии про то, пишем ли мы тесты и делаем ли ревью, дело тоже не особо благодарное, т.к. TTM сильно шире времени исполнения откуда-то взявшейся задачки. LeadTime сократить можно, но поставлять на прод невероятно быстро вместо хот-фиксов хот-баги - это про странные соревнования, победителя которых потом могут и ногами побить. Вместо тестов и ревью говорить, - "да я точно знаю!" - такое себе. Не знает, узнает только на проде.
Что везде нужен разумный подход - да, тут сложно не согласиться.
Клепаете MVP или говноутилиту местного значения на выброс в отдельном репозитории-помойке - фигачьте себе прямо в master, на ходу додумывая концепцию решения. Развиваете энтерпрайз-легаси-монстра - вы через неделю уже понять, что происходит не сможете при таком подходе. Вон, в соседней статье рассуждают про то, как по-крутому можно три месяца искать в легаси-проекте одну строчку, в которой ошибка и этим сломать все дурацкие KPI про коммиты (которые никто в качестве KPI принимать, к слову, не предлагал), продемонстрировав, тем не менее, невероятную эффективность и полезность. Что в итоге смог разобраться - молодец. Три месяца было потрачено, потому что когда-то давно вместо тестов, документации и ревью разрабы рассуждали про то, о чем не спрашивали, и выдали якобы невероятный "тайм-то-маркет" (который, очевидно, мерять и сравнивать никто даже не пытался). А потом штука под названием технический долг настигла их наследников и "тайм-ту-маркет" внезапно стал чудовищным.
Является ли эффективной такая организация разработки, при которой у нас сначала все происходит невероятно быстро, а потом все медленнее и медленнее? Рассуждения о достижении эффективности обычно именно такую ситуацию, такие подходы используют как точку отсчета, как призказку в духе "в стародавние времена все думали, что клепать как попало это очень здорово", чтобы потом через пугающий график роста стоимости внесения изменений рассмотреть наборы практик, которые позволяют прийти к другой ситуации, когда стоимость внесения изменений экспоненциально не растет. Но там честно показывается, что начало в таких подходах медленнее, чем в тяп-ляп и в продакшен. Зато потом нет никакой загнанной лошади, которую проще пристрелить.
В целом, общая мысль статьи - про разумное, но некоторые формулировки кажутся не самыми удачными.
Так для того и пишут тест, чтобы он свалился, если вдруг поведение почему-то изменилось, хотя не должно.
Лучше докопаться как можно раньше и выработать принципы, код-стайл. Внедрить форматтер и линтер, статический анализ кода. Иначе потом в это месиво никто добровольно лезть не захочет.
А цели есть? Приоритеты? Если имелось ввиду календарное планирование, то понять можно, если планирование в целом, то больше похоже на цитату из сборника с вредными советами. Так не добраться из пункта А в пункт Б, если не брать в руки карту и не прокладывать маршрут, не подгонять отстающих и не возвращать уклонившихся от курса.
Автор в личке ответил, что он скорее имел ввиду особенности Symphony (с которыми я не знаком) и что для описанного случая ORM генерит именно такие модели и именно такие запросы. Но формулировки получились слишком обобщающие, потому и возникают вопросы и к толпе джойнов и в целом к решению. Статья скорее про Symphony, чем про Postgresql и М2М.
А так - да, задачка уровня sqlacademy про поиск записей, у которых есть все теги. Возможно дистинкта не хватает, т.к. там уникальности по тегу на операцию вроде не навешано.
Экстеншен к студии - это для локальной работы, для CI сделан CLI-инструмент, он же доступен желающим для использования в качестве External Tools в VS неподдерживаемой версии или в SSMS, SourceTree. CLI сделать проще, чем Extension, с него и начинали. За основу брали OpenSource проект tsqllint и двигались от плагина для него к полностью своему решению с ~300 правилами. В упомянутом проекте, к слову, можно найти хорошие примеры работы со ScriptDom.
С нугетами работать было бы здорово, если бы инструкция к тому, как заставить это работать хотя бы в некоторых случаях не занимала целый экран. Новый Microsoft.Build.Sql SDK находится в зачаточном состоянии, пакет носит статус Preview и нормальная поддержка нугетов все еще где-то в далекой (судя по невысокой активности разработчиков) перспективе. Системные БД они действительно как нугеты опубликовали, но воспользоваться ими смогут только те, у кого COLLATION во всех зависимых проектах - English. Для всех остальных эти нугеты бесполезны, дакпаками из них воспользоваться не получится.
Возвращаюсь к решению по обеспечению контроля за кодом. На стороне CI сделать можно по-всякому и там интеграция с VS или другой IDE, очевидно, не нужна, контроль за тем, что анализ будет выполнен, не нужен - все шаги прописаны явно. А на стороне разработчика у нас все равно толком ничего не работает, т.к. пока он явно из CLI не повыполняет все инструкции, цель достигнута не будет (согласен с тем, что и экстешен он должен ставить сам, сам им пользоваться, но я как раз и обращаю внимание на то, что нет никакой разницы в том, чтобы подстраиваться под замороченные условности аналайзера или разрабатывать в относительно свободном стиле, не привязываться к чему-то полуживому). Кроме того, из-за низкого уровня проработанности SDK/SSDT, как описано выше, в абсолютно все sqlproj придется внести пачку изменений, которые могут там появиться только при ручном редактировании sqlproj-файла или при генерации проекта через boilerplate-утилиту, но в любом случае работать с этим очень неудобно. Далее, если продолжать рассуждать о контроле за кодом, то результат анализа мы отправляем в SonarQube, которому нужен особый json-формат. MSBuild, очевидно, умеет только в текстовый лог, что снова не добавляет удобства, путь через подстраивание под предлагаемый механизм анализаторов ничем не помогает в достижении конечной цели.
И стоит ли оно того в итоге? Аналайзер, оформленный по всем правилам SSDT интересен именно как путь высокой интегрированности с процессом разработки и сборки, а эта цель не достигается даже танцами с бубном. Еще Microsoft.SqlServer.Dac.CodeAnalysis дает доступ ко всей модели проекта в объектном виде, можно (предполагаю, т.к. сюда не добрался в экспериментах) бродить по зависимостям, что очень здорово, но всё вышеперечисленное отбивает всякое желание прорубаться через эти джунгли. В очередной раз потрачу время на заход через Microsoft.SqlServer.Dac.CodeAnalysis я уж точно не раньше, чем будет доведен до продуктового состояния Microsoft.Build.Sql. И совсем будет здорово, если там однажды появятся аналоги CodeFix.
Рассказ про Clickhouse и его возможности мог бы быть интересен, как и сравнение разных реализаций одного и того же в разных СУБД. Но к выводу нас подвели через несколько ложных утверждений, что не добавляет баллов статье.
EAV не тождественно равен нормализации, применен явно не самым удачным образом. Через восемь джойнов фильтр по восьми тегам делать вовсе не нужно (распростаренная задачка на базовые возможности SQL), в самом по-себе M2M никаких заложенных природой проблем нет. Аналоги предложенного решения, как уже упомянули, есть в самом Postgres. Планы выполнения и прочие факты при анализе производительности как раз имеют первоочередное значение, а сравнение 1.5 сек с 0.3 сек при очевидно неодинаковых условиях это как раз вообще не интересно.
Это довольно смелые утверждения.
То, о чем вы пишете, называется ScriptDom и оно входит в поставку DacFx, но самим DacFx не является. Более того, недавно парсер выделен в самостоятельный нугет и теперь его в решения по анализу кода TSQL можно без всех остальных составляющих пакета DacFx затягивать. Объектная модель описана довольно хорошо, вот корректная ссылка на доки.
ScriptDom сам построен на ANTLR, потому противопоставлять их не совсем корректно, хоть мысль и понятна.
SqlCodeAnalysusRule мы не используем, запилили свой линтер "сбоку" в виде экстеншена к студии. В SSDT крайне неудачно реализована работа с code-analyzer'ами, по сравнению с Roselyn тут всё находится на чудовищно допотопном уровне. В частности, согласно официальным докам, скомпилированный аналайзер нужно подсовывать в правильное место в Program Files, что в корпоративном мире (без админских прав на компе) не всегда возможно в принципе. Если для кого актуально, я заводил фича-реквест для разрабатываемого нового SDK/SSDT/не важно куда они это смогут вкорячить, чтобы сделали поддержку аналайзеров как нугетов безо всяких магических путей в Program Files - накиньте лайков.