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

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

• Development environment : I like when each developper has it's own environment ; and it's generally easier / faster when it's on his machine
  • still, if your development machines are running windows, and you production server will be running Linux, it could bring some problems (there are a few differences between those two, like case-sensitivity in files names)
  • в этом случае, при условии, что у вас есть достаточно мощный компьютер, используйте VMWare или VirtualBox для запуска минималистичной виртуальной машины (с Linux+Apache+PHP+MySQL на ней; исходный код тоже находится на ней, экспортирован через общий ресурс samba ) может быть хорошим решением -- это то, чем я занимаюсь чуть больше полугода, и это работает очень хорошо
• Pushing changes from dev to prod :
  • one solution is to log on the production server and do an "svn update" ; but I don't really like that (if some files have been modified directly on the production server -- yes, this sometimes happens), you may encounter conflicts and the like ; and that's definitly not fun at all, as it may break the site ^^
  • одно решение мне нравится больше (требует больше времени для развертывания, но если вы развертываете только, скажем, раз в неделю, это вполне нормально -- и определенно более безопасно) использовать "svn export" на одном на машинах разработки, создайте архив tar/zip/независимо и загрузите его на рабочий сервер. Затем вы извлекаете его в НОВЫЙ каталог; и когда это будет сделано, вы измените символическую ссылку, чтобы указать ваш корневой каталог на этот новый каталог. Хорошая вещь: вы храните старые исходные коды на рабочем сервере, и если возникнет катастрофическая проблема с тем, что вы развернули, у вас есть только одна символическая ссылка, которую можно изменить обратно, чтобы вернуться к предыдущей версии — и это может иногда спасти положение ^ ^
  • о, и, как побочное примечание: вы должны написать скрипт, который сделает это автоматически для вас: это позволит избежать возни с ine step однажды, когда вы будете делать это вручную (и поможет в тот день, когда парень, который всегда делает то есть в праздники ^^ )
• About using one instance of the sources for both environments : even if you plan on doing this only for the framework, I wouldn't recommend it :
  • it means having dev and prod on the same machine, which is bad : what if some still in development script becomes mad and does bad things ? What if one developpers types some kinf of "rm -Rf" in the wrong directory ?
  • вы думали о разных таблицах баз данных (я бы предпочел работать с разными базами данных; с разными пользователями, чтобы никто не делал неверных запросов к неправильной базе данных!), но это не единственное: как насчет временные файлы ? кэш, например?
  • Я бы предпочел иметь полностью отдельные экземпляры; даже если это означает, что исходники/фреймворк должны быть дважды на машине - и я действительно очень рекомендую иметь две разные машины!
• About having the framework on SVN :
  • The more things you have on SVN, the easiest it is to get a new development environment set up : ideally, just one "svn checkout", and there's a new environment ready for the new developper who just joined your team ; coupled with a Virtal Machine you can give him (copied from another's machine), you can have developpers ready to work on your project in a couple of dozen minutes -- which is nice ;-)
  • Тем не менее, наличие Framework в SVN - это PITA для его обновления: вы должны удалить его, заменить, повторно зафиксировать,...
  • Использование svn:externals (если возможно -- зависит от вашей настройки/вашей среды), указывающего на сам сервер SVN среды, может быть полезным, чтобы всегда быть в курсе последних событий (не обязательно укажите на HEAD ; использование тега или ветки может быть достаточно для вас).

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

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

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

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

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