Как вы размещаете веб-сайт в своих веб-серверах?

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

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

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

  • Dev-сервер с виртуальными каталогами, так что каждый имеет свою собственную базу кода,
  • SVN (или любой другой VCS) для отслеживания изменений
  • центральный сервер для тестирования с последним проверенным кодом

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

Как вы справляетесь с такой ситуацией? Какие сценарии развертывания у вас есть в действии?

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

Ответы

Ответ 1

Cassy - вам, очевидно, предстоит пройти долгий путь, прежде чем вы сможете полностью управлять своим исходным кодом, но похоже, что вы на пути!

Наличие отдельных песочниц несомненно поможет в чем-то. Затем убедитесь, что на веб-сайте ВСЕГДА просто чистая проверка конкретной версии, тега или ветки из подрывной программы.

Мы используем git, но у нас есть аналогичная настройка. Мы помещаем определенную версию с номером версии (в git мы также добавляем описание к тегу; полезно для заметок!), А затем у нас есть script, что любой, у кого есть доступ к "сделать релиз", может который принимает два параметра - какая система будет обновляться (датацентр и если мы обновляем тестовый или производственный сервер), а затем номер версии (тег).

script использует sudo для запуска версии script в общей учетной записи. Он выполняет проверку соответствующей версии, сводит к минимуму javascript и CSS 1, подталкивает код к соответствующим серверам для среды, а затем перезапускает то, что нужно перезапустить. Последняя строка выпуска script подключается к одному из веб-серверов и обрабатывает журнал ошибок.

В наш веб-сайты мы включаем комментарий html на нижняя часть каждой страницы с текущим именем сервера и версией - позволяет легко увидеть "Что работает прямо сейчас?"

1 и множество других заданий для домашнего хозяйства, подобных этому...

Ответ 2

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

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

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

Ответ 3

Возможно, вы можете использовать Capistrano, даже если это больше для ruby, есть некоторые статьи, которые описывают, как использовать его для PHP

Я думаю, что Phing может использоваться с CVS, но не с SVN (по крайней мере, тем, что я читал в последний раз)

Есть также некоторый проект вокруг того, который имитирует Capistrano, но написанный на PHP.

В противном случае существует также индивидуальное решение:

  • файлы тегов, которые вы хотите развернуть.
  • проверить файлы, используя тег в конкретный каталог
  • символизирует каталог текущей document root (легко откат к предыдущая версия)

Ответ 4

Естественно, посмотрите SVN для репозитория, Trac, чтобы отслеживать все, и Apache Ant для развертывания.

Основным процессом является управление в Subversion, отслеживание repositroy и разработчиков в Trac и использование сценариев Ant для развертывания вашего сайта с необходимыми настройками. Ant позволяет легко развернуть проект в определенном месте. (Dev/test/prod) и т.д.

Ответ 5

Вам нужно посмотреть:

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

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

Ответ 6

Мы проверяем стабильность с ant каждую ночь. И используйте ant script для развертывания. Его очень легко настроить и использовать.

Ответ 7

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

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