Хотелось бы узнать, кто и как выворачивается в ситуации, когда заказчику нужна некая фича на сайте, а организовать "песочницу" по тем или иным причинам нельзя? При этом сайт нежелательно останавливать...

Вот, например, одна из схем. 
При указании в урл параметра `&test=flag1,flag2,flag3` формируется кука с именем test и содержимым `flag1,flag2,flag3`. После формирования куки происходит переход по адресу, с вычищеным от этого параметра значением URI.
При наличии этой куки, программист может, например, использовать функцию

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

На моем прошлом месте работы (крупный известный сайт в РУ сегменте) мы делали примерно как ты сказал (с использованием get-параметров, но без кук) - в Url подставлялся некий ключ, далее имелось функция, проверяющая "офисный ли это ИПшник, либо userId из списка IDшников разработчиков (на случай, если из дома)" и тогда делаем, что нам нужно. В коде это выглядело примерно так:



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


либо, через систему таргетингов (удобно для тестеров, когда не все их пользователи - редактора):


А в админке таргетингов нужно создать таргетинг с именем myTestTargeting, например по тому же перечню IDшников, либо другому списку идентификаторов.

Aliance, кука удобна тем, что внешне, для пользователя ничего не меняется, ни адреса на странице, ни функционал. Тестирование более полное... Так можно отладить не одну страницу, а целый плагин, с ajax'ом и формами. Параметры в адресной строке нужно будет либо передавать по генерируемым страницей ссылкам, либо ограничится отладкой одной страницы.

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

Для работы некого функционала "для своих", но не имея userId (например, страница для незалогиненных) можно ограничиться методом isOurIP() (воспринимай его как абстрактный поток мыслей, как реализовать - дело твое, можно по ИПу офиса, можно по куке).

По в любом случае проверять что-то только по куке - точно не секурно.

Aliance, а что за проблемы с куками? Ну пусть я отлаживал сервис, проект заглох и я  благополучно забыл его на чужом сайте. Это само по себе косяк, оставить отладочные вставки, ну да ладно... Если плагин не содержит в себе устройство для взлома сайта - его внезапное появление для пытливого пользователя, вроде как, безопасно. 

Фильтр по IP несколько затрудняет демонстрацию фичи заказчику. Придется сначала выяснять этот самый IP... Хотя, в принципе, правильно.

Я говорил о подобном функционале в целом, а не в частности - не разделяя на то, несет ли он в себе опасность или нет. И, кстати, что подразумевается под плагином? JS что ли, мы же в треде по PHP =)

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


для этого придумали стейджинговые сервера 

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

Насчет плагинов
Задачки возникают разные и на разных платформах, разных CMS. Где-то что-то добавить/исправить - систему слежения за банерами, поиск по сайту, какие-то формы-подписки. Название  "плагин", imho, вполне подходит для задачи с неопределенным объемом работы    
Тем более, что такая задачка, таким образом отлаживаемая, идеологически плагином и является - удалил флажок в куках - вот и нет его. А после отладки тот флаг можно заменить на флажок в конфигурации...
Все дело в системе определений. 

Если вы пишите свое, и подключаете модуль (плагин в рамках РНР понятие резиновое), то вроде бы как рационально, чтобы модуль мог иметь режим активен/неактивен или отображается/не отображается. А что мешает добавить еще и режим "отладка"? Ну ладно бы они написаны вами "капитально и навека", но ведь и старое зачастую обновляется, и тоже возникает потребность в отладке.
Естественно, что режим отладки, в этом случае, доступен в режиме администрирования - тут и конфигурация, и опции, и "опознавание" не по временным кукам, а по входу администратора. А для пользователя этот режим тоже самое что и неактивен.   

Чтобы не растекаться уж совсем мыслию по древу, вот пример для "посмотреть".


whatisnot, меня интересует сам процесс монтажа уже "в принципе готового" модуля в работающую систему. Модуль еще требуется доработать напильником по месту, однако остальные пользователи системы не должны сильно пострадать. В идеальном случае - они не должны ощутить ничего, до момента окончания отладки. Этот класс и будет тем скотчем, на который можно "наживить" тот самый модуль и избежать, потенциально, отрицательных последствий для обычных пользователей.

