Как я должен переместить свой код от dev до производства?

Используйте файлы конфигурации, чтобы определить, к какой базе данных вы подключаетесь. То есть иметь файл конфигурации DEV, файл конфигурации TEST и файл конфигурации PROD. Обычно это лучший способ избежать дорогостоящих и разочаровывающих ошибок.

На самом деле, я не вижу причин, по которым среда TEST должна чудесным образом перейти на PROD без выключения сервера. Предполагается, что продукция TEST предназначена для тестирования. И даже если вы на самом деле ТЕСТИРУЕТЕ на производственном сервере, выключите его (выключите apache), измените одну строку в вашем основном файле конфигурации, которая определяет, какой набор второстепенных файлов конфигурации использовать) и снова откройте его (запустите apache). Это займет не более 1–3 минут, и, поскольку вы точно не собираетесь делать это двенадцать раз в день, все будет в порядке.

1. Have your code in a revision control system (I prefer Subversion (svn)). This makes it easy to keep your DEV, TEST and PROD environments in sync, you don't have to keep track of files you modified. Once you are happy with your modifications on DEV, you commit the changes to svn and then run "svn update" on the TEST and eventually after testing on PROD server. Most linux hosting providers have svn client installed or you can install it yourself.

2. I don't like having a different version of a config file for each site because it requires manually renaming one file and removing the other two. I prefer having DEV, TEST and PROD configurations in the same config file. In the config file I determine which server the code is running on by checking either the hostname or the request url. Then I can have "if" or "switch" statement that would load configuration settings based on which server is currently running the code.

3. You might also need to sync database structure between your servers. I use sqlyog for this purpose, it has a built-in database structure synchronization tool that compares 2 database structures and prepares SQL to synchronize them.

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

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

Чтобы перейти из одной ветки в другую, мы выполняем слияние, скажем, альфа- и бета-версии, и фиксируем это слияние. Затем запустите сценарий развертывания, который обновляет ветку из SVN на нашей машине разработки, затем rsync загружает код веб-серверов в корень бета-документа.

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

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

1) Отделите конфигурацию от остального кода. Остальная часть кода должна быть способна работать во всех трех местах без изменений. Типичный файл конфигурации может быть таким:

<? 
$db = "main_db"; $db_user="web1"; $db_pass = "xyz123"; 
$site ="example.com"; 
$htroot = "/var/www/prod/htdocs" 
?>

И для тестовой среды:

<? 
$db = "test_db"; $db_user="web1"; $db_pass = "xyz123"; 
$site ="test.example.com"; 
$htroot = "/var/www/test/htdocs" 
?>

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

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

<? 
$site = $_SERVER["HTTP_HOST"];

if ($site == "example.com"; ) {
  $db = "main_db"; $db_user="web1"; $db_pass = "xyz123"; 
  $htroot = "/var/www/prod/htdocs";
}
if ($site == "test.example.com") { 
  $db = "test_db"; $db_user="web1"; $db_pass = "xyz123"; 
  $htroot = "/var/www/test/htdocs";
}
?>

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

2) У вас уже есть "версии". Сейчас на prod работает одна версия. Дайте ей уникальное имя и номер, которые больше никогда не изменятся. Вы можете использовать это имя версии при резервном копировании кода и когда вы ссылаетесь на эту версию или когда вы перемещаете ее куда-то, вы называете поддиректорию, которая будет содержать ее, именем этой версии.

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

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

Обратите внимание, что конфигурационные файлы (3, по одному для prod, test и dev) НЕ являются частью версий. Поэтому вы можете "перемещать версии", но не файлы конфигурации. Если вы можете, поместите конфигурационные файлы ВНЕ дерева с остальным кодом, чтобы вам не нужно было разделять их и заботиться о том, чтобы позже перемещать версии. Вы можете переместить конфиг на один каталог "вверх" и получить доступ к ним из файлов следующим образом:

"include ../config.php";

