Веб-приложения: от разработки к производству

Question

Вот мой текущий процесс переноса изменений с нашего сервера разработки на наш производственный сервер:

1. Файлы, которые необходимо обновить, сняты с производства, чтобы гарантировать, что никаких изменений не было внесено только в производство (нет, это не должно происходить; но да, это действительно происходит). Старые файлы разработки имеют префикс ~ как своего рода «резервное копирование».
2. Разработчик вносит необходимые изменения.
3. Обновленные файлы в разработке копируются с этого сервера и вставляются в соответствующее место на рабочем сервере. Старые рабочие файлы имеют префикс ~ как своего рода «резервная копия».

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

У кого-нибудь есть альтернативы / переделки / конструктивная критика? В нашей команде разработчиков всего 6 человек, и наша база кода состоит из ASP (очень старого, ужасного наследия), PHP (несколько новее) и Java EE (новейший код; все приложения построены как отдельные WAR).

Заранее спасибо

edit: Для разработки наших приложений Java EE у каждого разработчика на своем компьютере работает Glassfish v2. Для PHP / ASP у нас есть центральный сервер разработки. Для производства у нас есть сервер для PHP / ASP (IIS) и еще один для Java (Glassfish v2).

Answer 1

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

При этом, возможно, вы захотите использовать инструмент развертывания, например Capistrano , или инструмент сборки, например Phing .

.

Я использую Capistrano для развертывания нашего приложения PHP, и с помощью одной команды терминала это будет:

1. Проверить копию проекта из системы контроля версий
2. Поместить в версионную папку для развертывания
3. Запуск пользовательских задач - таких как запись символических ссылок в общую папку, запуск задач db, переключение переменной среды из рабочей в производственную и т. Д.
4. Создать символическую ссылку между общей папкой моего приложения и корневым каталогом сервера

Если что-то пойдет не так, он автоматически вернется к последнему удачному развертыванию. Это такой полезный инструмент. Не могу рекомендовать это достаточно.

РЕДАКТИРОВАТЬ: Просто понял, что это не только вопрос PHP. В зависимости от вашей платформы инструменты развертывания могут отличаться. Capistrano прекрасно работает для Rails или PHP. Phing - это версия Apache Ant для PHP. Возможно, вы захотите узнать, какой инструмент лучше всего подходит для выбранной вами платформы.

Answer 2

Как вы сказали, Subversion, вероятно, поможет, в вашем случае: использование некоторой системы управления версиями отлично , а Subversion работает отлично - и вам, вероятно, не нужна децентрализованная система (например, git / mercurial /...).

Основными преимуществами будут:

• проще поделиться модификациями, сделанными каждым разработчиком в вашей команде
• одно центральное местоположение, которое «является официальной версией источников»
• возможно, более простое развертывание.

Хотя я бы не просто использовал svn checkout на моем производственном сервере: хорошо, в некоторых случаях он может работать нормально, но, особенно, если вы иногда изменяете файлы непосредственно на производственном сервере (что вам определенно не следует делать !) , у вас возникнут проблемы (например, конфликты) на рабочем сервере в тот или иной день ...

Да, вы можете использовать svn merge в тестовом режиме, но этого не всегда достаточно ... И нет тестового прогона для обновления svn - а конфликт в файле PHP обычно означает ошибку синтаксического анализа; и это плохо, когда это происходит на рабочем сервере ^^

Вместо этого я бы:

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

Да, и, кстати, о процессе развертывания, вас может заинтересовать ответ, который я дал на этот вопрос некоторое время назад: Обновление веб-приложения без простоев

Как примечание: начать работать с такого рода процессами не всегда легко, поэтому:

• Подумайте как можно больше, прежде чем начинать; публикация на SO - это хорошее начало, но не забудьте обсудить со своими коллегами, которые будут использовать эту систему!
• Не торопитесь: скорее всего, спешки нет, и пара дней размышлений всегда полезны ;-)
  • т.е. Подумайте о ситуациях, с которыми вы можете столкнуться, и ваших сценариях использования, чтобы убедиться, что процессы, которые вы создадите, будут работать для вас.

Answer 3

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

Answer 4

Да .... определенно нужен какой-то контроль источника. Лично мне нравится SVN, и я чувствую, что его довольно легко настроить.

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

Answer 5

Вы правы, использование управления исходным кодом (subversion, git, mercurial и т. Д.) Значительно облегчит вашу жизнь.

Вот основные шаги, которые необходимо предпринять при внесении изменений в продуктокружение:

1. Разработчик вносит изменения в ветку из главной ветви проекта
2. Когда все изменения сделаны и тесты пройдены, объедините изменения обратно в ствол
3. Создание тега для ствола
4. Экспорт этого тега в вашу производственную среду.Если что-то идет не так, вы всегда можете вернуться к ранее развернутому тегу.

Answer 6

Capistrano - отличный инструмент, но я считаю его излишним для не-Rails проектов. Это хорошее руководство по развертыванию проектов PHP в нескольких средах из репозитория: http://themetricsystem.rjmetrics.com/2010/02/01/simple-deploy-script-for-php-applications/