Веб-разработчики. Лучше ли делать разработку на локальном компьютере или на удаленном хосте?

Каковы преимущества/недостатки веб-разработки на локальной машине, а не на централизованном сервере разработки? Для тех, кто делает dev на вашей локальной машине, как вы сохраняете обновленную архитектуру db для локальной разработки, когда задействованы несколько разработчиков?

В частности, я сейчас экспериментирую с XAMPP для PHP, и мне было любопытно, как я могу синхронизировать экземпляр MySQL DB на моей локальной машине, когда другие разработчики регулярно меняют структуру данных /db.

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

Ответ 1

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

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

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

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

Стабильный и нормальный! Я не понимаю, почему вы сделали бы это иначе, когда серверы разработки будут бесплатными!

Ответ 2

Я думаю, что лучше всего иметь локальную настройку, которая полностью находится под вашим контролем во время разработки, чтобы гарантировать, что изменения, внесенные другими разработчиками, не будут мешать вашим собственным. У меня есть локальная среда разработки и тестирования, поэтому я могу выполнять обе задачи, не принимая во внимание других разработчиков. Я постоянно запускаю свои тесты, когда я использую autotest, что означает, что мой код верен и удовлетворяет правильной спецификации.

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

Ответ 3

Что касается сохранения вашей базы данных "в синхронизации", когда другие ее редактируют. Один из способов - получить схему БД под управлением версии. Это не так просто, как поставить исходный код под контроль версий, и есть разные способы его обработки.

Прочитайте этот пост о Coding Horror:

http://www.codinghorror.com/blog/archives/001050.html

Не столько сам пост, сколько шесть статей, к которым он приводит К. Скотта Аллена.

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

Ответ 4

Я обнаружил, что запуск локального веб-сервера с удаленным БД работает лучше всего. Репликация/синхронизация БД - боль, поэтому я бы работал только с локальной БД, если бы мне действительно приходилось.

Работа с локальным веб-сервером, хотя и устраняет всю досаду и медленность загрузки страниц/кода между изменениями.

Ответ 5

Плюсы на локальные:

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

Против локального:

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

Плюсы к центру:

У всех есть идентичные инструменты.
всегда работает над "реальным" контентом

Против центра:

не может работать, если сеть не работает.
может отсутствовать ваш "любимый" инструмент.

Я уверен, что их больше, но это сразу приходит в голову.

Ответ 6

Разработка и "тестирование" на локальной машине выполняется Ok, но тестирование качества должно выполняться в системе, отражающей целевую среду, то есть без установленных инструментов разработки и т.д.

Это поможет избежать ситуаций, которые "хорошо работают в моей машине".

Ответ 7

FWIW, я упомянул, что наша установка похожа на то, что описал г-н Мэтт. Каждый разработчик получает свою собственную песочницу, с которой можно связаться, со своим собственным веб-сервером и БД. На пороге релиза управляемый версией код является мгновенным/разветвленным и перемещается на промежуточный сервер, который должен как можно ближе имитировать реальную живую среду. Тестирование происходит, затем выпуск производится в производственной среде.

Для моих личных (не связанных с работой) проектов я развиваюсь локально, а затем вживую. Один или два проекта могут иметь промежуточный сервер тестирования/среду между разработкой и публикой/жить.

Ответ 8

Еще одна причина для работы на месте - все работает быстрее. Это приводит к более быстрому развитию. Сетевое отставание может быть убийцей производительности!

Ответ 9

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

Когда дело доходит до части базы данных вопроса, вы можете либо:

у каждого есть своя собственная копия базы данных OR
синхронизировать данные/структуру, запустив централизованный script (возможно, как часть вашей сборки)

Ответ 10

