Настройка эффективного и эффективного процесса разработки

Question

Я запускаю среду разработки (PHP/MySQL) для моего запуска. Мы используем три набора серверов:

LIVE - на серверах, которые обеспечивают фактическое применению TEST - обеспечение версии тестирования, прежде чем она на самом деле выпустила DEV - сервера развития

Сервера разработки работают SVN с каждым разработчиком проверяя их местную копию. В конце каждого дня проверяются исправления, а затем мы используем Hudson для автоматизации процесса сборки, а затем передаем его TEST. Затем мы проверяем, что приложение все еще функционирует правильно, используя тестер, а затем, если все в порядке, переместите его в LIVE. Я доволен этим процессом, но у меня есть два вопроса:

• Как бы вы рекомендовать нас сделать локальное тестирование - как каждый разработчик добавляет новые страницы или изменения функциональности я хочу, чтобы они были в состоянии проверить, что они делают , Вы бы просто установили локальный Apache и локальную базу данных и проверили их локально на своей собственной машине?

• Как вы порекомендовали бы использовать изменения слоя данных?

• Есть ли что-нибудь еще, что вы бы порекомендовали, чтобы сделать наш процесс разработки максимально простым и эффективным?

Заранее спасибо

Answer 1

+1 к каждому разработчику работает ее собственные настройки, в комплекте с Apache и базами данных.

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

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

Answer 2

Любой, кто занимается разработкой, ДОЛЖЕН иметь свою собственную локальную среду. Я использую Mac, поэтому я запускаю MAMP, чтобы у меня была локальная локальная среда LAMP и не зависела от какой-либо другой среды. Это также позволит мне узнать, что никто другой не меняет/не работает на тех же компонентах, которые я есть, и устраняет любую возможную путаницу. Если вы пользователь Windows, также легко установить локальные версии стека LAMP, такие как XAMP и т. Д. Если вы используете Linux в качестве рабочего стола, вы, скорее всего, уже знаете, как установить LAMP для вкуса Linux, вы бегут.

Версия схемы базы данных - отличная идея. Это то, что мы используем. Помимо схемы управления версиями, мы добавляем таблицу схемы в схему и обновляем ее, чтобы мы могли быстро определить, какая версия находится в производстве/qa/dev, когда нам нужно сравнивать.

Что касается изменений уровня данных, я бы рекомендовал две вещи.

1. Всегда создавайте свой путь миграции вперед и назад. Это означает, что когда у вас есть схема, которую вы хотите поставить на производство, чтобы обновить существующую схему, вы всегда должны сделать ее частью релиза. Четкий краткий процесс для ALTERing таблиц. Точно так же вам нужно иметь рабочую и проверенную версию ROLLBACK, а также в случае, если что-то пойдет не так.

2. Что я нашел полезным, это использование резервной копии для загрузки на моем локальном (или QA/DEV), так что у меня есть самые современные данные/схемы для игры без влияния на производство. Если вы не выполняете регулярные резервные копии продукции, возможно, сейчас самое подходящее время для реализации политики. Тогда вы убьете двух зайцев одним камнем. У вас будут резервные копии для любых отключений и полезной живой схемы с данными, которые вы можете загрузить для тестирования на другой машине. Это также поднимет все возможные проблемы с изменениями схемы, поскольку данные будут соответствовать производству. Поэтому, если он работает локально (и на DEV/QA), это снижает риск того, что что-то пойдет не так в производстве.