Установка эффективного и продуктивного процесса разработки
Я посреди установки среды разработки (PHP/MySQL) для моего запуска. Мы используем три набора серверов:
ЖИВОЙ - серверы, которые предоставляют реальное приложение ТЕСТ - обеспечение версии тестирования, прежде чем это будет на самом деле выпущено DEV - серверы разработки
Серверы разработки выполненный SVN с каждым разработчиком, проверяющим их локальную копию. В конце каждого завершенного дня фиксирует, зарегистрированы, и затем мы используем Гудзон, чтобы автоматизировать наш процесс сборки и затем передать его для ТЕСТИРОВАНИЯ. Мы затем проверяем, что приложение все еще функционирует правильно с помощью тестера и затем если все - прекрасное перемещение оно для ПРОЖИВАНИЯ. Я доволен этим процессом, но у меня действительно есть два вопроса:
Как был бы Вы рекомендовать, чтобы мы сделали локальное тестирование - поскольку каждый разработчик добавляет новую функциональность страниц или изменений, я хочу, чтобы они смогли протестировать то, что они делают. Вы просто установили бы локальный Apache и локальную базу данных и сделать, чтобы они протестировали локально на их собственной машине?
Как Вы рекомендовали бы иметь дело с изменениями слоя данных?
Есть ли что-либо еще, что Вы рекомендовали бы делать для реального создания нашего процесса разработки максимально легким и эффективным?
Заранее спасибо
2 ответа
+1 каждому разработчику, работающему в своей собственной установке, в комплекте с Apache и базой данных.
Храните схему базы данных в разделе управления версиями.
Возможно, вы могли бы хранить (возможно, в отдельном репозитории) небольшой, но репрезентативный набор данных в тестовой базе данных. Каждое утро вы проверяете последнюю копию этой тестовой базы данных и начинаете взламывать. При изменении схем обновите репозиторий тестовых данных соответствующим образом.
Все, кто занимается разработкой, ДОЛЖНЫ иметь собственную локальную среду. Я использую Mac, поэтому я запускаю MAMP, чтобы у меня была собственная локальная среда LAMP, независимая от любой другой среды. Это также позволит мне узнать, что никто другой не меняет / не работает над теми же компонентами, что и я, и устранит любую возможную путаницу. Если вы являетесь пользователем Windows, также легко установить локальные версии стека LAMP, такие как XAMP и т. Д. Если вы используете Linux в качестве рабочего стола, вы, скорее всего, уже знаете, как установить LAMP для версии Linux, которую вы бегут.
Версия схемы базы данных - отличная идея. Это то, что мы тоже используем. В дополнение к схеме в системе управления версиями мы добавляем в схему таблицу версий схемы и постоянно обновляем ее, чтобы мы могли быстро определить, какая версия находится в производстве / qa / dev, когда нам нужно сравнить.
Что касается изменений уровня данных, я бы порекомендовал две вещи.
Всегда создавайте свой путь миграции, вперед и назад.Это означает, что когда у вас есть схема, которую вы хотите запустить в производство для обновления существующей схемы, вы всегда должны делать ее частью выпуска. Ясный и лаконичный процесс ИЗМЕНЕНИЯ таблиц. Точно так же у вас должна быть рабочая и протестированная версия ROLLBACK на случай, если что-то пойдет не так.
Что мне показалось полезным, так это использование резервной копии производства для загрузки на мой локальный компьютер (или QA / DEV), чтобы у меня были самые свежие данные / схема, с которыми можно было играть, не влияя на производство. Если вы не выполняете регулярное резервное копирование продукции, возможно, сейчас хорошее время для реализации политики. Тогда вы убьете двух зайцев одним выстрелом. У вас будут резервные копии на случай сбоя и полезная живая схема с данными, которые вы можете загрузить для тестирования на другом компьютере. Это также позволит поднять любые возможные проблемы с изменениями схемы, поскольку данные будут соответствовать производственным. Поэтому, если он работает локально (и на DEV / QA), это снижает риск того, что что-то пойдет не так в производственной среде.