Подтвердить что ты не робот

Советы по развертыванию кода PHP

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

Теперь я хотел бы начать новый проект и улучшить свой рабочий процесс. В идеале я имел в виду следующее:

  • У вас есть одна или несколько локальных сред разработчиков
  • Разработка и тестирование на локальных машинах.
  • Использовать SVN (или Git) в качестве репозитория кода
  • Используйте инструмент сборки для настройки новых сред (dev, промежуточная или производственная) и развертывания кода

Поскольку я не очень хорошо разбираюсь в этом процессе, я ищу предложения о том, как наилучшим образом настроить эту идею и использовать инструменты, особенно когда дело доходит до инструментов сборки. Я смотрел в Ant и Phing (возможно, сделал), но я так новичок в этом, что мне очень хотелось бы получить некоторые рекомендации. Есть ли хорошие учебники или книги о развертывании PHP, особенно для начинающих? Меня особенно интересуют следующие темы:

  • Развертывание на разных типах серверов с различными настройками (например, dev использует разные пароли db, db, отчеты об ошибках PHP, чем производство или этап).
  • Развертывание, которое автоматически вытаскивает код из SVN.
  • Развертывание, которое временно устанавливает страницу "Обслуживание" для рабочей среды.
  • Как только я освою вышеизложенное, возможно, даже сделаю некоторое тестирование в процессе сборки.

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

4b9b3361

Ответ 1

Я бы предложил сделать стратегию развертывания тестирования готовой к установке - script - так как вам все равно понадобится одна из них.

Несколько советов, которые могут показаться очевидными для некоторых, но заслуживают внимания:

  • Ваш конфигурационный файл, сохраненный в вашем VCS, должен быть шаблоном и должен быть назван иначе, чем файл, который в конечном итоге будет содержать фактические настройки. Например. config-dist.php или config-sample.conf или sample/config-mysql.php или что-то в этом роде. В противном случае вы случайно проверите файл конфигурации сервера по вашему шаблону.
  • Для развертывания PHP предвидите, что некоторые пользователи не смогут запускать серверные скрипты с помощью любого механизма, кроме самого веб-сервера. Установщик на основе PHP почти не подлежит обсуждению.
  • Вы должны включить удобный для пользователя механизм обновления, и для этого wordpress - отличный пример проекта для эмулирования. PHP script может (a) загрузить последнюю сборку, (b) использовать функции ftp для обновления ваших файлов приложений и (c) выполнить обновление script, которое вносит соответствующие изменения в базу данных и т.д.
  • Ради всего этого не делай, как [отредактировано], и заставляйте пользователей загружать и устанавливать отдельные исправления для каждого точечного релиза. Попросите их загрузить последнюю (окончательную) версию, которая содержит все обновления на сегодняшний день, и последовательно применяет правильные функции ALTER TABLE.

Независимо от того, развертываются ли файлы через SVN или через FTP, механизм установки и обновления должен быть одинаковым: получить последние файлы, запустить обновление script. Обновитель использует версию, указанную в PHP скрипт, и версию, указанную в БД, и использует эти знания для правильного применения соответствующих патчей DB. Что касается создания этих патчей, здесь есть другие вопросы, на которые вы можете обратиться за дополнительной информацией.

Что касается страницы "Обслуживание", просто используйте описанный выше трюк версии, чтобы вызвать его (сравните версию в БД с версией в PHP-коде). Также полезно иметь возможность отмечать сайт как "вниз" для публики, но сделать его видимым для администраторов (например, Joomla), которые вы можете инициировать с помощью флагов базы данных или файловой системы.

Что касается автоматического вытягивания кода из SVN, я бы сказал, что вам лучше с помощью cron script или с помощью триггеров фиксации, чем для работы в вашем приложении, поскольку это не относится к конечным пользователям.

Ответ 2

Это не совсем часть вашего вопроса, но это актуально:

Если вы собираетесь распространять код, предназначенный для широкой аудитории, я бы посоветовал вам приступить к созданию и распространению пакетов PHAR, подписанных OpenSSL. Вы можете распространять их по HTTP без проблем, и поскольку они являются подписанными OpenSSL, вы также уменьшаете риск нападений "человек в центре" и защищаете конечных пользователей/клиентов/клиентов от кого-то, вводящего код, если вы хотите настроить автоматическое или однократное обновление.

Вот набор инструментов, которые я внес в прошлом, которые отлично подходят для этого, но вам понадобится PHP 5.3, или вам понадобится PHP 5.2 с PHAR, установленным через PECL. https://github.com/koto/phar-util

Что касается тестирования, то PHPUnit является стандартом de facto.

Ответ 3

Если вы заинтересованы в использовании Git, вы должны проверить эту систему сборки из CodeMeme. Из того, что вы описали, это звучит так, как будто это было бы хорошо. Вы можете добавить его в любой проект в качестве подмодуля, и с помощью прилагаемого кода вы можете адаптировать конструкцию script, которая будет развертываться на разных серверах в нескольких средах. Он использует Git для создания кода для развертывания, но, к сожалению, SVN не поддерживается.

https://github.com/CodeMeme/Phingistrano