Данный пост решил посвятить одному приему, который я использую на «постоянно» развивающихся проектах. Пост не претендует на уникальность, наверняка кто то уже использовал аналог нижеописанного.
О каких проектах пойдет речь:
Существуют проекты, которые уже запущены, работают, есть посещающие проект пользователи, но… механизмы совершенствуются, меняются интерфейсы, происходят другие изменения, меняются бизнес-процессы в компании и т.д., и, в то же время, процесс разработки не должен мешать текущей эксплуатации проекта.
О чем пойдет речь: какой прием можно использовать при масштабных изменениях механизмов и тестировании на «живых» сайтах, не создавая проблем работающим с сайтами пользователям.
Прелюдия:
Рассмотрим самый простой пример:
Пусть есть некая страница проекта index1.php
На данной странице располагается какой то компонент или код, или же просто статика.
Нам требуется изменить сценарий работы страницы, не мешая текущей эксплуатации системы. При этом нам не хотелось бы создавать «тестовых» дубликатов данной страницы и разрабатывать и тестировать наши механизмы необходимо именно по текущему адресу.
Один из используемых способов – повзолить работать с новыми механизмами только избранным, т.е. поставить условие с учетом прав доступа
LST1
Или
LST2
Во втором случае я для удобства использую константу, определяющую группу, в которую входят пользователи с доступным новым разрабатываемым функционалом. Или просто бета-тестеры.
Можно указать и ID группы, но иногда бывает, что надо посмотреть, как будет выглядеть новый функционал для той или иной группы и при этом иметь возможность оперативного переключения.
* МОжно также поставить условие на вхождение в список групп. Этот момент в данном посте не столь важен
Опишу еще момент, который иногда использую, но он не имеет отношения к сути поста.
Дополнительно, для удобства я завожу константу, в которой храню ID группы пользователей, которым можно видеть отладочную информацию.
Для вывода отладочной информации просто использую
LST3
или
LST4
где myComment - просто готовая функция для вывода отладочной информации. (сие уже неоднократно рассматривалось в сообществе)
В принципе ничего особенного и интересного, за исключением того, что вы, поставив в коде можете забыть про этап "уборки" на предмет оставленных отладочных комментариев. Достаточно изменить значение нашей константы на несуществующий ID и никто нашей информации уже никогда не увидит.
При масштабной разработке это бывает полезно.
*Конечно, оставлять отладочные строки в коде некрасиво, но... почему бы не иметь в своем арсенале альтернативный механиз управления с помощью одного лишь "переключателя"?
Все это была прелюдия…
Переходим к основной части.
Представим, что у нас проект масштабный и изменение функционала потребует корректировки N мест проекта.
А теперь представляем, что мы все выполнили, бета-тестеры все протестировали, теперь надо изменения "накатить"
Если мы использовали варианты LST1 или LST2, то остается лишь пройтись по всем N точкам и скорректировать код таким образом, чтобы новый функционал стал доступен всем.
Удобно?
Один раз мне пришлось "пройти" около десятка таких точек. Не сладко. Время тоже жалко.
Приходится кропотливо документировать не только изменения, но и совершенные действия, дабы не запамятовать, где и когда что включалось или отключалось.Рутина...
А почему бы не решить вопрос созданием аналога механизма, описанного в приеме для отладочной информации?
В итоге пришел к следующему решению:
Каждый новый процесс изменения механизмов или шаблонов рассматриваю как новую версию проекта (с точки зрения проектирования ничего нового
)
Ввожу новую константу
PROJECT_VERSION – целое число, которое обозначает текущую версию проекта
Для мест, где происходит изменение механизмов или замена на новые механизмы, используем условие чуть сложнее
LST5
Где N – версия проекта, при которой данные изменения вступают в силу.
В результате имеем следующее: Для бета-тестеров работают новые механизмы
Для остальных – старые до тех пор, пока версия проекта не позволит использовать новые.
Т.е. при необходимости мы осуществляем привязку к группе, а для управления запуском или откатом изменений получаем «переключатель» в виде константы
LST5 – просто пример, он может выглядеть и иначе. Суть в том, что вам необходимо прописать варианты выбора между действиями в зависимости от версии проекта, т.е. сделать привязку к нашей константе.
В результате использования данного решения имеем возможность параллельно эксплуатации вести разработку или доработку (логики компонент, шаблонов и т.д.) с поддержкой работы бета-тестеров.
«Накат» и «Откат» новых механизмов производим лишь изменением значения нашей константы. (обычно пара минут, иногда и меньше)
Пример использования:
Сейчас у меня на одном из проектов будет изменение двухэтапное
Есть часть механизмов, которые надо будет запустить в день А, а есть часть, которые надо будет изменить в день В
Текущая версия у меня 2
Первую часть изменений я фиксирую за версией 3
Вторую часть изменений за версией 4
И те и другие механизмы разрабатываются и тестируются бета-тестерами, «рядовым» пользователям станут доступны только при изменении значения константы PROJECT_VERSION
Что еще надо отметить:
Есть и ограничение в данном приеме – линейность…
Предположим, что нам надо сделать две независимые друг от друга корректировки или доработки, каждая из которых затрагивает несколько механизмов.
Привязать изменения к разным версиям – значит сделать одно зависимым от другого
Привязать к одной версии – значит потерять независимость управления версиями
Как ни крути, а для таких задач вышеизложенное решение не подходит. Сталкиваться с таким не приходилось. В большинстве случаев разработка осуществляется линейно (В принципе такая линейность характерна для ПО. Как правило все релизы и версии – линейны), но буду благодарен любому совету к данному посту.
Вот и все...
Надеюсь кому нибудь данный прием поможет и станет верным помошником
P.S.
То, что не вошло в пост, но хотелось бы отметить
Если мне необходимо менять логику работы компонента – предпочитаю создание нового компонента (новой версии). Так как гораздо удобнее, для этого в месте вызова надо просто указать:
При корректировке логики уже существующего вы ставите себя в зависимость от результатов разработки и можете "сжечь" мосты назад. А также теряете возможность легкого управления версионностью
Кроме того придется решить и такие задачи:
1. следить в коде компонента за соблюдением работоспособности при различных версиях
2. не мешать своей разработкой пользователям, использующим те же компоненты.
Для случаев с шаблонами – все еще проще
В условии определяю код шаблона и далее подключаю компонент с нужным шаблоном в зависимости от версии (шаблоны тоже делаем по версиям)
что нибудь типа такого
или типа такого
Для того, чтобы использовать все вышеописанное в комплексе, ввожу три константы:
1. – версия проекта
2. – группа бета-тестеров
3. - группа, которой видная отладочная информация
и код стараюсь делать с учетом данных "переключателей"
ну вот и все...
если что не так написано - не судите строго
О каких проектах пойдет речь:
Существуют проекты, которые уже запущены, работают, есть посещающие проект пользователи, но… механизмы совершенствуются, меняются интерфейсы, происходят другие изменения, меняются бизнес-процессы в компании и т.д., и, в то же время, процесс разработки не должен мешать текущей эксплуатации проекта.
О чем пойдет речь: какой прием можно использовать при масштабных изменениях механизмов и тестировании на «живых» сайтах, не создавая проблем работающим с сайтами пользователям.
Прелюдия:
Рассмотрим самый простой пример:
Пусть есть некая страница проекта index1.php
На данной странице располагается какой то компонент или код, или же просто статика.
Нам требуется изменить сценарий работы страницы, не мешая текущей эксплуатации системы. При этом нам не хотелось бы создавать «тестовых» дубликатов данной страницы и разрабатывать и тестировать наши механизмы необходимо именно по текущему адресу.
Один из используемых способов – повзолить работать с новыми механизмами только избранным, т.е. поставить условие с учетом прав доступа
LST1
If ($USER->IsAdmin()): Новый функционал Else: Старый функционал Endif; |
Или
LST2
| if (in_array(TEST_USERS_GROUP, $USER->GetUserGroupArray())): Новый функционал Else: Старый функционал Endif; |
Во втором случае я для удобства использую константу, определяющую группу, в которую входят пользователи с доступным новым разрабатываемым функционалом. Или просто бета-тестеры.
Можно указать и ID группы, но иногда бывает, что надо посмотреть, как будет выглядеть новый функционал для той или иной группы и при этом иметь возможность оперативного переключения.
* МОжно также поставить условие на вхождение в список групп. Этот момент в данном посте не столь важен
Опишу еще момент, который иногда использую, но он не имеет отношения к сути поста.
Дополнительно, для удобства я завожу константу, в которой храню ID группы пользователей, которым можно видеть отладочную информацию.
Для вывода отладочной информации просто использую
LST3
If (in_array(VIEWBUGS_USERS_GROUP, $USER->GetUserGroupArray())){
Echo “<pre>”; print_r(…); echo “</pre>”;
} |
или
LST4
If (in_array(VIEWBUGS_USERS_GROUP, $USER->GetUserGroupArray())){
myComment($arVar);
} |
где myComment - просто готовая функция для вывода отладочной информации. (сие уже неоднократно рассматривалось в сообществе)
В принципе ничего особенного и интересного, за исключением того, что вы, поставив в коде можете забыть про этап "уборки" на предмет оставленных отладочных комментариев. Достаточно изменить значение нашей константы на несуществующий ID и никто нашей информации уже никогда не увидит.
При масштабной разработке это бывает полезно.
*Конечно, оставлять отладочные строки в коде некрасиво, но... почему бы не иметь в своем арсенале альтернативный механиз управления с помощью одного лишь "переключателя"?
Все это была прелюдия…
Переходим к основной части.
Представим, что у нас проект масштабный и изменение функционала потребует корректировки N мест проекта.
А теперь представляем, что мы все выполнили, бета-тестеры все протестировали, теперь надо изменения "накатить"
Если мы использовали варианты LST1 или LST2, то остается лишь пройтись по всем N точкам и скорректировать код таким образом, чтобы новый функционал стал доступен всем.
Удобно?
Один раз мне пришлось "пройти" около десятка таких точек. Не сладко. Время тоже жалко.
Приходится кропотливо документировать не только изменения, но и совершенные действия, дабы не запамятовать, где и когда что включалось или отключалось.Рутина...
А почему бы не решить вопрос созданием аналога механизма, описанного в приеме для отладочной информации?
В итоге пришел к следующему решению:
Каждый новый процесс изменения механизмов или шаблонов рассматриваю как новую версию проекта (с точки зрения проектирования ничего нового
)Ввожу новую константу
PROJECT_VERSION – целое число, которое обозначает текущую версию проекта
Для мест, где происходит изменение механизмов или замена на новые механизмы, используем условие чуть сложнее
LST5
if (in_array(TEST_USERS_GROUP, $USER->GetUserGroupArray()) || PROJECT_VERSION>=N): Новый функционал Else: Старый функционал Endif; |
Где N – версия проекта, при которой данные изменения вступают в силу.
В результате имеем следующее: Для бета-тестеров работают новые механизмы
Для остальных – старые до тех пор, пока версия проекта не позволит использовать новые.
Т.е. при необходимости мы осуществляем привязку к группе, а для управления запуском или откатом изменений получаем «переключатель» в виде константы
LST5 – просто пример, он может выглядеть и иначе. Суть в том, что вам необходимо прописать варианты выбора между действиями в зависимости от версии проекта, т.е. сделать привязку к нашей константе.
В результате использования данного решения имеем возможность параллельно эксплуатации вести разработку или доработку (логики компонент, шаблонов и т.д.) с поддержкой работы бета-тестеров.
«Накат» и «Откат» новых механизмов производим лишь изменением значения нашей константы. (обычно пара минут, иногда и меньше)
Пример использования:
Сейчас у меня на одном из проектов будет изменение двухэтапное
Есть часть механизмов, которые надо будет запустить в день А, а есть часть, которые надо будет изменить в день В
Текущая версия у меня 2
Первую часть изменений я фиксирую за версией 3
Вторую часть изменений за версией 4
И те и другие механизмы разрабатываются и тестируются бета-тестерами, «рядовым» пользователям станут доступны только при изменении значения константы PROJECT_VERSION
Что еще надо отметить:
Есть и ограничение в данном приеме – линейность…
Предположим, что нам надо сделать две независимые друг от друга корректировки или доработки, каждая из которых затрагивает несколько механизмов.
Привязать изменения к разным версиям – значит сделать одно зависимым от другого
Привязать к одной версии – значит потерять независимость управления версиями
Как ни крути, а для таких задач вышеизложенное решение не подходит. Сталкиваться с таким не приходилось. В большинстве случаев разработка осуществляется линейно (В принципе такая линейность характерна для ПО. Как правило все релизы и версии – линейны), но буду благодарен любому совету к данному посту.
Вот и все...
Надеюсь кому нибудь данный прием поможет и станет верным помошником
P.S.
То, что не вошло в пост, но хотелось бы отметить
Если мне необходимо менять логику работы компонента – предпочитаю создание нового компонента (новой версии). Так как гораздо удобнее, для этого в месте вызова надо просто указать:
if (in_array(TEST_USERS_GROUP, $USER->GetUserGroupArray()) || PROJECT_VERSION>N): $APPLICATION->IncludeComponent(“новый”,….. Else: $APPLICATION->IncludeComponent(“старый”,….. Endif; |
При корректировке логики уже существующего вы ставите себя в зависимость от результатов разработки и можете "сжечь" мосты назад. А также теряете возможность легкого управления версионностью
Кроме того придется решить и такие задачи:
1. следить в коде компонента за соблюдением работоспособности при различных версиях
2. не мешать своей разработкой пользователям, использующим те же компоненты.
Для случаев с шаблонами – все еще проще
В условии определяю код шаблона и далее подключаю компонент с нужным шаблоном в зависимости от версии (шаблоны тоже делаем по версиям)
что нибудь типа такого
if (in_array(TEST_USERS_GROUP, $USER->GetUserGroupArray())
|| PROJECT_VERSION>N)
{
$templ = "ShablonNew";
}
else
{
$templ = "ShablonOld";
}
$APPLICATION->IncludeComponent(“новый”,…..
|
или типа такого
if (in_array(TEST_USERS_GROUP, $USER->GetUserGroupArray())
|| PROJECT_VERSION>N)
{
$templ = "Shablon_v".N;
}
else
{
$templ = "Shablon_v".(N-1);
}
$APPLICATION->IncludeComponent(“новый”,…..
|
Для того, чтобы использовать все вышеописанное в комплексе, ввожу три константы:
1. – версия проекта
2. – группа бета-тестеров
3. - группа, которой видная отладочная информация
и код стараюсь делать с учетом данных "переключателей"
ну вот и все...
если что не так написано - не судите строго
не решен.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