3) Если вы хотите использовать системы контроля версий, они делают отличную работу, но нужно некоторое время, чтобы привыкнуть к ним, и если вы торопитесь с обновлением, то, вероятно, сейчас не время начинать жить с ними. Но на будущее я бы рекомендовал использовать распределенную систему контроля версий последнего поколения. Распределенная система означает, что вам не нужно устанавливать сервер и имеет много других преимуществ. Я назову bazaar, при необходимости обновления по ftp он справится. Обратите внимание, что система контроля версий делает обмен версиями очень быстрым, так как записываются только различия между версиями. Bazaar имеет сообщество и документацию, что облегчает начало работы. Существует также Git, который имеет самый современный коммерческий хостинг: http://github.com. Вы можете просматривать код онлайн и сравнивать версии, а также есть много других полезных функций, даже если вы единственный кодер, но в группе это еще лучше. Выбор между этими системами непрост. Я не могу рекомендовать CVS, которая устарела. Также SVN не является последним поколением распределенной системы контроля версий, я бы не рекомендовал использовать ее, если нет конкретной причины, и она будет загрязнять все ваши поддиректории специальными поддиректориями, что может раздражать. Для людей, которые привыкли к ней и уже имеют код на ней, это нормально, но для начинающих я бы сказал, что не стоит.

Среди распределенных систем контроля версий с открытым исходным кодом есть также Mercurial и Darcs. У Mercurial также есть отличный коммерческий сайт для совместной работы и просмотра кода онлайн (http://bitbucket.org).

4) Пока вы не используете систему контроля версий, как насчет использования симлинков?

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

У вас может быть src/versions/v001/ src/versions/v002/ src/versions/v003/ или любая другая схема именования, которую вы используете.

А вот и хитрость: /var/www/prod/htdocs является симлинком на src/versions/v001/

При обновлении до v002 вы просто делаете следующее:

• выключаете apache
• удаляете старый симлинк /var/www/prod/htdocs (на этом этапе webroot apache исчезает! )
• создайте новую ссылку /var/www/prod/htdocs, являющуюся ссылкой на src/versions/v002
• запустите apache

Вы также можете написать для этого скрипт с параметрами и вызвать его следующим образом:

upgrade-web prod 002

Это делает промежуток еще короче.

Иногда вам нужно сделать "fallback", когда вы обнаруживаете, что в новой версии есть ошибки, и вам нужно вернуться назад. Это было бы просто (потому что вы не удаляете старые каталоги, вы просто останавливаете apache, удаляете симлинк и возвращаетесь обратно).создайте его в прежнем месте, в данном случае src/versions/v001 )

А если test и dev находятся на одном сервере, вы, конечно, можете связать симлинками те же директории, так что не будет необходимости в перемещении или копировании.

5) Если вы делаете это вручную без симлинков, почему бы не перемещать вместо копирования?

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

Если есть несколько каталогов на корневом уровне проекта, вы можете перемещать их по одному. Убедитесь, что вы НЕ ПЕРЕМЕЩАЕТЕ файлы конфигурации. Или найдите какую-нибудь стратегию, чтобы перенести их в bakc. Рабочий процесс будет выглядеть так:

• Остановите apache
• Переместите все текущие каталоги и файлы prod на корневой уровень, кроме файла(ов) config
• Переместите все новые каталоги и файлы prod на корневой уровень, кроме файла(ов) config
• Запустите apache

6) Попытайтесь найти идеальное расположение отдельных файлов и каталогов и идеальный рабочий процесс. Это займет некоторое время и размышления, но это окупится. Делайте это на листе бумаги, пока не найдете лучшее решение. Это может означать, что вам придется рефакторить ваш код и изменить конфигурационные файлы сервера, но в будущем ваша жизнь станет проще при администрировании и обновлении. Из моего опыта: не ждите так долго с этим шагом. Ваш макет должен сделать обновление простым и безопасным. Обновление - это не что-то экстраординарное, это рутина, и оно должно быть безопасным и простым.

7) Если вы назовете среду вашего сервера и рабочей станции (операционная система сервера - linux, я полагаю, но это хостируемый или корневой сервер, есть ли у вас ftp-доступ или также shell (ssh) доступ, или sftp? где вы разрабатываете, на машине windows или mac?), тогда люди смогут назвать инструменты для копирования и перемещения. Также интересно: Является ли тестовый и рабочий сервер одной и той же машиной, если нет, то как они подключены, или нет? Если нет, то вы бы сделали 3-сторонний перенос (Скопировали на локальную рабочую станцию, а затем на сервер).

8) Подумайте о разрешениях на файлы. Если вы перемещаете файлы или копируете их, возможно, разрешения файлов меняются, и если приложение зависит от некоторых из них, должен быть способ проверить и, возможно, изменить. Пример: Некоторым приложениям нужны доступные для записи каталоги, куда они помещают загруженные файлы, файлы сессий или кэширования шаблонов. Другие приложения не позволяют записывать некоторые файлы в целях безопасности.