Multi-Developer-Setup с SVN-VC и удаленными тестовыми серверами для каждого разработчика. Лучшие практики?

Question

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

• несколько PHP-разработчиков (скажем PHP)
• каждый разработчик принадлежитв одну группу
• в каждой группе есть один руководитель группы, который делегирует задачи
• , каждый разработчик работает на одной машине с Windows 7
• и разрабатывается с использованием NetBeans или Eclipse
• каждый разработчик «владеет» одним виртуальным тестовым сервером, на котором он может запустить код
• Используется VCS: SVN
• есть промежуточный сервер, на котором продукт в конечном итоге тестируется до его получениявыпущено / развернуто

Я дал некоторые конкретные технологии, чтобы они не были слишком абстрактными и б / к. Мне также были бы интересны конкретные предложения для плагинов и т. д.

---

ТамВ этой настройке мне приходит в голову несколько вопросов.

1) Таким образом, каждый разработчик будет работать в личной ветке.

2) Эта ветвь извлечена в рабочей копии.

Теперь ... эта рабочая копия редактируется локально на ПК с помощью IDE разработчика и выполняется / тестируется на сервере.

Что было бы в этом случае лучшим / обычным способом сделать это?Я имею в виду - как вы можете получить отредактированный код на сервере, не вызывая чрезмерных накладных расходов?

Будет ли разработчик иметь код на своем локальном диске вообще?Или было бы лучше иметь IDE для записи на удаленном виртуальном сервере через туннель или по определенному протоколу?

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

Есть ли лучшая практика относительно того, где хранилище должно быть расположено?Отдельный сервер?

4) Затем, после того, как разработчик завершил свою задачу, он или руководитель группы сливают новый код в соответствующую основную ветвь или магистраль.

---

Самая запутанная частьо том, что я написал между 2) и 3).Потому что пока я работал только с локальным сервером.Например, виртуальная машина с сервером, на котором выполняется код, который находится в общей папке, поэтому я смогу редактировать его напрямую.Я не уверен, как эффективно преодолеть разрыв, когда сервер теперь фактически удален.Эффективно означает, что нет необходимости загружать вручную через FTP, например.

Также приветствуются внешние источники или рекомендации книг.

---

edit

Мой вопроснацеленность на квази-стандарт / лучшую практику.Я думаю, что это в значительной степени стандартный сценарий разработки, поэтому должно быть «обычное» решение.

---

edit 2

Хорошо ... так что давайте попробуем с картинкой:

V - это виртуальный тестовый сервер для одного или нескольких разработчиков D. C и C '- две версии кода.Они должны быть максимально идентичными.

Мне приходят на ум два решения:

1: отредактируйте C, затем загрузите его в C ', затем выполните C', затем подтвердите C.

2: C не существует.Просто C ', который редактируется с помощью некоторой туннельной технологии, выполняется и передается.

Мои смелости говорят мне, что оба решения полуоптимальны.Итак, что было бы «профессионально» / наиболее эффективно / максимально быстро / наиболее удобно / максимально без трения / наименее подвержено ошибкам / передовой опыт / отраслевой стандарт?

Есть вопросы?

Answer 1

Возможно, это не очень помогает, но GIT звучит как идеально подходящее для ваших проблем, я рекомендую взглянуть на функции GIT. И если у вас есть время проверить Линус Торвальдс, он сам говорит о GIT. http://www.youtube.com/watch?v=4XpnKHJAok8

Answer 2

Мне не нравится работать с личными ветками. Я работал с ClearCase почти 15 лет, и хотя ClearCase, вероятно, справляется с персональным ветвлением лучше, чем большинство, это все еще было большой болью. Хуже того, личные ветки побуждают людей не начинать свою работу до последней минуты - обычно за день или два до основного выпуска.

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

То, что вам нужно, это способ автоматизации развертывания. То есть я делаю изменения на своем локальном компьютере, и с помощью одной команды я проверяю, чтобы на сервере была дублированная копия кода. Вы также хотите, чтобы развертывание было эффективным. Если вы изменяете один файл размером 2 килобайта при развертывании в 10 000 файлов размером 2 гигабайта, вам нужно скопировать только один файл, а не 10 000 гигабайт. Для этого я бы порекомендовал вам написать сценарий развертывания в Ant .

