Тут два основных подхода: мы выбираем или самые затратные по времени ручные тесты, или самые сложные сценарии для подготовки среды, пользователей и т. д.
Выбрав самые сложные, можно потратить много времени и ничего хорошего не получить. Например, автоматизация отчетов: много допбиблиотек, неустойчивы из-за зависимости от данных, да и нужно придумывать, как парсить пдф или перелавливать результат до формирования файла. А функционал не основной. Любой ручник потратит не более получаса. Невыгодно.
Двойную работу не нравится делать никому. Это факт. Но тесты по НФ лучше включить в регресс, т.к. коммит с исправлением по нему или вообще часть НФ могут забыть добавить в релиз. Можно проверять НФ и в середине спринта, а потом его сломают при починке бага где-то еще.
С последним абзацем согласны. Но опять же, если баг не выше третьего и до выпуска продукта осталось меньше дня ?
Замечание справедливо, если не успевать тестировать НФ до регресса. Обычно оно у нас все-таки протестировано и описано в новых тестах до начала выпуска нового регресса. Поэтому и используем такое деление. Часть новых тестов потом войдет в ядро регресса, а остальные отправятся в архив до момента, когда в работе будет задета данная функциональность. В каком порядке проводить — это уже дело вкуса. Главное, чтобы все выбранные тесты были пройдены.
Редко дадут время на повторное прохождение всего цикла регресса, особенно если в проекте нет автоматизации. Поэтому максимум — проверка бага, перепрохождение теста, давшего ошибку, и то, редко дадут время на повторное прохождение всего цикла регресса, особенно если в проекте нет автоматизации. Поэтому максимум — проверка бага, перепрохождение теста, давшего ошибку, и то, что тестировщик успевает проверить. Это ближе к реальности.
Пожеланием заказчика было использовать встроенный инструментарий ClickHouse. Утилита clickhouse-backup, хотя и использует родные команды базы, является сторонним инструментом, что с ним будет через год — неизвестно.
В вашем случае нужно сделать две фильтрации. Сначала отобрать нужную партицию, после чего отфильтровать по id. Чтобы четко выбрать партицию, сделаем предфильтрацию. Если правильно вас поняли — партицией у вас является кортеж из полей a и b, поэтому будет использоваться виртуальный столбец _partition_value в секции prewhere.
PREWHERE _partition_value IN (select (a, b) from dic where name = :name_value)
Далее отфильтруем по id.
WHERE id IN (select id from dic where name = :name_value)
По второму вопросу. Руками в нашем случае было значительно дольше, т.к. на старте проекта имелось несколько томов требований.
Что касается следующего подпункта второго вопроса — проект от перевода задач в Jira, разумеется, методологию не поменял. Однако удалось сохранить привычный темп работы команды, которая была привлечена к данному проекту, что в свою очередь, позволило решить другую задачу. Речь о пристальном внимании руководства, о котором упоминалось в начале статьи. Оно выражалось в периодической внутренней демонстрации, иногда даже в присутствии сотрудников заказчика.
Согласны, что существует порог востребованности аналитика. В небольших компаниях с продуктовой разработкой задачи аналитика действительно могут делиться между участниками. Но рано или поздно все приходят к аналитике. Иногда не напрямую, а через потребность в документировании решений или более обоснованном планировании развития продукта, что необходимо инвесторам. Другой вариант — отсутствие времени у команды и множество задач по основному профилю.
Пользователи Хабра искали вакансии системных аналитиков за рубежом https://habr.com/ru/post/655433/. На наш взгляд, получили объективные результаты в целом.
Многое зависит от железа, скорости сетевого канала, типов данных, распределения этих данных между таблицами и т.д. А пример мы привели для понимания контраста: скорость миграции одной из БД удалось сократить с 24 часов до 10 часов за счёт только этих параметров.
Конфигурация, которая описана в статье, была «отправной точкой». У нас несколько кластеров (leader-replica-replica), они работают на виртуалках 16-32 CPU, 32-128 GB RAM. Все на SSD-дисках. Далее конфигурации корректировали по результатам НТ.
У нас была только одна процедура очистки архивных данных, которую мы легко переписали. Других процедур в БД не было. На других проектах тоже занимались переносом процедур, может быть, опишем в следующих статьях:)
Большее количество ботов, которые мы сделали, когда пользовались Slack, работают по принципу «От Slack нам нужен только hook для отправки уведомления», поэтому в MM их перенести было достаточно нетрудоемко.
Да, клиенты действительно пока что прожорливые, но они с достаточной периодичностью обновляются. По крайней мере, сейчас пользователи нашего воркспейса не ощущают каких-то критичных проблем, в частности, с точки зрения юзабельности на Android.
Банально хотелось системы на том стеке, который очень хорошо знаком нашим ребятам с точки зрения поддержки, не хотелось бежать в сторону Mongodb и NodeJS, притом что MM на PostgreSQL конкретно нам проще эксплуатировать.
Важно, что mattermost можно размещать условно on-premise (в нашем случае это русское облако), соответственно, нет зависимости от вышеуказанных блокировок самой системы. Документация, к сожалению, «просто так» с русским IP недоступна.
Многие компании сейчас активно набирают сотрудников, так как начинают новые проекты и стремятся занять ниши, освободившиеся после ухода западных компаний. Адаптировать новых сотрудников к проекту и помогать им вливаться в команду — насущная необходимость, если вы не хотите, чтобы специалисты увольнялись от непонимания происходящего.
Тут два основных подхода: мы выбираем или самые затратные по времени ручные тесты, или самые сложные сценарии для подготовки среды, пользователей и т. д.
Выбрав самые сложные, можно потратить много времени и ничего хорошего не получить. Например, автоматизация отчетов: много допбиблиотек, неустойчивы из-за зависимости от данных, да и нужно придумывать, как парсить пдф или перелавливать результат до формирования файла. А функционал не основной. Любой ручник потратит не более получаса. Невыгодно.
Двойную работу не нравится делать никому. Это факт. Но тесты по НФ лучше включить в регресс, т.к. коммит с исправлением по нему или вообще часть НФ могут забыть добавить в релиз. Можно проверять НФ и в середине спринта, а потом его сломают при починке бага где-то еще.
С последним абзацем согласны. Но опять же, если баг не выше третьего и до выпуска продукта осталось меньше дня ?
Замечание справедливо, если не успевать тестировать НФ до регресса. Обычно оно у нас все-таки протестировано и описано в новых тестах до начала выпуска нового регресса. Поэтому и используем такое деление. Часть новых тестов потом войдет в ядро регресса, а остальные отправятся в архив до момента, когда в работе будет задета данная функциональность. В каком порядке проводить — это уже дело вкуса. Главное, чтобы все выбранные тесты были пройдены.
Редко дадут время на повторное прохождение всего цикла регресса, особенно если в проекте нет автоматизации. Поэтому максимум — проверка бага, перепрохождение теста, давшего ошибку, и то, редко дадут время на повторное прохождение всего цикла регресса, особенно если в проекте нет автоматизации. Поэтому максимум — проверка бага, перепрохождение теста, давшего ошибку, и то, что тестировщик успевает проверить. Это ближе к реальности.
Пожеланием заказчика было использовать встроенный инструментарий ClickHouse. Утилита clickhouse-backup, хотя и использует родные команды базы, является сторонним инструментом, что с ним будет через год — неизвестно.
В вашем случае нужно сделать две фильтрации. Сначала отобрать нужную партицию, после чего отфильтровать по id. Чтобы четко выбрать партицию, сделаем предфильтрацию. Если правильно вас поняли — партицией у вас является кортеж из полей a и b, поэтому будет использоваться виртуальный столбец _partition_value в секции prewhere.
PREWHERE _partition_value IN (select (a, b)
from dic
where name = :name_value)
Далее отфильтруем по id.
WHERE id IN (select id from dic where name = :name_value)
Спасибо за замечание по скриншотам, заменили.
По второму вопросу. Руками в нашем случае было значительно дольше, т.к. на старте проекта имелось несколько томов требований.
Что касается следующего подпункта второго вопроса — проект от перевода задач в Jira, разумеется, методологию не поменял. Однако удалось сохранить привычный темп работы команды, которая была привлечена к данному проекту, что в свою очередь, позволило решить другую задачу. Речь о пристальном внимании руководства, о котором упоминалось в начале статьи. Оно выражалось в периодической внутренней демонстрации, иногда даже в присутствии сотрудников заказчика.
Согласны, что существует порог востребованности аналитика. В небольших компаниях с продуктовой разработкой задачи аналитика действительно могут делиться между участниками. Но рано или поздно все приходят к аналитике. Иногда не напрямую, а через потребность в документировании решений или более обоснованном планировании развития продукта, что необходимо инвесторам. Другой вариант — отсутствие времени у команды и множество задач по основному профилю.
Пользователи Хабра искали вакансии системных аналитиков за рубежом https://habr.com/ru/post/655433/. На наш взгляд, получили объективные результаты в целом.
Спасибо! Добавили?
Многое зависит от железа, скорости сетевого канала, типов данных, распределения этих данных между таблицами и т.д. А пример мы привели для понимания контраста: скорость миграции одной из БД удалось сократить с 24 часов до 10 часов за счёт только этих параметров.
Конфигурация, которая описана в статье, была «отправной точкой». У нас несколько кластеров (leader-replica-replica), они работают на виртуалках 16-32 CPU, 32-128 GB RAM. Все на SSD-дисках. Далее конфигурации корректировали по результатам НТ.
У нас была только одна процедура очистки архивных данных, которую мы легко переписали. Других процедур в БД не было. На других проектах тоже занимались переносом процедур, может быть, опишем в следующих статьях:)
Что не нравится:
Поиск работает своеобразно. Это, пожалуй, самый большой минус.
Более прожорливые клиенты.
До оптимизации БД были серьезные лаги по отправке сообщений.
Есть баги по тредам (они только вышли из бета-версии).
Баги с unread-сообщениями.
В остальном серьезных отличий от Slack не видим.
Большее количество ботов, которые мы сделали, когда пользовались Slack, работают по принципу «От Slack нам нужен только hook для отправки уведомления», поэтому в MM их перенести было достаточно нетрудоемко.
Да, клиенты действительно пока что прожорливые, но они с достаточной периодичностью обновляются. По крайней мере, сейчас пользователи нашего воркспейса не ощущают каких-то критичных проблем, в частности, с точки зрения юзабельности на Android.
Банально хотелось системы на том стеке, который очень хорошо знаком нашим ребятам с точки зрения поддержки, не хотелось бежать в сторону Mongodb и NodeJS, притом что MM на PostgreSQL конкретно нам проще эксплуатировать.
Важно, что mattermost можно размещать условно on-premise (в нашем случае это русское облако), соответственно, нет зависимости от вышеуказанных блокировок самой системы. Документация, к сожалению, «просто так» с русским IP недоступна.
Многие компании сейчас активно набирают сотрудников, так как начинают новые проекты и стремятся занять ниши, освободившиеся после ухода западных компаний. Адаптировать новых сотрудников к проекту и помогать им вливаться в команду — насущная необходимость, если вы не хотите, чтобы специалисты увольнялись от непонимания происходящего.