Что нужно знать перед установкой нового Web Dev Env? - PullRequest
2 голосов
/ 30 декабря 2010

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

Мне не нужны знания, необходимые для кодирования сайта (php, js, html)., CSS и др.).Это все, что я знаю.

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

Что быхороший путь обучения?

Ответы [ 2 ]

2 голосов
/ 30 декабря 2010

Как человек, который руководил этим процессом в нескольких компаниях, я рекомендую постепенно повышать «зрелость» вашей организации как фабрики программного обеспечения путем постепенной консолидации набора практик в порядке, который соответствует вашим потребностям.Порядок, которому я стремлюсь следовать (начиная с вещей, которые я считаю более простыми, до более продвинутых):

  1. Контроль версий - контролируйте свои источники.Раньше я работал с SVN, но постепенно перевожу свою команду в Mercurial (я согласен с рекомендацией Meagar для распределенной VCS).Отличное учебное пособие по HG: hginit
  2. Создание понятного процесса выпуска , маркировка ваших выпусков в VCS, чистая сборка в контролируемой среде, тестирование и выпуск из них..
  3. Отслеживание дефектов - будьте систематичны в своих ошибках и запросах функций.Я склонен использовать Trac , потому что он дает мне более или менее полное решение для управления проектами плюс вики, который я использую в качестве базы знаний.Но у вас есть большой выбор (Jira, Bugzilla и т. Д.)
  4. Установить рутину Методы тестирования . Модульные тесты , например, с помощью одной из xUnit Framework (сделайте привычкой, по крайней мере, писать модульные тесты для новых функций, которые вы пишете, и старого кода, который вы изменяете) и тесты интеграции / системыдля веб-приложений используйте какой-нибудь инструмент, например, Selenium).
  5. Сделайте ваши тесты частыми, как часть процесса автоматической сборки
  6. В конце концов, напишите свои тесты перед тем, как писать код ( Разработка через тестирование ) и стремимся увеличить охват.
  7. Сделайте шаг вперед в цикле сборки / тестирования / выпуска, настроив систему с непрерывной интеграцией (чтобы регулярно выполнять сборку и тесты)хотя бы ночью).Недавно я начал использовать Hudson , и он отлично подходит для наших проектов Java / Maven, но вы можете использовать его и для любого другого процесса сборки

С точки зрения сред тестирования, ясогласен с рекомендациями meagar.У нас есть следующие уровни:

  1. Тест на рабочих станциях разработчиков (должен содержать полную настройку для запуска вашего кода)
  2. Staging среда:как можно ближе клонируйте свою производственную среду, разверните и запустите там свое приложение.Мы также используем виртуальные машины.
  3. Предварительный просмотр производства : мы разворачиваем наше приложение на производственных серверах с производственными данными, но в другом URL-адресе предварительного просмотра только для внутреннего использования.Мы запускаем часть наших автоматических интеграционных тестов на этом сервере и проводим дополнительное ручное тестирование с внутренними пользователями
  4. Производство - и держим пальцы скрещенными;)

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

2 голосов
/ 30 декабря 2010

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

Я бы лично порекомендовал распределенную VCS, такую ​​как git или mercurial, локальную WAMP / LAMP.стеки на каждой рабочей станции разработчика (общие «глупые» серверы разработки) и сервер, на котором запущены некоторые тестирующие виртуальные машины, которые являются дубликатами вашей производственной среды.Вы не можете попросить более конкретный совет, чем этот, без привлечения ваших разработчиков.

...