CodeIgniter: среда разработки и продуктивная среда
Я предполагаю, что Вы могли хотеть протестировать базовую функциональность абстрактного класса... Но Вы, вероятно, были бы лучше всего выключены путем расширения класса, не переопределяя методов и сделали бы насмешку минимального усилия за абстрактные методы.
2 ответа
Я не использую CodeIgniter, поэтому я не смогу ответить на все ваши вопросы; но, тем не менее, вот несколько указателей:
- Среда разработки: мне нравится, когда у каждого разработчика есть собственная среда; и это'
- тем не менее, если ваши машины разработки работают под управлением Windows, а ваш рабочий сервер будет работать под управлением Linux, это может вызвать некоторые проблемы (между ними есть некоторые различия, например, чувствительность к регистру в именах файлов)
- в этом случае, при условии, что у вас достаточно мощный компьютер, использующий VMWare или VirtualBox для запуска минималистичной виртуальной машины (с Linux + Apache + PHP + MySQL на нем; исходный код также находится на нем, экспортированный через общий ресурс samba) может быть хорошим решением - это то, чем я занимаюсь несколько более полугода, и это работает довольно хорошо
- Перенос изменений от разработчика к продукту:
- Одно из решений - войти на рабочий сервер и выполнить «svn update»; но мне это не очень нравится (если некоторые файлы были изменены непосредственно на производственном сервере - да, такое иногда случается) , вы можете столкнуться с конфликтами и т.п. и это определенно совсем не весело, так как это может сломать сайт ^^
- одно решение, которое мне нравится больше (развертывание занимает больше времени, но если вы развертываете только, скажем, один раз в неделю, это вполне нормально - - и определенно более безопасным) - использовать "svn export" на одной из машин разработчика, создать tar / zip / любой архив и загрузить его на prod-сервер. Затем вы распаковываете его в НОВЫЙ каталог; и когда это будет сделано, вы измените символическую ссылку, чтобы указать ваш корневой каталог на этот новый каталог. Хорошая вещь:
- это означает наличие dev и prod на одной машине, что плохо: что, если какой-то еще в разработке сценарий сойдет с ума и сделает плохие вещи? Что, если один разработчик наберет какой-нибудь вид "rm -Rf" в неправильном каталоге?
- вы подумали о разных таблицах баз данных (я бы предпочел использовать разные базы данных; с разными пользователями, чтобы никто не делал ничего плохого запрос не на ту базу данных!) , но это не единственное: как насчет временных файлов? кеш, например?
- Я действительно предпочел бы иметь полностью разделенные экземпляры; даже если это означает, что исходники / фреймворк должны быть дважды установлены на машине - и я бы действительно рекомендовал иметь две разные машины!
- О наличии фреймворка на SVN:
- Чем больше у вас вещей в SVN, тем проще будет настроить новую среду разработки: в идеале, всего одну «svn checkout», и есть новая среда, готовая для нового разработчика, который только что присоединился к вашей команде; вместе с Virtal Machine вы можете дать ему (скопировано с чужой машины) , вы можете подготовить разработчиков для работы над вашим проектом за пару десятков минут - что приятно; -)
- Тем не менее , наличие Framework в SVN - это PITA для его обновления: вы должны удалить его, заменить, повторно зафиксировать, ...
- Использование svn: externals (если можете - зависит от ваших настроек / ваш фреймворк) , указывающий на сам сервер SVN фреймворка, может быть хорошей вещью, чтобы всегда быть в курсе (не обязательно указывать на HEAD; использование тега или ветки может быть достаточно для вас).
Удачи!
1) Я согласен с Паскалем МАРТИНОМ - лучше для каждого иметь свою локальную среду разработки; так они смогут играть, не наступая друг другу на пятки. Тогда это может означать, что вы хотите иметь какой-то тип тестовой или промежуточной среды, в которой члены команды (и заинтересованные стороны проекта) могут видеть интегрированный, незавершенный код.
2, 3) В общем, это похоже на вас спрашивают, как автоматизировать / развернуть в одной или нескольких средах. Для этого есть несколько коммерческих вариантов и вариантов с открытым исходным кодом. Недавно мы начали использовать Capistrano ( http://www.capify.org ) и остались очень довольны результатами. Это рубиновый инструмент, написанный с использованием рубинов-на-рельсах. Если вы не знакомы с ними (я не был), потребуется немного прочитать и погуглить, чтобы понять это. Однако, по сути, это просто средство для определения и запуска сценариев на удаленных серверах. Эти сценарии можно использовать в любом типе развертывания (например, мы используем PHP). Две замечательные особенности Capistrano, которые отвечают на ваш вопрос:
- Он знает о контроле версий; независимо от того, используете ли вы SVN, git или другие, он знает (несколькими способами) получить последний код из репозитория и сделать все необходимое для обновления удаленного сервера (ов).
- Он выполняет транзакции, поэтому, если что-то пойдет не так в процессе сборки / развертывания он может автоматически откатиться к предыдущей версии
4) Это, вероятно, упрощенная модель; просто скачайте установку codeigniter и напишите свой код в каталоге applications /. Когда-нибудь это может стать проблемой, если вы захотите обновить CI, чтобы воспользоваться какой-то новой горячей функцией. Вы можете обойти это, определив svn: внешняя ссылка на codeigniter, чтобы при обновлении она также включалась в ваш код. См .: http://svnbook.red-bean.com/nightly/en/svn.advanced.externals.html для получения дополнительной информации ...