Если они работают в одной ветке, то куча багов будет вылезать еще до мержа.

Да, но не будет ситуации, когда задача1 проверена, задача2 проверена, а после мержа сломалась и та, и другая

То есть ветка на задачу в теории выглядит здорово, но когда мы попробовали использовать, поняли, что всё не так радужно. Вот пытаюсь понять, что мы делали не так)

Если все время работа над одним и тем же местом кода, значит это плохое качество декомпозиции задач.

коллеги, поделитесь пожалуйста опытом. кто как тестирует (веб-сервис) на продакшене и как скрываются тестовые данные и тестовые аккаунты от пользователей?

Тут смотря как удобнее - либо разрабы ручками скриывают, либо вы, либо через интерфейс

Значит код берет на себя слишком много ответственности => нарушение SRP

Если все время работа над одним и тем же местом кода, значит это плохое качество декомпозиции задач.

Не всё время, но ситуация реальная. Вполне очевидно, что есть проблема с распределением задач. А может проблема выше и она в декомпозиции или ещё в чём-то.

Ну тут короче надо смотреть по ситуации и по коду, сферического ответа в вакууме не существует. По моему опыту, если в целом качество разработки не сильно крутое - невнимательная декомпозиция задач, недостаточное написание тестов, неследование SOLID - то и проблем получается при мерже больше.

это настолько индивидуально для каждого проекта, что прям общая практика вряд ли будет

коллеги, поделитесь пожалуйста опытом. кто как тестирует (веб-сервис) на продакшене и как скрываются тестовые данные и тестовые аккаунты от пользователей?

я вот имею возможность реально разработку привлечь для выкладки кода, который тестовые данные огораживает от бизнес-процессов, давая нам возможность в своей песочнице на проде ковыряться

в таких случаях выступаю ПМом для задач, нужных только отделу тестирования

мне всегда казалось что тестировать нужно ДО продакшена

потому что с таким "огораживанием данных" можно иногда получить неожиданные косяки

и?

на продакшене нужен функциональный мониторинг. и это не про тесты получается

В моей практике доступа на прод простым смертным не давали))

а что, телеграм съел мою фразу про "все индивидуально"?

конкретно в нашем проекте всегда есть необходимость в тестировании на проде

именно тестирования?

это обязаловка, которая страхует от багов окружения, дефектов публикации и прочих проблем

конкретно в нашем проекте всегда есть необходимость в тестировании на проде

Завести тестовые учётки и никому не говорить что они есть?

мониторинг тоже есть, но это о другом

почему не говорить

СБ в курсе всех наших учеток

а у вас специфика проекта такая, что аккаунты нужно именно скрывать, иначе они как-то портят работу другим?

мониторинг может быть очень разным, в том числе и бизнес процессов

не, конкретно с аккаунтами специфики такой нет

есть специфика с тестовыми данными

вот чтобы их не показывать озерам, мы и реализуем разный функционал, позволяющий работать на проде с тестовыми данными

*юзерам

мониторинг и тестирование релиза на проде - вообще разные вещи

а вы уверены что в этом случае вы проверяете реальное поведение системы, а не те, особенности, которые именно для вас "зашили"?

конечно уверены

нет уж, буду всё отрицать

ну окей, если уверены

У нас сейчас скрытые юзеры на проде, но хотят сделать тестовый прод)

всегда есть тонкая грань, которая отделяет тестовую песочницу от реальных данных, и да, на этой грани можно упустить дефект но риск такого дефекта сильно меньше, чем риск необнаружения дефектов без возможности тестирования прода

мы такое же задумали одну ноду прода сделаем релизной, туда будем выкатывать релиз, тестировать в боевом окружении, после этого уже переключать на боевую базу и синкать с остальными нодами

У нас сейчас скрытые юзеры на проде, но хотят сделать тестовый прод)

тонко настроенная конфигурация?

ну, не особо там тонко

просто ноду выводим из балансера, строка коннекта к бд меняется на песочную

