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

Question

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

LIVE - серверы, которые предоставляют актуальное приложение ТЕСТ - предоставление тестовой версии до ее фактического выпуска DEV - серверы разработки

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

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

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

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

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

Answer 1

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

Держите схему базы данных под контролем версий.

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

Answer 2

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

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

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

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

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