Одна проблема с тестированием на локальном хосте заключается в том, что вы можете пропустить что-то, что связано с локальными файлами, а не через браузер. Мой отец всегда размещал ссылки на веб-сайте своего камерного клуба, где были такие вещи, как "a href=" C:\My Documents\Camera Club\Photos... ", и когда я скажу ему, что он его обманул, он сказал бы" это сработало для меня". Аналогично, в профессиональной среде у вас могут быть вещи, которые вы забыли проверить в исходном коде управления, и поэтому они не будут развернуты на реальном сервере.

Одним из компромиссных решений может быть виртуальная машина VirtualBox или VMWare или Parallels, так что вы можете запустить виртуальную панель Solaris, Windows, Mac и/или Linux для ее проверки - это покажет вам, как выглядит ваш сайт браузеры по умолчанию для каждого, плюс вы можете убедиться, что все работает через нелокальное соединение. Еще лучше, возможно, иметь виртуальную машину, к которой вы развертываете, и использовать ее как свой веб-сервер для тестирования.

Если ваша базовая ОС - OpenSolaris, вы можете даже использовать ZFS и использовать моментальные снимки, чтобы откат ваших виртуальных машин обратно в их базовое состояние после каждого прогона.

Ответ 11

Я создаю сайт в Ruby on Rails, и я занимаюсь разработкой локально, но часто использую его на удаленной машине. Я читал в Agile Web Development с Rails, что чем больше вы практикуете развертывание, тем лучше, потому что когда придет время для развертывания на производстве - сюрпризов не будет.

Ответ 12

В моем нынешнем положении я развиваюсь на своей машине. Для небольших проектов я просто использую легкий веб-сервер, который поставляется с Visual Studio. У меня также есть SQL Server 2005 и 2008, настроенные на моей машине для разработки и начального тестирования.

Это хорошо сработало для меня в целом; одна проблема, с которой я столкнулся, - это, как отмечали другие, сохранение синхронизации баз данных - это боль. Я недавно перешел в nettrap.net net net - в основном .NET берёт на себя миграцию Ruby on Rails - для сохранения локального/промежуточного/uat/production баз данных, и это делает мою жизнь намного менее напряженной. Такой инструмент также упрощает работу с базой данных в командной среде, хотя вы должны быть достаточно дисциплинированными, чтобы использовать его последовательно.

Мои опыты убедили меня в том, что наилучшим способом является локальная разработка в сочетании с каким-то процессом управления изменениями db, сервером непрерывной интеграции и хорошей системой управления версиями, которая поддерживает слияние (мы используем TFS). Это позволяет всем делать свое дело, не наступая на кого-то другого, но также гарантирует, что изменения будут слиты должным образом.

В моей предыдущей работе мы использовали IIS на наших компьютерах в сочетании с выделенной базой данных разработки, и это было немного PITA - вы должны были быть осторожны, чтобы не запускать какие-либо процессы, которые могут привести к сбою базы данных или даже испортить потому что это может повлиять на других разработчиков, а IMO - на то, чтобы победить цель создания БД разработки.

Ответ 13

Я - магазин одного человека; У меня есть как удаленный сервер, так и локальный сервер.

Я использую локальный сервер для быстрого прототипирования и начального цикла разработки, где я делаю много изменений и должен быстро их протестировать. Когда он дойдет до этапа "приблизительно-альфа", я настрою собственный суб-хост для проекта и развернусь на моем сервере. Есть определенные функции, которые просто не могут быть протестированы локально - т.е. регистрация пользователей по электронной почте - и поэтому эти функции разрабатываются на удаленном сервере. Поскольку это MINE, а не реальное развертывание, оно по-прежнему в основном не имеет запаса. Поскольку у меня есть VPS, я полностью контролирую среду разработки на обеих машинах.

Ответ 14

Обычно у вас есть локальный сервер разработки, который все разделяют.

Ответ 15

В такой ситуации я всегда делал это на сервере разработки. Поскольку перекомпиляций нет. Вы всегда можете получать новый снимок DB каждый день и переносить его на свой компьютер. Или просто локальный веб-сервер и укажите DB в окне dev.

Ответ 16

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