Настройка сервера разработки

Два момента моей ежедневной работы:

• XAMPP – это универсальный магазин для установки стека Apache / mySQL / PHP в Windows. Я разрабатываю с ним и развертываю на машинах Linux, никаких проблем.

• Если вы хотите настроить среду Linux на домашнем сервере или виртуальной машине, я задал вопрос, который может вас заинтересовать: предварительно установленный Linux для веб-разработчиков?

Лучше ли использовать другой сервер через одну и ту же хостинговую компанию и спросить их, что и у разработчиков, и у живых есть те же самые настройки?

Если вы можете позволить себе второй сервер, это может быть наилучшим способом. С другой стороны, локальная машина, которую вы могли бы обновить и возиться по своему усмотрению, и все это на долю долгосрочной стоимости второго арендованного сервера. Если сомневаюсь, я бы пошел на местную машину.

Не забывайте, что PHP – очень портативный язык. Если вы не используете какие-либо конкретные инструменты командной строки или полностью экзотические расширения, это делает работу с PHP-приложением в Linux, и даже в Windows речь идет о некоторых настройках и деталях, но это не имеет большого значения.

Кроме того, какой лучший рабочий поток для проверки файлов с «живого сервера» работает над ними на «сервере разработки», а затем проверить их обратно на живой сервер?

В этой области много и много мнений и практик. Для меня лично следующий рабочий процесс оказался идеальным везде, где я его использовал – я все еще в процессе реализации этого сам во всех проектах и ​​для всех клиентов.

1. Редактировать файлы локально в среде IDE

2. Загрузка на сервер разработки через встроенную функцию FTP IDE

3. Тест на сервере разработки

4. Как только функция протестирована и работает на сервере разработки (т.е. она «завершена»), проверьте весь пакет в Subversion (или другой) репозиторий

5. На реальном сервере создайте скрипт проверки последней версии из репозитория, загрузите его в каталог с номером ревизии, а когда закончите, измените символическую ссылку, указывающую на предыдущую ревизию на последнюю.

Таким образом, каждое изменение, которое вы делаете в живой среде, регистрируется в системе управления версиями, и возврат к предыдущей ревизии является вопросом, если секунды. Для меня это было огромным облегчением по сравнению с работой с чистым FTP везде.

Возможно также интересный вопрос: настройка цикла развертывания / сборки / CI для проектов PHP

Вы можете проверить все настройки производственного сервера с помощью phpinfo () и скопировать их в среду разработки, не нужно, чтобы они находились на одном и том же провайдере.

Обычно я беру код в исходный элемент управления и проверяю в рабочей среде, скрывая всю информацию о репозитории через .htaccess, например, здесь .

Другой (менее рекомендуемый) вариант состоит в том, чтобы просто иметь ваш основной источник в машине разработки, и как только он будет готов к работе с FTP, существуют различные бесплатные инструменты, которые будут загружать только измененные файлы.

Что касается серверной части, у вас есть несколько возможностей. Вы можете использовать vHosts, когда у вас есть Apache, с двумя разными DocumentRoots: один для живой версии и один для разработки. Или вы можете создать среду разработки на своей локальной машине, а затем жить (+ постановка) на выделенном сервере / веб-пространстве вообще.

В нашем текущем проекте у нас есть трехуровневая система:

развитие, постановка и жизнь. Стадии и живые существа практически одинаковы, так что я могу устранить любые проблемы при выходе из dev на стадию. Это дает мне еще один уровень безопасности, прежде чем выкатиться, чтобы жить, и в конечном итоге заметил, что что-то пошло не так.

Учитывая рабочий процесс развертывания, вы должны создать конфигурацию приложения, в которой вы можете определить несколько прикладных сред (разработка и производство), которые автоматически выбирают свою среду на основе URL-адресов, определенных переменных среды или чего-то еще. Таким образом, в Zend Framework, например, эта управляемая конфигурация встроена в ваши приложения. В файле config.ini у вас есть шаблон, который выглядит так:

[production] [staging : production] [testing : production] [development : production] 

Там вы можете определить различные варианты, скажем, соединения с базой данных, т.е.

Поэтому, когда вы проверяете свои изменения на dev-машине на подрывную деятельность и выполняете развертывание в своей живой системе, вам не нужно менять конфигурацию. Он должен просто работать.

Что касается рабочего процесса, обычно это происходит для небольших сайтов. Однако, в зависимости от размера проекта, может быть хорошей идеей использовать контроль версий, например Git или Subversion.

Вам не нужно никуда идти, чтобы попросить хостинговую компанию настроить для вас две одинаковые среды хостинга. В большинстве случаев у них есть обновленные версии php, mysql и apache. Я разрабатываю на Linux-машине, у которой уже установлен стек лампы, поэтому мой рабочий процесс довольно бесшовна, и я использую svn с крючками после коммита для загрузки на живой сервер. Если вас беспокоит несовместимость между сервером «dev» и сервером хостинга, проще всего сделать файл phpinfo,

 <?php phpinfo(); ?> 

и убедитесь, что ваш сервер хостинга не запрещает каких-либо специальных функций, которые вы используете на своем dev-сервере (и это довольно редко, что хостинговая компания блокирует жизненные вещи, и если они это сделают, вы можете легко отправить поддержку по электронной почте и в 99% случаев, когда они поможет вам в том, чтобы предоставить вам какие-либо сведения, которые вам нужны.Но в том, что касается настройки среды разработки, я бы спустился по пути захвата виртуального бокса и установил ubuntu, найду учебник для создания ubuntu веб-сервера (серьезно только несколько apt- получите команды), и вы будете курить газом!