Как поэтапно развернуть приложение на том же сервере, что и производство?

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

Их приложение находится в папке под корневым каталогом. Назовем его «/app». Я хотел бы создать родственный каталог с именем «/appstaging», где я буду публиковать последний код. Препятствие заключается в том, что хостинг-провайдер позволяет вам устанавливать пути для пользовательских тегов и сопоставлений, но не для каждого приложения CF. Все существующие настройки указывают на каталог /app, поэтому, если мне нужно внести изменения в теги, CFC и т. д., я не могу протестировать их, не повлияв на работающее приложение. Я хочу, чтобы CF позволял мне устанавливать пути и сопоставления тегов для каждого приложения. Из того, что я читал, CF8 позволяет мне это сделать, но клиент использует CF7 (я настаиваю на том, чтобы они обновились как можно скорее). В то же время, есть ли способ обойти это, или нужно подождать плавного способа постановки изменений?

(В настоящее время я экспериментирую со способами определения того, на каком приложении я основан, используя GetCurrentTemplatePath() в application.cfm. Идея состоит в том, что любой код, который ссылается на другие файлы с помощью сопоставлений, будет использовать другое сопоставление. Я не проделал достаточно работы. там хотя бы узнать, получится ли все это.)

Любые идеи или вход приветствуются. Я должен отметить, что приложение и его среда разработки не очень «современны». Никаких фреймворков и таких вещей, как ant, не используется для сборки/развертывания. Бюджет клиента крайне ограничен, поэтому я не собираюсь продавать приложение оптом, но мне нужно найти дешевые способы внедрить какой-то процесс, чтобы все было в порядке.


person DaveBurns    schedule 20.09.2009    source источник
comment
Думаю, это в основном покрыто вашим предыдущим вопросом.   -  person Sergey Galashyn    schedule 20.09.2009
comment
@Sergii: я так не думаю на 100%. Если в существующем коде используются пользовательские теги, как указать CF путь для их загрузки, отличный от глобального пути тегов, который мне позволяет установить хостинг-провайдер? То, что вы предложили в моем другом вопросе, по сути то же самое, что и мой третий абзац выше. Интересно, есть ли какой-нибудь другой способ решить проблему, не распространяя это изменение по всей кодовой базе (она большая). Возможность устанавливать сопоставления для каждого приложения позволила бы мне это сделать. Похоже, переход на CF8 — лучшее решение. Интересно, есть ли другой способ четко разделить два приложения перед обновлением...   -  person DaveBurns    schedule 21.09.2009


Ответы (2)


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

person ale    schedule 21.09.2009
comment
Хотя второй размещенный аккаунт, упомянутый в другом месте, является отличной идеей, я выбрал что-то подобное вместо этого, главным образом потому, что обновление до CF8 произойдет в ближайшее время, и поэтому клиент не хочет беспокоиться о логистике второго аккаунта. Но также потому, что в качестве побочного эффекта загрузки CFC с явными путями (приложение предшествовало CFC) и других настроек, которые я сделал по пути (файлы конфигурации и т. д.), я могу иметь промежуточный каталог бок о бок с живое приложение. Там все еще есть совпадения с пользовательскими тегами, но я минимизирую их использование в приложении, чтобы это редко, если вообще когда-либо, было проблемой. - person DaveBurns; 15.10.2009

Это серьезное, но дурацкое предложение: используйте вторую размещенную учетную запись.

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

Кроме того, подсчитайте стоимость пересмотра базы кода, чтобы разрешить работу и постановку на одной учетной записи, и сравните ее со стоимостью второй учетной записи хостинга.

Помните, что вам не понадобится вторая учетная запись после того, как ваше настоящее обновление будет завершено.

person Antony    schedule 21.09.2009
comment
Присоединяюсь к этому. Это не должно стоить очень дорого и во всех смыслах и целях обеспечивает независимый промежуточный сервер. - person Jack Ryan; 21.09.2009
comment
Согласовано. Зачем тратить время на программирование, когда все решается вторым хостинг-аккаунтом? Даже если у клиента ограниченный бюджет, вторая учетная запись дешевого хостинга должна быть дешевле, чем разработка обходного пути. - person Eddie; 21.09.2009