Мульти-Разработчик -Настройка с SVN-VC и удаленными тестовыми серверами для каждого разработчика. Лучшие практики?
Я хотел бы получить некоторую информацию о том, как может выглядеть программа профессионального развития со следующими требованиями.
- несколько PHP-разработчиков (скажем, PHP)
- каждый разработчик принадлежит к одной группе
- в каждой группе есть один руководитель группы, который делегирует задачи
- каждый разработчик работает на одной машине с Windows 7
- и развивается либо с помощью NetBeans, либо с помощью Eclipse
- каждый разработчик "владеет" одним виртуальным тестовым сервером, на котором он может запускать код
- используемый VCS - это SVN
- существует промежуточный сервер, на котором продукт в конечном счете тестируется до его выпуска/развертывания
Я дал некоторые конкретные технологии, чтобы не быть слишком абстрактными, и, кроме того, мне также были бы интересны конкретные предложения по плагинам и т. Д.
В этой ситуации мне приходит в голову несколько вопросов.
1) Таким образом, каждый разработчик будет работать над личной веткой.
2) Эта ветвь проверена в рабочем копировать.
Сейчас... эта рабочая копия редактируется локально на ПК с помощью IDE разработчика и выполняется/тестируется на сервере.
Что было бы в этом случае лучшим/обычным способом сделать это? Я имею в виду - как вы получаете отредактированный код на сервере, не вызывая слишком больших накладных расходов?
Будет ли у разработчика вообще код на его локальном диске? Или было бы лучше, чтобы IDE записывалась на удаленный виртуальный сервер через туннель или по определенному протоколу?
3) Каждый день разработчик передаст свою работу в свою личную ветвь, которая находится в центральном хранилище.
Существует ли наилучшая практика в отношении того, где должно располагаться хранилище? Отдельный сервер?
4) Затем, после того как разработчик выполнил свою задачу, либо он, либо руководитель группы объединяют новый код в соответствующую основную ветвь или магистраль.
Самая запутанная часть касается того, что я написал между 2) и 3). Потому что до сих пор я работал только с локальным сервером. Например, виртуальная машина с сервером запуск кода, который находится в общей папке, чтобы я мог редактировать его напрямую. Я не уверен, как эффективно преодолеть этот разрыв, когда сервер теперь фактически удален. Эффективно означает, например, отсутствие необходимости загружать данные вручную через FTP.
Также приветствуются внешние источники или рекомендации по книгам.
Редактировать
Мой вопрос/вопросы/нацелены на квази-стандартную/передовую практику. Я думаю, что это в значительной степени стандартный сценарий развития, поэтому должен быть "обычное" решение.
Редактировать 2
Хорошо... итак, давайте попробуем с картинкой:
V - виртуальный тестовый сервер для одного или нескольких разработчиков D.C и C' - две версии кода. Они должны быть как можно более идентичными.
Мне приходят на ум два решения:
1: Отредактируйте C, затем загрузите его в C', затем выполните C', затем зафиксируйте C.
2: C не существует. Просто C', который редактируется с помощью какой-то туннельной технологии, выполняется и фиксируется.
Мой интуиция подсказывает мне, что оба решения являются полуоптимальными. Итак, что было бы "профессиональным" /наиболее эффективным / быстрым / наиболее удобным / без трения / наименее подверженным ошибкам / лучшей практикой / отраслевым стандартом?
Есть вопросы?
4 answers
Я уверен, что у всех разные способы делать что-то, но вот мои мысли.
" Лучшая практика", вероятно, "Непрерывная интеграция", т.е. у каждого разработчика нет своей собственной ветви, но он регистрируется в общей ветви разработки. Это заставляет их справляться с конфликтами и координировать свои действия друг с другом на ранней стадии и часто для того, чтобы ведущий разработчик не управлял огромным крушением поезда, которое произойдет позже в будущем. Взгляните на cruisecontrol, если вы действительно хотите поехать этот маршрут.
Лучший способ - это если у них есть локальный веб-сервер apache и полный стек php. Вы можете использовать выпуск сообщества Zend_Server для быстрого запуска и запуска в Windows. Большинство стандартных php-кодов будут отлично работать как в Windows, так и в Linux, Но если вы выполняете много операций с файлами, выполняете задания cron или cli, или вам нужен кэш памяти и т. Д., Вы столкнетесь с несовместимостью. Если это так, и материал, предназначенный только для Linux, вас укусит, используйте VMWARE или VirtualBox для локального запуска экземпляры linux и установите IDE внутри них и просто убедитесь, что у них есть много оперативной памяти, чтобы справиться с этим.
Каждому разработчику необходимо запустить синхронизацию внутри Eclipse, в основном обновление svn, устранить любые конфликты с другими разработчиками прямо сейчас и там, провести локальное тестирование и зафиксировать их изменения.
Я настраиваю крючок post_commit на сервере svn, который вызывает и/autobuild.php на моем веб-сервере. autobuild.php запускает обновление svn и получает последние изменения кода а также выполняет ли какие-либо разрешения на доступ к файлам chown или chmod и сбрасывает любые файлы конфигурации, специфичные для сервера config.php . Немного сложно настроить его так, чтобы пользователь apache мог запускать обновление svn, но как только вы выполните бета-тестирование/тестирование, на сервере всегда будет последний зафиксированный код. CruseControl и некоторые другие также могут помочь вам в этом, добавить модульное тестирование и т. Д.
Теперь вашему Ведущему разработчику все еще предстоит выполнить работу по объединению ветки разработки с Производственной, тестированию на сервер разработчиков, а также просмотр коммитов других и принятие решения о том, как и когда выпустить релиз, но вы не возлагаете на него бремя разрешения каждого конфликта и объединения каждого изменения.
Ваши разработчики не используют файлы ftping или удаленное подключение по ssh к серверам, они просто работают локально в своей среде IDE и взаимодействуют друг с другом через svn (и электронную почту, телефон, чат и т. Д.), Обновляя, чтобы получить новый код и фиксируя по мере завершения работы.
Я не вижу никаких хорошо, что у вас есть отдельная ветвь для каждого разработчика, использующего SVN. Объединение этих ветвей может работать в Git, но с SVN ваш ведущий разработчик очень быстро возненавидит жизнь с таким типом настройки.
Возможно, это не очень помогает, но GIT идеально подходит для ваших проблем, я рекомендую взглянуть на функции GIT. И если у вас есть время, проверьте, что Линус Торвальдс сам говорит о мерзавце. http://www.youtube.com/watch?v=4XpnKHJAok8
Стандартная процедура, как вы описываете, более или менее одинакова. Я также рекомендую этот подход для моей команды. Это также можно назвать поэтапной разработкой приложений.
Вот как я это делаю, я использую удаленный хост SVN (например: assembla.com, unfuddle.com ) для хранения всех моих кодов. Члены моей команды хранят информацию на этих удаленных серверах svn. Вы также можете купить VPS и настроить SVN там и использовать тот же подход.
Наилучшей практикой является локальное тестирование и фиксация и делайте фиксацию столько раз, сколько сможете, но каждая фиксация должна решать проблему или включать значительный сегмент, который добавляет какую-либо новую функцию.
Как только фиксация будет выполнена всеми, ведущий разработчик сможет войти на промежуточный сервер через SSH, используя такие инструменты, как PuTTY. В первый раз ведущий разработчик должен извлечь код в папку, в которой должны быть расположены коды. На этом этапе может возникнуть конфликт файлов, если несколько разработчиков редактируют один и тот же сегмент файла. Затем ведущий разработчик должен сначала разрешите код, а затем приступайте к оформлению заказа. После проверки ведущему разработчику потребуется только обновить svn на промежуточном сервере, чтобы обновить код.
Основная идея состоит в том, чтобы заставить код работать на локальной установке, затем зафиксировать и обновить промежуточный этап для тестирования приложения по моделируемому сценарию, а затем зафиксировать его на реальном сайте.
Здесь есть много "если" и "но", которые понадобятся мне, чтобы написать главу о:) но вкратце это изюминка.
Инструменты (вы можете использовать для работы в рамках этой настройки): - Менеджер SVN черепахи - Шпаклевка - NetBeans
Надеюсь, это поможет:)
Мне не нравится работать с личными филиалами. Я работал с ClearCase почти 15 лет, и хотя ClearCase, вероятно, справляется с персональным ветвлением лучше, чем большинство, это все равно было большой болью. Что еще хуже, личные филиалы побуждают людей не выполнять свою работу до последней минуты - обычно за день или два до крупного релиза.
По этой причине и для того, чтобы заставить разработчиков поддерживать связь друг с другом, я настоятельно рекомендую всем работать вместе в одной ветке (или на багажнике) как можно больше. Я продолжаю говорить разработчикам, чтобы они делали небольшие укусы, когда они вносят изменения.
Похоже, вам нужен способ автоматизации развертывания. То есть я вношу изменения на своей локальной машине и с помощью одной команды удостоверяюсь, что на сервере есть дубликат кода. Вы также хотите, чтобы развертывание было эффективным. Если вы измените один файл объемом 2 килобайта объемом 2 гигабайта с развертыванием 10 000 файлов, вам потребуется скопировать только этот файл, не 10 000 гигабайт. Для этого я бы рекомендовал вам написать сценарий развертывания в Ant.
Ваши разработчики могут изменять файлы, а затем развертывать эти файлы с помощью сценария Ant. Разработчикам не нужно запоминать, какие файлы они обновили, потому что Ant автоматически обработает это. На самом деле, Ant может даже изменять файлы, чтобы убедиться, что они содержат правильную информацию об окружающей среде, когда они копируются. И, конечно, Ant может изменить порядок файлов, если настройка на сервере отличается от настройки в исходном репозитории. И Netbeans, и Eclipse могут выполнять сценарии Ant прямо в среде IDE.
Итак:
- Попросите ваших разработчиков изменить код на своем локальном компьютере.
- Запустите сценарий Ant, чтобы убедиться, что сервер и локальная машина синхронизированы.
- Проверка на сервере.
- Затем проверьте их изменения, как только они будут довольны результатами на сервере.
Кто-то упомянул систему непрерывной сборки, такую как Дженкинс. Это на самом деле было бы хорошей идеей в любом случае, даже если это не решит эту конкретную проблему. У Дженкинса может быть свой собственный сервер и база данных. Затем, когда вы зафиксируете свой код, Дженкинс обновит сервер и запустит автоматические тесты. Затем Дженкинс может создать отчет. Все это отображается на веб-странице Дженкина. Кроме того, вы можете архивировать свои развертывания в Jenkins, поэтому, если вы скажете кому-нибудь протестировать "Сборку № 20", они могут просто снять ее с Jenkins, где ее легко найти.