Как лучше всего настроить мою среду разработки PHP (LAMP), чтобы у меня были серверы разработки, создания и производства. Один – «щелчок» развертывания на любой из них, а также откат одного клика на любую ревизию. Откат также должен откатить схему базы данных и данные, как это было, когда этот исходный код был текущим.
Прямо сейчас я сделал все это (кроме возможности отката DB) для одного приложения, используя сценарии оболочки. Мне любопытно узнать, как настроены среды других, а также, если есть какие-то общие инструменты или лучшие практики, которые следует соблюдать в отношении макета.
Итак, как вы это делаете? Какие существующие инструменты вы используете?
Благодаря!
ОБНОВЛЕНИЕ: Просто уточнить, поскольку есть некоторая путаница в отношении того, что меня интересует.
Я действительно хочу, чтобы люди перекликались с тем, как настроена их среда.
Если вы запустите проект PHP и у вас есть ваша схема DB в контроле версий, как вы это делаете? Какие инструменты вы используете? Являются ли они собственными силами или мы все можем найти их в Интернете где-нибудь?
Если вы запускаете проект PHP и выполняете автоматическое тестирование при совершении (и / или ночной), как вы это делаете? Какую систему управления версиями вы используете? Используете ли вы SVN и запускаете свои тесты на крючках после фиксации?
Если вы запускаете проект PHP с несколькими серверами-разработчиками, промежуточным сервером и производственным сервером (-ами), как их организовать и как вы развертываете?
То, что я надеюсь выйти из этого, – это хорошая идея, как другие склеивают все вместе.
Наша производственная среда включает в себя следующее:
Наша среда разработки – это единый сервер, на котором работают как базы данных, так и httpd, с конфигурацией мы имеем разные рабочие области для каждой настройки, а наш VC – подрывная деятельность. Проведение тоже довольно просто – оно работает на одном из интерфейсов.
Изменения в базе данных
Первоначально мы потратили много времени на дизайн базы данных и, похоже, действительно окупились. Через пять месяцев мы ничего не изменили. Большинство изменений, которые мы развертываем, находятся на интерфейсе. Теперь, до сих пор мы запускаем все изменения в базе данных вручную, и я всегда писал небольшой скрипт для возврата.
Если бы у меня было больше таких, я бы использовал Доктрину и Миграции . У меня никогда не было возможности использовать их в производстве, но я уже много играл с ними, и они кажутся очень мощными.
развертывание
Поэтому всякий раз, когда мы развертываем новую версию, мы создаем тег кода, который мы проверяем на этапе, затем просматриваем пару списков проверок и т. Д., А затем мы разворачиваем код на производственных фронтах. Для выполнения всего развертывания у меня есть пара задач в Capistrano .
Проверьте этот пример capfile :
role :www, "web01", "web02", "web03" role :web, "web01", "web02", "web03", "web04" role :db, "db01", "db02" desc "Deploy sites" task :deploy, :roles => :www do run "cd /usr/www/website && sudo svn --username=deploy --password=foo update" end
Capistrano также позволяет запускать любую другую команду без определения задачи:
cap invoke COMMAND="uptime" ROLES=web
(Требуется настройка роли «Интернет». См. Пример выше.)
Стиль кодирования и документация
Мы в значительной степени придерживаемся стандарта кодирования PEAR , который мы проверяем с помощью PHP_CodeSniffer (phpcs). Когда я говорю довольно много, я имею в виду, что я искал принюшки и добавил несколько исключений из моего собственного удовольствия.
Помимо стиля кодирования, phpcs также проверяет встроенную документацию. В конце документа эта документация создается phpDocumentor .
CI
У меня есть оба этих инструментария на нашем CI-сервере ( непрерывная интеграция ), который является phpUnderControl с использованием вышеперечисленных и CruiseControl, phpUnit , Xdebug (пара метрик кода …) и т. Д.
модульное тестирование – это то, чего мы в настоящее время не хватает. Но сейчас мы делаем то, что с каждой ошибкой, которую мы находим в нашем синтаксическом анализаторе (мы анализируем текст в определенных форматах), мы пишем тест, чтобы убедиться, что он не возвращается. Я также написал некоторые базовые тесты, чтобы проверить URL-маршрутизацию и внутренний XMLRPC API, но это действительно подлежит улучшению. Мы также используем тесты типа phpUnit и phpt .
CI-сервер создает новую версию пару раз в день, генерирует графики, документы и всевозможные отчеты.
Помимо всех упомянутых инструментов, мы также используем Google Apps (в основном для электронной почты) и сохраняем вики Google Sites со всей другой документацией. Например, процедура развертывания, списки проверки качества и т. Д.
Я заметил, что это не сильно разоблачает. Это тоже то, что меня интересует. Знаете ли вы о Финге ? Ты это пробовал?
Андрей
Вот хорошее руководство по автоматизации развертывания приложений PHP с Capistrano.
Для изменений базы данных у нас есть каталог в VCS:
+ dbchanges |_ 01_database |_ 02_table |_ 03_data |_ 04_constraints |_ 05_functions |_ 06_triggers |_ 07_indexes
Когда вы вносите изменения в базу данных, вы помещаете файл .sql в правильный каталог и запускаете скрипт интеграции, который выполняется через эти каталоги, и импортируйте каждое изменение в db.
Файлы sql должны начинаться с комментария, который отображается пользователю, когда скрипты интеграции импортируют изменение, описывая, что он делает. Он регистрирует каждое импортированное имя файла sql в файле, поэтому при следующем запуске скрипта он не будет применять одно и то же изменение снова.
Таким образом, все разработчики могут просто запустить скрипт, чтобы обновить db.
@andrew: Я пробовал Phing и закончил с phpUnderControl. Проблема с Phing заключается в том, что для управления охватом кода он должен фактически включать в себя все файлы в вашем проекте, которые для нашего проекта просто этого не делают. Подход CruiseControl работал лучше для нас. Дайте им попробовать, их легко настроить – тяжелая работа – построить тесты ….