Ваши разработчики могут изменять файлы, а затем развертывать эти файлы с помощью сценария Ant. Разработчики не должны помнить, какие файлы они обновили, потому что Ant автоматически с этим справится. Фактически, Ant может даже изменять файлы, чтобы убедиться, что они содержат правильную информацию о среде, когда они копируются. И, конечно же, Ant может переставлять файлы, если настройки на сервере отличаются от настроек в исходном хранилище. И Netbeans, и Eclipse могут выполнять сценарии Ant прямо в IDE.

Итак:

• Пусть ваши разработчики изменят код на своей локальной машине.
• Запустите сценарий Ant, чтобы убедиться, что сервер и локальный компьютер синхронизированы.
• Тест на сервере.
• Затем проверьте их изменения, как только они будут довольны результатами на сервере.

Кто-то упомянул систему непрерывной сборки, такую ​​как Jenkins . Это на самом деле было бы хорошей идеей в любом случае, даже если это не решает эту конкретную проблему. Дженкинс мог иметь свой собственный сервер и базу данных. Затем, когда вы фиксируете свой код, Дженкинс обновляет сервер и запускает автоматические тесты. Дженкинс может затем создать отчет. Все это отображается на веб-странице Дженкин. Кроме того, вы можете заархивировать свои развертывания в Jenkins, поэтому, если вы скажете кому-нибудь протестировать «Сборку №20», они могут просто извлечь его из Jenkins, где его легко найти.

Answer 3

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

Вот как я это делаю, я использую удаленный хост SVN (например :assembla.com, unfuddle.com) для хранения всех своих кодов.Члены моей команды хранят информацию там на этих удаленных серверах SVN.Вы также можете купить VPS и настроить SVN там и использовать тот же подход.

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

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

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

Существует множество вариантов «если» и «здесь», которые понадобятся мне, чтобы написать главу о :), но вкратце этоизюминка

Инструменты (вы можете использовать для работы в этой настройке): - Черепаха SVN Manager - PuTTy - NetBeans

надеюсь, это поможет:)

Answer 4

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

"Лучшая практика" , вероятно, "Непрерывная интеграция" т.е. каждый разработчик не имеет своей собственной ветки, но регистрируется в общей ветке разработки. Это вынуждает их обрабатывать конфликты и скоординировать действия друг с другом на ранних этапах и часто, чтобы избежать того, чтобы ведущий разработчик смог справиться с огромным слиянием поездов, которое произойдет позже. Посмотрите на круиз-контроль, если вы действительно хотите пойти по этому пути.

Лучше всего, если у них есть локальный веб-сервер Apache и полный стек php . Вы можете использовать версию сообщества Zend_Server для быстрого запуска и запуска Windows. Большая часть стандартного php-кода будет прекрасно работать как в Windows, так и в Linux, но если вы выполняете много манипуляций с файлами, работами cron или cli, или вам требуется memecache и т. Д., Вы столкнетесь с несовместимостью. Если дело обстоит именно так, а кусочки Linux будут кусаться, то вы используете VMWARE или VirtualBox для запуска локальных экземпляров linux и установки внутри них IDE и просто убедитесь, что у них есть набор оперативной памяти для работы с ним.

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

Я установил post_commit hook на сервере svn, который вызывает и /autobuild.php на моем веб-сервере. autobuild.php запускает обновление svn и получает последние изменения кода, а также выполняет любые действия с разрешениями для файлов chown или chmod и сбрасывает любые конфигурационные файлы для конкретного сервера config.php. Немного сложно настроить его так, чтобы пользователь apache мог запустить svn update, но после того, как вы выполните бета-тестирование, на сервере всегда будет последний зафиксированный код. CruseControl и некоторые другие могут также помочь вам в этом, добавить модульное тестирование и т. Д.

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

Ваши разработчики не используют файлы ftping или удаленное удаленное взаимодействие с ssh на серверах, они просто работают локально в своей IDE и взаимодействуют друг с другом через svn (и по электронной почте, по телефону, в чате и т. Д.). ) обновление для получения нового кода и фиксация по окончании.

Я не вижу ничего хорошего в том, чтобы иметь отдельную ветку для каждого разработчика, использующего SVN. Объединение этих веток может работать в Git, но с SVN ваш ведущий разработчик будет очень быстро ненавидеть жизнь с таким типом установки.