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

Question

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

https://blog.codinghorror.com/get-your-database-under-version-control/

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

Разработка и «тестирование» на локальном компьютере - это нормально, но тестирование качества должно проводиться в системе, которая отражает целевую среду, т. Е. Без всех установленных инструментов разработки и т. Д.

Это поможет избежать ситуаций «хорошо работает на моей машине».

Answer 6

Плюсы к местному:

• работает, даже если сеть не работает
• Вы знаете каждый инструмент на станке

Минусы для местных:

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

Плюсы к центральному:

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

Минусы к центральному:

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

Я уверен, что есть и другие, но они сразу приходят на ум.

Answer 7

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

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

Answer 8

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

Answer 9

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

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

Answer 10

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

Это сработало для меня в целом; Единственная проблема, с которой я столкнулся, - это (как уже отмечали) синхронизация баз данных - это своего рода боль. Недавно я перешел на migrator dot net - в основном .NET берет на себя миграцию Ruby on Rails - для синхронизации локальных / staging / uat / production баз данных, и это делает мою жизнь намного менее эффективной стресс. Подобный инструмент также облегчает работу с базой данных в командной среде, хотя вы должны быть достаточно дисциплинированными, чтобы использовать ее последовательно.

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

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