Как оптимизировать обновление веб-приложения?

Question

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

Шаги, которые я делаю для обновления приложения:

1. Доступ через FTP (Filezilla)
2. Загрузить файл .htaccess, который перенаправляет всех людей (кроме моего IP) в файл mantain.html
3. Убедитесь, что доступ запрещен для других IP, кроме моего.
4. Резервное копирование старого кода
5. Загрузить новый код
6. Перейти к PhPMyAdmin
7. Резервная копия БД
8. Выполнение скриптов для БД
9. Проверить, что все работает нормально (если нет -> восстановить резервные копии)
10. удалить .htaccess файл

Я обычно провожу в среднем 30 минут, выполняя эти шаги, и мне интересно, есть ли способ оптимизировать, автоматизировать или сделать что-то, чтобы тратить меньше времени. Также я знаю, что если я могу автоматизировать некоторые этапы, то они менее подвержены ошибкам.

Answer 1

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

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

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

1. Загрузить новый код на сервер в каталоге с именем new /
2. Войдите на сервер через оболочку и выполните скрипт upgrade
3. Тестирование нового сайта
4. Выполнить обновить-завершить

Конец.

Теперь для интересной части скрипт upgrade сделает это:

1. Он удалит символическую ссылку .htaccess и заново создаст ее, указав на .htaccess-maintenence .
2. Будет скопирован текущий код в current / в backup /
3. Он будет выполнять резервное копирование БД, используя те же самые команды, которые использует PHPMyAdmin
4. Переместит содержимое new / (которое вы только что загрузили) в current /
5. Он выполнит сценарии для БД

И скрипт upgrade-finalize будет просто:

1. Удалите символьную ссылку .htaccess и заново создайте ее, указав на .htaccess-constant еще раз

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

Answer 2

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

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

Выполнение этого вручную, как вы говорите, вызывает проблемы.

Answer 3

Посмотрите на инструмент развертывания, например Capistrano , который позволяет автоматизировать эти шаги.

Answer 4

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

Возможно, вы также можете сделать резервную копию во время работы, если вам не нужна согласованность в базе данных.Для миграции, которая не «нарушает» функциональность, вы также можете перенести ее и протестировать на новом веб-корне с другим именем хоста, если согласованность не является проблемой.

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