CodeIgniter: разработка и производственная среда

в настоящее время я изучаю фреймворк PHP CodeIgniter. В настоящий момент я ищу среду разработки и производственную среду. Исходя из чисто C и JAVA-фона, я привык иметь все локально (с контролем версий), но поскольку у меня будет производственная сторона на веб-сайте, мне было интересно несколько разных вещей:

  1. лучше ли сохранить среду разработки локально?
  2. что было бы хорошо (и легко) способ внесения изменений на стороне DEV, чтобы получить их на стороне производства (предполагая, что DEV env является локальным)?
  3. можно ли (и если да, то как?) настроить CodeIgniter на среду DEV & PROD в одном и том же кодовом пространстве (скажем, на сервере, но с разными таблицами баз данных)?
  4. при использовании управления версиями в приложении, которое я бы создал в рамках, рекомендуется иметь только файлы, которые я создаю для своего приложения, или добавить всю структуру (к сохранить код в соответствии с версией фреймворка)?

Я ценю любые мысли или предложения у вас есть заранее.

спасибо!

6
codeigniter frameworks php version-control

2 ответов

Я не использую CodeIgniter, поэтому я не могу ответить на все ваши вопросы ; но, все же, здесь несколько указателей:

  • среда разработки : мне нравится, когда каждый разработчик имеет свою собственную среду ; и это, как правило, проще / быстрее, когда он на своей машине
    • тем не менее, если ваши машины разработки работают под управлением windows, и вы производственный сервер будет работать под управлением Linux, это может привести к некоторым проблемам (есть несколько различий между этими двумя, как чувствительность к регистру в именах файлов)
    • в этом случае, если у вас есть достаточно мощный компьютер, используя VMWare или VirtualBox для запуска минималистской виртуальной машины (С Linux + Apache+PHP+MySQL на нем ; источник кода тоже на нем, экспортируется через долю samba) может быть хорошим решением - это то, что я делаю несколько больше полугода, и это работает довольно хорошо
  • нажатие изменений от dev до prod :
    • одно решение войдите на рабочий сервер и выполните" обновление svn"; но мне это не очень нравится (если некоторые файлы были изменены непосредственно на производственном сервере-да, это иногда происходит), вы можете столкнуться с конфликтами и тому подобное ; и это определенно не весело, так как это может сломать сайт ^^
    • один solutioon мне нравится больше (требуется больше времени для развертывания, но если развернуть только, скажем, раз в неделю, это вполне нормально-и определенно более безопасно) использовать " svn экспорт " на одной из dev-машин создайте архив tar/zip/whatever и загрузите его на сервер prod. Затем вы извлекаете его в новый каталог ; и когда это сделано, вы меняете символическую ссылку, чтобы указать свой корневой каталог в этот новый каталог. Хорошая вещь: вы храните старые источники на рабочем сервере, и если есть катастрофическая проблема с тем, что вы развернули, у вас есть только одна символическая ссылка для изменения назад, чтобы вернуться к предыдущей версии-и это может когда-нибудь спасти день ^^
    • о, и, как sidenote : вы должны написать сценарий, чтобы сделать это автоматически для вас: он будет избегать возиться с шагом ine один день, делая это вручную (и поможет в тот день, когда парень, который всегда делает именно в праздники ^^ )
  • об использовании одного экземпляра источников для обеих сред : даже если вы планируете делать это только в рамках, Я не рекомендовал бы его :
    • это означает наличие dev и prod на той же машине, что плохо: что, если какой-то еще в разработке скрипт сойдет с ума и сделает плохие вещи ? Что делать, если один разработчик вводит некоторый kinf "rm-Rf" в неправильном каталоге ?
    • вы думали о разных таблицах базы данных (Я бы предпочел пойти с разными базами данных ; с разными пользователями, чтобы избежать любого плохого запроса на неправильной базе данных !), но это не единственное : насчет временных файлов ? кэш, например ?
    • Я действительно предпочитаю иметь полностью разделенные экземпляры ; даже если это означает, что у источников / фреймворка дважды на машине - и я бы действительно рекомендовал иметь две разные машины !
  • о наличии фреймворка на SVN :
    • чем больше вещей у вас есть на SVN, тем проще настроить новую среду разработки : в идеале, только один "svn checkout", и есть новая среда, готовая для нового разработчика, который только что присоединился к вашей команде ; в сочетании с виртуальной машиной, вы можете дать ему (скопировано с чужой машины), вы можете иметь developpers готовы работать на вашем проекте в течение нескольких десятков минут - что приятно; -)
    • тем не менее, наличие фреймворка в SVN-это Пита для его обновления : вы должны удалить его, заменить его, повторно зафиксировать ...
    • использование svn: externals (если вы можете -- зависит от вашей установки / вашей структуры), указывая на сам SVN-сервер фреймворка, может быть хорошо всегда быть в курсе (не обязательно указывать на HEAD ; использование тега или ветви может быть достаточно хорошо для вас).

надеюсь, что эти заметки помогут...
удачи !

7

1) я согласен с Паскалем Мартином-лучше всего для всех иметь свою собственную локальную среду разработки; таким образом, они могут играть, не наступая друг на друга. Это может означать, что вы хотите иметь некоторый тип тестовой или промежуточной среды, где члены команды (и заинтересованные стороны проекта) могут видеть интегрированный, незавершенный код.

2, 3) в целом, похоже, вы спрашиваете, как автоматизировать/развернуть в одной или нескольких средах. Есть несколько коммерческих и открытых исходные параметры для этого. Недавно мы начали использовать Capistrano (http://www.capify.org) и были очень довольны результатами. Это инструмент ruby и написан с использованием ruby-on-rails-isms. Если вы не знакомы с ними (я не был), вам нужно немного прочитать и погуглить, чтобы понять это. Однако в его основе лежит просто средство определения и запуска скриптов на удаленных серверах. Эти скрипты можно использовать в любом типе развертывания (например, мы используем PHP). Два большие вещи о Capistrano, которые адресуют ваш вопрос:

  • он знает о контроле версий; используете ли вы SVN, git или другие, он знает (несколько способов) извлечения последнего кода из репозитория и делает все необходимое для обновления удаленных серверов.
  • он делает транзакции, поэтому, если что-то пойдет не так с процессом сборки/развертывания, он может автоматически откатиться к предыдущей версии

4) это, вероятно, упрощенная модель; просто скачайте установку codeigniter и напишите свой код в каталоге applications/. Это может быть хлопот когда-нибудь, если вы хотите обновить CI, чтобы воспользоваться какой-то новой горячей функцией. Вы должны быть в состоянии обойти это, определив svn:внешнюю ссылку на codeigniter, чтобы при обновлении она также была свернута в ваш код. См.: http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html для получения дополнительной информации...

1