а это, кстати, может быть очень удобным

это единственный человечный вариант реализации тестирования в условиях, идентичных проду

плюс еще пара заглушек на взаимодействие с внешними системами

просто ноду выводим из балансера, строка коннекта к бд меняется на песочную

И можно нартавлять на него автотесты со спокойной душой

да

у нас практически 1:1 стенд тестирования. если где и могут быть косяки - так это при установке и настройке какой-нибудь вебсферы.

мы вот этой 1:1 позволить себе не можем

параллельно в тестировании всегда несколько релизов, плюс адская куча веток с отдельными задачами

разворачивать под это дело отдельный прод (который и так довольно мощный ввиду нагрузки) - роскошь

а у вас одна тестовая среда на всё это или много мелких по запросу?

для этого у нас упрощённые стенды без кучи крутых защит

ну сейчас переходный период

в данный момент работаем на одном QA-сервере с кучей веток в перспективе переезжаем на внутреннюю разработку, там все в докерах по уши, изоляция, отдельные бд, коммунизм и прочее

мы тоже пошли по пути "много мелких" + пара пре-продакшенов

ну это от объема зависит всегда

и докера наелись) и ещё в процессе

у нас по десятку релизов в неделю

мы тоже пошли по пути "много мелких" + пара пре-продакшенов

вот у нас так и есть.

распараллеливание тестирования тут просто необходимо

ну у нас SOA, тоже стопятьсот мелких релизов, веток и прочее

у нас по десятку релизов в неделю

ого. раз в два месяца наш норматив)

ну, у всех своя специфика

мы веб-проект с живой аудиторией

нам нужно адски быстро реагировать на увелчивающиеся аппетиты бизнеса

мы веб-проект с живой аудиторией

Ну да, у остальных-то аудитория мёртвая )

ну у всех все разное

в банковском секторе подобная спешка не в почете

@kochyn а что у вас за проектик такой интересный? если не секрет конечно)

CarPrice

прикольно никогда такой сервис не видел - продажа авто на аукционе для диллеров

Крутой сервис. Пару месяцев назад продавал авто)) Адреналина на аукционе хватило))

через этот сервис продавал?

@kochyn а что у вас там под капотом? какая-то CRM и в ней так много изменений? Так на сайтик взглянуть - обычная визитка с формой..

продал в итоге?

Крутой сервис. Пару месяцев назад продавал авто)) Адреналина на аукционе хватило))

у нас сайт для клиентов (тех, кто продает) и отдельный для дилеров (которые за машину торгуются) на это все навернута мощная инфраструктура по полному сопровождению авто от момента приезда клиента до момента передачи дилеру

@kochyn а что у вас там под капотом? какая-то CRM и в ней так много изменений? Так на сайтик взглянуть - обычная визитка с формой..

CarPrice

Мне кажется я подкаст слушала с создателем этого сервиса

а можно поинтересоваться, почему выбрали движок 1c-bitrix?

слышал о нем плохие только отзывы

ну, куча всяких разных причин внутренних на том этапе битрикс покрывал все потребности компании

битрикс разработчики не слишком любят просто потому, что это все-таки сторонняя разработка, и в ядро к нему лезть - дело неблагодарное, плюс обновлений лишаешься

а теперь только мучаетесь с ним?

почему мучаемся

эт вопросик :-)

работаем

из профессионального любопытства

с битриксом, насколько понимаю, ситуация идентична продукции майкрософта: принято ругать, но столь же принято использовать

культура такая сложилась, в общем

ну я когда на фрилансе работал, у меня сложилось мнение, что в россии подавляющее большинство использует битрикс, а вот в украине - можно пересчитать по пальцам (я конечно могу ошибаться, но примерно такое впечатление сложилось) и вот еще тоже хороший вопрос, вы как создатели своего продукта, завязались на битриксе и теперь в ядро не лезите, чтобы обновления получать и вдруг что можно было им баги отправлять, чтобы сами фиксили