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

Question

Я сейчас нахожусь в процессе изучения PHP-фреймворка CodeIgniter. В настоящий момент я ищу среду DEV и среду PRODUCTION. Исходя из чисто C и JAVA, я привык иметь все локально (с контролем версий), но, поскольку у меня будет сторона ПРОИЗВОДСТВО на веб-сайте, мне было интересно несколько вещей:

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

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

Спасибо!

Answer 1

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

• Среда разработки: мне нравится, когда каждый разработчик имеет свою собственную среду; и вообще легче / быстрее, когда он на его машине
  • Тем не менее, если ваши машины разработки работают под управлением Windows, а ваш рабочий сервер будет работать под управлением Linux, это может привести к некоторым проблемам (между ними есть несколько отличий, например, чувствительность к регистру в именах файлов)
  • в этом случае, при условии, что у вас достаточно мощный компьютер, использующий VMWare или VirtualBox для запуска минималистической виртуальной машины (с Linux + Apache + PHP + MySQL на ней; источник кода тоже на нем, экспортируется через доля самбы) может быть хорошим решением - это то, чем я занимаюсь немногим более полугода, и оно работает довольно хорошо
• Перенос изменений из dev в prod:
  • одно из решений - войти на рабочий сервер и выполнить «svn update»; но мне не очень нравится (если некоторые файлы были изменены непосредственно на рабочем сервере - да, такое иногда случается) , вы можете столкнуться с конфликтами и т. п .; и это определенно не весело, так как это может взломать сайт ^^
  • одно решение мне нравится больше (развертывание занимает больше времени, но если вы развертываете только, скажем, раз в неделю, это вполне нормально - и, безусловно, более безопасно) - использовать "svn export" на одном из машин dev создайте архив tar / zip / what и загрузите его на сервер prod. Затем вы извлекаете его в новый каталог; и когда это будет сделано, вы измените символическую ссылку, чтобы указать корневой каталог на этот новый каталог. Хорошая вещь: вы сохраняете старые источники на производственном сервере, и если есть катастрофическая проблема с тем, что вы развернули, у вас есть только одна символическая ссылка, чтобы вернуться к предыдущей версии - и это может когда-нибудь спасти день ^ ^
  • о, и, как замечание: вы должны написать скрипт, который сделает это автоматически для вас: это позволит избежать путаницы с одним шагом, когда вы будете делать это вручную (и поможет в тот день, когда парень это всегда происходит в праздничные дни ^^)
• Об использовании одного экземпляра источников для обеих сред: даже если вы планируете делать это только для платформы, я бы не рекомендовал это:
  • это значит иметь dev и prod на одной и той же машине, что плохо: что если кто-то еще в разработке сценарий сходит с ума и делает плохие вещи? Что, если один разработчик наберет какой-нибудь код "rm -Rf" в неправильном каталоге?
  • вы думали о разных таблицах баз данных (я бы предпочел использовать разные базы данных; с разными пользователями, чтобы никто не делал неправильные запросы к неправильной базе данных!) , но это не единственное: как насчет временных файлов? кеш, например?
  • Я бы действительно предпочел иметь полностью разделенные экземпляры; даже если это означает, что на машине должны быть два источника / фреймворка - и я бы очень рекомендовал иметь две разные машины!
• О наличии фреймворка в SVN:
  • Чем больше вещей у вас есть в SVN, тем проще будет настроить новую среду разработки: в идеале, всего одна "svn checkout", и есть новая среда, готовая для нового разработчика, который только что присоединился к вашей команде; в сочетании с машиной Virtal вы можете дать ему (скопировано с чужого компьютера) , у вас могут быть разработчики, готовые работать над вашим проектом через пару десятков минут - что приятно; -)
  • Тем не менее, наличие Framework в SVN является PITA для его обновления: вы должны удалить его, заменить его, повторно зафиксировать его, ...
  • Использование svn: externals (если вы можете - зависит от вашей настройки / вашей среды) , указывая на сам сервер SVN платформы, может быть полезно всегда быть в курсе событий (не t обязательно указывает на HEAD; вам может быть достаточно использовать тег или ветку).

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

Answer 2

1) Я согласен с Паскалем МАРТИНОМ - лучше всего иметь собственную среду разработки; таким образом они могут играть, не наступая друг другу на пальцы ног. Таким образом, это может означать, что вы хотите иметь какой-то тип тестовой или промежуточной среды, в которой члены команды (и заинтересованные стороны проекта) могут видеть интегрированный, выполняющийся код.

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

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

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