Как Вы реализуете “одну сборку шага” для проекта ЛАМПЫ?

Я не думаю, что для этого есть простой ответ из поваренной книги, потому что это очень сильно зависит на вашем окружении. Что бы вы ни придумали, я настоятельно рекомендую подход на основе сценариев, при котором сценарии развертывания сами находятся в системе контроля версий. Эти сценарии также обеспечат лучшую интеграцию с решениями для сборки (см. Ниже).

Самым простым из таких сценариев для запуска в производственной среде будет просто команда для получения последней версии (или получения конкретной версии) из системы управления версиями.

Следующая задача - развертывание базы данных. Решение, которое мне больше всего нравится для проектов малого и среднего размера, - это поддерживать таблицу версий схемы в каждой базе данных и иметь все сценарии DDL и обновления данных в системе контроля версий (включая источники данных, которые они используют в сжатых архивах). Сценарии пронумерованы последовательно (начиная с 000001 ..., 000002 ... и т. Д.), И сценарий развертывания, который я запускаю, просто сначала создает резервную копию существующей базы данных, затем получает последний запускаемый сценарий базы данных из таблицы версий схемы, а затем запускается. любые новые скрипты базы данных, найденные в системе управления версиями, в правильном порядке, соответственно обновляя таблицу версий схемы.

Этот подход позволяет мне довольно быстро перестроить базу данных с нуля.

Два подхода, взятые вместе, позволяют быстро развернуть вашу кодовую базу на нескольких различных промежуточных машинах, в вашей среде QA, бета-версии и т. Д.

Для немного более сложных сценариев, вам следует запустить сервер непрерывной интеграции, например Kieveli et. al. предложенный, который по существу регулярно «перестраивает» все ваше развертывание и, следовательно, содержит сценарии, которые делают именно то, что вы бы запускали «вручную» выше.

Развертывание базы данных также можно сделать более сложным, создав сценарий отката для каждого сценария базы данных. Затем вы должны написать небольшое приложение-контроллер для их обработки. Существует несколько решений OSS для такого рода вещей, и одно из них может соответствовать вашим потребностям.

НО,

We do. We use a product called Anthill Pro to do all of our builds and deployments. It has a workflow process which set up to check out the files, do the builds, run the unit tests and then deploy the code to the servers. You can use it to deploy just about anything as the process can run command line programs etc.

Лучшим инструментом сборки для проекта PHP, вероятно, является Phing , который очень похож на Ant, но написан на PHP. Он содержит все необходимое для чего-то вроде этого, например, для получения данных из репозитория svn.

Выполнив одноэтапную сборку, вы можете легко превратить ее в непрерывные сборки.

У нас есть все наши завершенные сборки, отмеченные номером изменения, которым они были построен на центральном сервере. Когда что-то фиксируется (мы используем Perforce, но это будет работать для SVN), cronjob в одном из наших блоков сборки замечает, что есть более свежие изменения, чем сборка, запускает http-запрос для загрузки исходного дерева и начинает сборку (в основном с GMake). Непрерывная сборка всего за несколько простых шагов :)

После этого остается короткий шаг к автоматическому запуску всей вашей автоматизации тестирования. Полностью собранный и протестированный (возможно, развернутый!) Код после каждой фиксации.

Для языка сценариев обычные советы, такие как использование варианта ant или CruiseControl, не имеют большого значения, потому что вам не нужно ничего компилировать.

Давайте придерживаться базы данных. Когда дело доходит до непрерывной интеграции, три важных момента - это автоматизация, автоматизация и автоматизация. Это означает, что у вас должно быть все, от создания пустой базы данных, импорта из внешних данных и обновления до новой версии, написанное и готовое к запуску с использованием некоторых сценариев. Хорошим примером этого может быть что-то вроде MediaWiki, которое позволяет вам настраивать и устанавливать с помощью самого php. Я бы порекомендовал запустить сервер сборки для развертывания новой базы данных в течение дня, запускать модульные тесты и отправлять электронные письма в случае сбоя.

"make" on UNIX (and Windows) is your friend. It's got a learning curve though, but it's worth it. You can have make update the source, compile, test, etc, etc.

Я думаю, что вам нужен один сценарий, чтобы собрать все воедино, получить все файлы \ ресурсы из системы управления версиями и выполнить все шаги для создания конечного «продукта»

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

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

http://www.kinook.com/VBP/

http://www.finalbuilder.com/