http://bestblog.name/2010/01/sync-dev-and-live-sites/ Блог web-developer'а Sat, 17 Jul 2010 05:43:08 +0400 http://wordpress.org/?v=2.8.4 hourly 1 http://bestblog.name/2010/01/sync-dev-and-live-sites/comment-page-1/#comment-2384 Cypedeert Sun, 02 May 2010 16:08:47 +0000 http://bestblog.name/?p=132#comment-2384 Здравствуйте. Автор, скажите вы из какого города? Если не секрет :) Здравствуйте. Автор, скажите вы из какого города? Если не секрет :)

]]> http://bestblog.name/2010/01/sync-dev-and-live-sites/comment-page-1/#comment-1391 yas Fri, 08 Jan 2010 10:33:39 +0000 http://bestblog.name/?p=132#comment-1391 ну live держать под svn не очень хорошо. могут быть проблемы с безопасностью (http://habrahabr.ru/blogs/infosecurity/70330/). плюс получается, что тогда для каждого клиентского сайта создавать еще и аккаунт к нашему svn? мы рассматривали такой вариант работы, но всё же пришли к тому, что это не очень хорошо. на live должно быть всё чистенько и аккуратно. Тем более, что в svn я могу и какую-то инфу хранить, которой на live быть не должно. А именно скрипты вспомогательные, дамп базы... базу каждый раз я не синхронизирую. Но иногда удобно забрать базу с клиентского сайта и у себя её развернуть. например приходит задача, что клиент хочет, чтобы когда на странице выводится 30 статей, то должен быть paging. Ну и мне надо его включить, оформить (если до этого не делался paging), ну и проверить. Так проще забрать базу клиента и у себя развернуть, чтобы не надо было создавать кучу тестового материала. А иногда может быть, что клиент жалуется на какие-то глюки на живом сайте, тогда тоже удобнее развернуть полную копию сайта для тестирования и исправления. Ну и еще один момент: я дамп базы в svn храню. С каждым более-менее крупным каким-то изменением на сайте я бэкаплю и базу. Просто с drupal у меня были когда-то случаи, когда сайт просто падал, база ложилась (уже не помню из-за чего, т.к. давно это было). Ну и после того у меня выработалась какая-то параноя и я бэкаплю дамп базы теперь периодически ) Плюс т.к. друпаль все настройки хранит в базе. То в случае если клиент чего-нибудь наменяет в настройках на сайте и там что-нибудь не понятно вдруг сломается (или например он удалит views какой-нибудь большой с сложный), то мне будет проще вытянуть из svn определённую ревизию, развернуть у себя и сравнить в ручную настройки в админке (ну или сделать у себя экспорт, а на live импорт необходимого views'а). Таких ситуаций у меня, правда, еще не было, но я уже подстраховался =) ну live держать под svn не очень хорошо. могут быть проблемы с безопасностью (http://habrahabr.ru/blogs/infosecurity/70330/). плюс получается, что тогда для каждого клиентского сайта создавать еще и аккаунт к нашему svn? мы рассматривали такой вариант работы, но всё же пришли к тому, что это не очень хорошо. на live должно быть всё чистенько и аккуратно. Тем более, что в svn я могу и какую-то инфу хранить, которой на live быть не должно. А именно скрипты вспомогательные, дамп базы…
базу каждый раз я не синхронизирую. Но иногда удобно забрать базу с клиентского сайта и у себя её развернуть. например приходит задача, что клиент хочет, чтобы когда на странице выводится 30 статей, то должен быть paging. Ну и мне надо его включить, оформить (если до этого не делался paging), ну и проверить. Так проще забрать базу клиента и у себя развернуть, чтобы не надо было создавать кучу тестового материала. А иногда может быть, что клиент жалуется на какие-то глюки на живом сайте, тогда тоже удобнее развернуть полную копию сайта для тестирования и исправления.
Ну и еще один момент: я дамп базы в svn храню. С каждым более-менее крупным каким-то изменением на сайте я бэкаплю и базу. Просто с drupal у меня были когда-то случаи, когда сайт просто падал, база ложилась (уже не помню из-за чего, т.к. давно это было). Ну и после того у меня выработалась какая-то параноя и я бэкаплю дамп базы теперь периодически )
Плюс т.к. друпаль все настройки хранит в базе. То в случае если клиент чего-нибудь наменяет в настройках на сайте и там что-нибудь не понятно вдруг сломается (или например он удалит views какой-нибудь большой с сложный), то мне будет проще вытянуть из svn определённую ревизию, развернуть у себя и сравнить в ручную настройки в админке (ну или сделать у себя экспорт, а на live импорт необходимого views’а). Таких ситуаций у меня, правда, еще не было, но я уже подстраховался =)

]]> http://bestblog.name/2010/01/sync-dev-and-live-sites/comment-page-1/#comment-1389 ShkilionOK Fri, 08 Jan 2010 01:35:06 +0000 http://bestblog.name/?p=132#comment-1389 Виктор, а почему нельзя поставить и production (или live) под контроль SVN? Черепашка делает все то же самое, только в интерактивном режиме. и не понял, зачем каждый раз базу синхронизировать? Какая для необходимость в этом для staging'а? Виктор, а почему нельзя поставить и production (или live) под контроль SVN? Черепашка делает все то же самое, только в интерактивном режиме.
и не понял, зачем каждый раз базу синхронизировать? Какая для необходимость в этом для staging’а?

]]>