Что быстрее Memcache или file_get_contents()
- Автор темы sunyang
- Дата начала
~WR~
Новичок
Нет, без симлинков становится возможен вот какой сценарий.
1). Запустили длинный скрипт. Он работал какое-то время и прочитал часть файлов конфига.
2). Разложили новую версию конфига.
3). Скрипт продолжает работать и читать другие части. Но они уже от новой версии.
Идея с realpath в том, чтобы один запуск скрипта всегда работал только с одной версией конфига no matter what.
Даже если будет раскладка новой версии, ранее запущенные скрипты спокойно продолжат пользоваться старой.
1). Запустили длинный скрипт. Он работал какое-то время и прочитал часть файлов конфига.
2). Разложили новую версию конфига.
3). Скрипт продолжает работать и читать другие части. Но они уже от новой версии.
Идея с realpath в том, чтобы один запуск скрипта всегда работал только с одной версией конфига no matter what.
Даже если будет раскладка новой версии, ранее запущенные скрипты спокойно продолжат пользоваться старой.
~WR~
Новичок
По смыслу, эта сущность живет и раскладывается независимо от кода.
Скажем, активная версия кода живет в /local/www/
Активная версия конфига в /local/config/223/
Симлинк на активную версию конфига: /local/config/current/
Путь в $_SERVER будет смотреть на сам скрипт.
Мы же хотим один раз получать реальный путь к конфигу: $this->config_path = realpath('/local/config/current');
И потом использовать его для всех остальных запросов в рамках этого скрипта.
Скажем, активная версия кода живет в /local/www/
Активная версия конфига в /local/config/223/
Симлинк на активную версию конфига: /local/config/current/
Путь в $_SERVER будет смотреть на сам скрипт.
Мы же хотим один раз получать реальный путь к конфигу: $this->config_path = realpath('/local/config/current');
И потом использовать его для всех остальных запросов в рамках этого скрипта.
~WR~
Новичок
А, я понял. Нет проблем 
По сути, то же самое, только вид сбоку.
На самом деле, в реальном приложении логика выбора пути чуть сложнее. Последовательно проверяется несколько вариантов, первых из которых - путь для продакшна.
На девеле же есть общий стандартный конфиг для всех разработчиков, но каждый имеет возможность сгенерить свою собственную тестовую версию и не задеть остальных.
Также может быть отдельный путь для тестов и для разных агентов в teamcity. Типа, проверка одного и того же кода с разными конфигами.
Здесь уже не всё так однозначно.
Но, если таких сложностей не нужно, то разницы нет.
По сути, то же самое, только вид сбоку.На самом деле, в реальном приложении логика выбора пути чуть сложнее. Последовательно проверяется несколько вариантов, первых из которых - путь для продакшна.
На девеле же есть общий стандартный конфиг для всех разработчиков, но каждый имеет возможность сгенерить свою собственную тестовую версию и не задеть остальных.
Также может быть отдельный путь для тестов и для разных агентов в teamcity. Типа, проверка одного и того же кода с разными конфигами.
Здесь уже не всё так однозначно.
Но, если таких сложностей не нужно, то разницы нет.
А зачем на продакшене перебирать варианты? Там можно сразу разложить смердженное для данной среды.
На девеле то да, у меня вообще рекурсивный мержинг CFG_PATH/$configName.config.php + CFG_PATH/$envName/$configName.config.php
UPD
Кстати, с realpath надо аккуратно - некоторые опкод-кэшеры вполне могут оверрайдить realpath cache на персистентный. Кажется, новоявленный ZendOptimizerPlus такое делает при определенных настройках.
На девеле то да, у меня вообще рекурсивный мержинг CFG_PATH/$configName.config.php + CFG_PATH/$envName/$configName.config.php
UPD
Кстати, с realpath надо аккуратно - некоторые опкод-кэшеры вполне могут оверрайдить realpath cache на персистентный. Кажется, новоявленный ZendOptimizerPlus такое делает при определенных настройках.
~WR~
Новичок
На продакшне он сразу находит первый вариант и совсем не проверяет остальные.
В нашем случае, физически файлы конфигов и версии одинаковы для продакшна, стейджинга и девела.
Разграничение по environment'у делается на стадии проверок в коде. И оно инкрементальное.
Например:
Включить что-то только на продакшне, но выключить на девеле в принципе нельзя. Специально сделали такое ограничение, чтобы тесты всегда проверяли версию, максимально близкую к продакшну.
Без него будет возможна ситуация, когда у QA на стейджинге нет никаких проблем, а на продакшне всё сломалось, т.к. для продакшна что-то внезапно оказалось включено.
В нашем случае, физически файлы конфигов и версии одинаковы для продакшна, стейджинга и девела.
Разграничение по environment'у делается на стадии проверок в коде. И оно инкрементальное.
Например:
PHP:
env=0 //выключено совсем
env=1 //включено на девеле
env=2 //включено на девеле и стейджинге
env=3 //включено на девеле, стейджинге и продакшнеБез него будет возможна ситуация, когда у QA на стейджинге нет никаких проблем, а на продакшне всё сломалось, т.к. для продакшна что-то внезапно оказалось включено.
~WR~
Новичок
Наоборот - так сильно проще.
Реальная ситуация: добавляется новый метод оплаты в Зимбабве.
С одной стороны - нужны изменения в коде, которые будут показывать формочки и обрабатывать реквесты.
С другой стороны - ему сразу нужны цены в конфиге.
Выкатываем новые конфиги на стейджинг и продакшн.
Выкатываем код на стейджинг. Смотрим, что всё работает.
Выкатываем код на продакшн. Он сразу же начинает работать точно на тех же конфигах, которые только что были проверены.
В той ситуации, когда стейдж работает на одном конфиге, а прод - на другом, выше риск ошибиться и что-то пропустить. Больше заморочек, сложнее контролировать.
Реальная ситуация: добавляется новый метод оплаты в Зимбабве.
С одной стороны - нужны изменения в коде, которые будут показывать формочки и обрабатывать реквесты.
С другой стороны - ему сразу нужны цены в конфиге.
Выкатываем новые конфиги на стейджинг и продакшн.
Выкатываем код на стейджинг. Смотрим, что всё работает.
Выкатываем код на продакшн. Он сразу же начинает работать точно на тех же конфигах, которые только что были проверены.
В той ситуации, когда стейдж работает на одном конфиге, а прод - на другом, выше риск ошибиться и что-то пропустить. Больше заморочек, сложнее контролировать.
~WR~
Новичок
Еще забавный момент, почему дефолтный конфиг для девела тоже должен генерироваться с данных продакшна.
Если это будет не так, то базы продакшна и девела очень быстро разойдутся.
Поддерживать их одинаковость всем в лом - проверено. Особенно если там 50+ таблиц.
И девел должен максимально повторять поведение продакшна. Тесты должны гоняться в условиях, максимально приближенных к боевым.
Отсюда такой интересный финт, который, тем не менее, приходится часто объяснять новеньким.
Если это будет не так, то базы продакшна и девела очень быстро разойдутся.
Поддерживать их одинаковость всем в лом - проверено.
Особенно если там 50+ таблиц.И девел должен максимально повторять поведение продакшна. Тесты должны гоняться в условиях, максимально приближенных к боевым.
Отсюда такой интересный финт, который, тем не менее, приходится часто объяснять новеньким.
Так, ну подожди, а я разве не о том же самом?
Есть production сборки конфигов, тегом stable мечено то, что на прод. Есть новый конфиг (head). Есть новый код.
1) выкатили config/head на staging
1.5) тут тоже неплохо проверить, что с новым конфигом старая прод-версия - которая пока еще на staging - внезапно не ломается
2) выкатили новый код на staging
3) протестировали, работает
4) меняем тег, выкладываем новый (уже -stable) конфиг на прод
5) деплоим новый код на прод
В каком месте разница, чото не пойму
Есть production сборки конфигов, тегом stable мечено то, что на прод. Есть новый конфиг (head). Есть новый код.
1) выкатили config/head на staging
1.5) тут тоже неплохо проверить, что с новым конфигом старая прод-версия - которая пока еще на staging - внезапно не ломается
2) выкатили новый код на staging
3) протестировали, работает
4) меняем тег, выкладываем новый (уже -stable) конфиг на прод
5) деплоим новый код на прод
В каком месте разница, чото не пойму