Сервер Coldfusion 7 для нескольких приложений и пути CFC

У нас есть сервер Coldfusion, на котором размещено несколько приложений, все в собственной подпапке. Что-то типа:

  • / webrootfolder / applicationA
  • / webrootfolder / applicationB

Кроме того, на сервере разработки у нас есть копия данного приложения для каждого разработчика, каждая из которых является рабочей копией Subversion:

  • / webrootfolder / applicationA_dev1
  • / webrootfolder / applicationA_dev2
  • / webrootfolder / applicationA_dev3

Поскольку мы работаем с Coldfusion 7 (с большим сопротивлением обновлению), я застрял, так как хочу использовать CFC в пакетах. Вот различные проблемы, попытки решения и проблемы, связанные с ними:

  • Использование относительного имени компонента работает только при наличии одного пакета, что приведет к беспорядку компонентов в одной папке.
  • Использование подпакетов работает до тех пор, пока вы никогда не ссылаетесь на компоненты в родительских пакетах, что, кажется, легко происходит при расширении, создании экземпляра или использовании компонента в качестве типа cfargument.
  • Использование полного пути CFC, начиная с корня, не работает с нашими множественными копиями для каждого разработчика. ** Использование динамического пути с переменной было моим решением на данный момент ... пока я не понял, что он не работает с типом extends или cfargument ... ** Использование сопоставлений серверов не работает в разработке, как у нас псевдоним на копию разработчика. Я ожидаю, что код будет независимым от папки. ** Использование сопоставлений для конкретных приложений (определенных в Application.cfc) не работает, потому что CF7, а не CF8 +.
  • Моим предыдущим решением было создание локальных фиктивных копий необходимых CFC и включение содержимого фактических CFC (с относительными путями "../../"). Это работает, но иметь эти клоны повсюду так грязно. ** Совсем недавно я обнаружил, что это решение не всегда работает. Coldfusion сбивает с толку одноименные функции, явно включенные в различные CFC.
  • Использование серверов Coldfusion для разработки на каждом компьютере разработчика, позволяющее всегда указывать путь приложения /webrootfolder/applicationA (предложено Марком А. Крюгером). ** Основная проблема здесь заключалась в том, чтобы убедить компьютерную команду позволить нам установить это. Это может занять много времени, которого, боюсь, у меня нет. ** Могут быть другие проблемы с конфигурацией сети (возможно, с предоставлением доступа к БД, я не уверен), которые также должны будут пройти через сетевую команду и занять некоторое время, если это даже разрешено.

Один веб-сайт на приложение / папку - изменение корня

Я потратил время на изучение способа настройки веб-сайтов / приложений в IIS 6. После некоторых исследований я обнаружил, что можно создавать привязки точно так же, как я привык в Unix / Apache. На данный момент все приложения находятся в собственной подпапке корневого веб-каталога. Псевдонимы настраиваются, например, так, что "domain.com/appA" указывает на папку "/ webrootfolder / applicationA". Но это все еще один веб-сайт IIS с множеством подпутей. Таким образом, корень Coldfusion (для CFC и включает в себя) основан на корне этого веб-сайта (/ webrootfolder).

Я провел быстрый тест и мне удалось установить на сервере второй веб-сайт IIS, привязанный к порту 8080 (вместо 80 по умолчанию). Я указал на это непосредственно в / webrootfolder / applicationA / cfm (который на самом деле является корнем приложения). Таким образом, Coldfusion распознает эту папку как корень и при запуске экземпляра "Object" CFC ищет ее как /webrootfolder/applicationA/cfm/Object.cfc.

Это именно то, что у нас было на моей предыдущей работе, и это сработало очень хорошо. Тем не менее, это была небольшая компания, и я боюсь, что с этим решением могут возникнуть проблемы. В основном: как указать людям на этот сайт? Использование привязки портов не очень удобно для пользователя (наши пользователи не технические специалисты). Наличие определенного домена для каждого приложения звучит неплохо, но может быть дорогостоящим, особенно если задействован HTTPS (по крайней мере, я слышал). Поддомены могут быть другим решением, но, похоже, имеют аналогичные проблемы.

So...

Я что-нибудь пропустил? Я застрял на одном из "грязных" решений?

У меня есть доступ к административной панели Coldfusion и, возможно, к конфигурации IIS, хотя я, скорее всего, буду ограничен, если решение затронет пути или URL-адреса других приложений на сервере.


person leokhorn    schedule 13.11.2014    source источник


Ответы (1)


Однажды я спросил, как добраться до рыболовного озера у старого фермера из южного Иллинойса. Он на мгновение почесал в затылке, а затем сказал мне: «Сынок, отсюда тебе не добраться». :) Думаю, ты можешь оказаться в одной лодке, Лео.

Проблема не в упаковке, проблема в том, что ваш SDLC идет вразрез с лучшими практиками. Любой тип «dev-сервера» должен отражать производственную среду - то, с чем вы уже столкнулись со своим подходом. Более того, похоже, что каждый из ваших разработчиков имеет копию своего кода на сервере разработки. Это заставляет меня вспомнить 12 лет назад, когда мы с моим приятелем, только что открыв небольшой магазин разработчиков, разместили код на сервере разработки и разработали его напрямую - но такой подход нелегко поддерживать, и чем больше ваша команда, тем хуже становится, когда вы нашел.

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

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

person Mark A Kruger    schedule 13.11.2014
comment
Я слышал об этой концепции, но до сих пор не встречал ее на работе. Итак, каждый разработчик должен установить сервер Coldfusion на свой компьютер, а также сервер БД? Тогда у всех нас есть файловая структура и отдельная папка / приложение, и становится возможным использовать application.path.to.cfc, верно? - person leokhorn; 14.11.2014
comment
Сервер БД менее важен для работы локально. Если у вас очень мало изменений (или все изменения выполняются администратором баз данных), тогда будет достаточно одного сервера dev db или dev db (или даже отдельных dbs для каждого разработчика на одном сервере). У него нет тех же проблем с окружающей средой, как у кода, поскольку интерфейс (например, JDBC) установлен для всех. Я знаю людей, для которых каждый разработчик запускает локальную установку БД, но я знаю больше людей, которые запускают сервер БД разработчиков и делают его доступным. Однако вам НЕОБХОДИМО защищать сценарии DB DDL с помощью системы управления версиями - иначе это станет недокументированным слоем. - person Mark A Kruger; 14.11.2014
comment
Помимо моих комментариев о сервере БД, вы правы, лев. идентичные (или почти идентичные) среды для разработчиков, qa и продакшн. Так обычно и поступают команды - с Git или SVN (или другой системой управления версиями) в качестве основного источника ссылки. Свяжитесь со мной напрямую, если вы хотите воспользоваться нашей помощью в этом вопросе. - person Mark A Kruger; 14.11.2014