Лучшая практика обновления сайта - PullRequest
3 голосов
/ 21 марта 2009

В настоящее время мой рабочий процесс выглядит следующим образом:

Локально на машине. Я поддерживаю git-репо на каждом веб-сайте, над которым я работаю. Когда приходит время публиковать что-то, я сжимаю папку и загружаю этот единственный файл на производственный сервер через ssh, затем распаковываю, тестирую изменения. переместите изменения в папку live, и я избавлюсь от папки .git.

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

Позже я прочитал о capistrano http://capify.org, но у меня нет опыта работы с этим программным обеспечением ...

По вашему опыту, каков наилучший метод / методология для развертывания / обновления веб-сайта?

Заранее спасибо и за ваши отзывы.

Ответы [ 3 ]

2 голосов
/ 21 марта 2009

Я не думаю, что наш метод можно назвать наилучшей практикой, но он хорошо нам послужил.

У нас есть несколько больших баз данных для нашего приложения (20 ГБ +), поэтому поддержка локальных копий на каждом компьютере разработчика никогда не была опцией, и даже если мы не разрабатываем против действующей базы данных, нам нужно заняться разработкой к базе данных, максимально приближенной к реальной.

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

У нас также есть проверка кода на производственных серверах, поэтому после того, как мы закончим тестирование, мы просто делаем svn-обновление на рабочих серверах. Мы реализовали скрипт, который выполняет команду обновления на всех серверах, используя ssh. Это очень удобно, поскольку наша кодовая база велика и требует много времени для загрузки. Subversion будет копировать только те файлы, которые действительно были изменены, так что это намного быстрее.

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

0 голосов
/ 21 марта 2009

Капистрано великолепен. Рецепты по умолчанию Документация пятнистая, но список рассылки активен, и его настройка довольно проста. Вы используете Rails? Он имеет некоторые аккуратные встроенные функции для приложений Rails, но также довольно часто используется с другими типами веб-приложений.

Существует также Webistrano , который основан на Capistrano, но имеет веб-интерфейс. Сам не использовал. Другая система развертывания, которая, похоже, набирает обороты, по крайней мере, среди пользователей Rails, - это Vlad the Deployer .

0 голосов
/ 21 марта 2009

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

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

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

...