Класс статический, так как одно из назначений его - гарантировать текстово-единообразный след в исходниках. Можно просто тупо поискать `DBG::` по файлам и обнаружить все "точки склейки" модуля и системы. Собственно монтаж будет начинаться с подключения класса во все возможные точки входа системы, довольно удобно - добавить его в auto_prepend_file. Окончательная вклейка модуля в систему заключается в выкидывании упоминания DBG из "точек склейки" и чистка препенда.

Это сообщение отредактировал(а) ksnk - 12.2.2015, 15:49

Хотите скачать, что без некоего индивидуального флага у модуля, без кук и припарок preg_match невозможно "отключить" пользователя? Ну это же не так. Для упрощения:

У меня в системе три ресурса - А, B, C. Могу ли я через конфигурацию отключить вывод любого из этого ресурсов пользователю, а для себя сделать доступным? Могу.
Пусть и ресурсы имеют подключаемые модули. Могу ли я и их через конфигурацию также сделать недоступными для пользователя? Могу.
Если я включаю режим отладки ресурсу/модулю, вхожу как администратор и в одном браузере открыт и раздел управления, и страница ресурса, то мне и кук не требуется, меня и сессия "опознает".

Я не говорю, что вы поступаете не так, каждый волен думать так, как он думает. Просто я исхожу из того, что если уж делать систему, то лучше ее делать кофигурируемой не только для случаев "А показывать в Б", но и показывать ли А и кому. 

whatisnot, Мы говорим о разных вещах. Тред назван ` Тестирование новых фич сайта "на лету"`. Вероятно, нужно было назвать "монтаж".
К примеру, на некий сайт требуется поставить поиск. По каким-то причинам (самодельный CMS, неподходящий набор плагинов...) разумной системы поиска у него нет. 
Монтируемый модуль поиска имеет "точки вклейки" в систему
-- шаблон вывода header'а - туда нужно вставить вывод формы поиска,  скриптовые и стилевые изменения.
-- вывод страницы с результатами поиска - отдельные страницы в дизайне сайта
-- настройка плагина в админке  (очистка результатов, переиндексация, параметры ets...)

Изменений дофига и уследить за корректным и сразу 100% работающим кодом достаточно сложно. Ломать внешний вид сайта и обижать клиенов на время отладки нельзя.

Класс расчитан именно на это время, от начала монтажа, до окончания отладки. После этого он удаляется с сервера за ненадобностью.

Не знаю, видимо у нас разные понимания и понятия модуль, и что такое подкулючить модуль. В моем понимании составляющие модуля, а это html-код его, стили, клиентский сценарий (если есть) не живут сами по себе, и если их "хозяин" (серверный скрипт) не запущен, то и их нет у клиента. Кто при этом и как может что-то поломать на клиенте, я не понимаю.

Видимо, да. В моей практике регулярно повляются самодельные и native-php сайты, и `модуль`или `плагин` для них - достаточно резиновое понятие. 

Если ваш "самодельный" не имел модуля поиска, то как он работал без него, ничего в нем "не ломалось"? Думаю нет. Добавили модуль, кторый доступен только вам, что-то "поломалось", кто это видит, вы или все? Видимо только вы. А что видит пользователь? Прежнее. В чем беда, я не понимаю.
Я так понимаю, что это и есть ваш аргумент в пользу кук с классами. Но до меня он не доходит, ибо по логике вещей такого просто быть не может. А если моудуль не изолированный, как тот же поиск, и так или иначе затрагивает русуры страницы, если это можно сделать через конфигурацию, то и поставить всю страницу в режим отладки нет проблем - в этом режиме она будет опять таки доступна только вам. И по большому счету, как это будет сделано роли не играет, вопрос только в гибкости и удобстве.

А где там точка входа у модуля, это ну никак не должно влиять на саму суть отладки, а плодить еще и какие-то классы, которые после отладки еще и выковыривать надо... Ну коли считаете это необходимостью, заради бога.

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