"production" web site

[Guest]

посоветуйте стратегию как лучше выкатывать "production" версию веб сайта

сейчас у меня есть маленькая linux машина на которой я разрабатываю этот сайт.
допустим это "development".
"production" бежать будет на выделенном сервере у какого нибудь провайдера.

пока у меня идея такая . поставить точно такую же OS, c тем же софтом как у провайдера на какой нибудь промежуточной машине "test". софт будет точно одинаковый а железа в "test" послабее.

новые версии сайта и все обновления выкатывать так:
development->test->production

есть ли какие-нибудь гениальные идеи на этот счет?
весь софт под линуксом, довольно стандартные штуки типа nginx, python, postgresql...

[from sergNN]

а в чём вопрос то ?

[Maus]

А нагрузку и вообще как тестировать собираешься? И потом, если чего не так вдруг, хорошо бы стратегию откатывания иметь, а не только накатывания.

[Guest]

А нагрузку и вообще как тестировать собираешься? И потом, если чего не так вдруг, хорошо бы стратегию откатывания иметь, а не только накатывания.

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

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

ну или тестировать лучше, чтоб назад не понадобилось

[mashka]

А нагрузку и вообще как тестировать собираешься? И потом, если чего не так вдруг, хорошо бы стратегию откатывания иметь, а не только накатывания.

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

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

ну или тестировать лучше, чтоб назад не понадобилось

Ну здасьте... У тебя что, "продакшн" в едином физическом/логичеком экземпляре что-ли????

[Guest]

Ну здасьте... У тебя что, "продакшн" в едином физическом/логичеком экземпляре что-ли????

и вам тоже здрасьте.
продакшн это то с чем конечные пользователи работают.

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

то с чем конечные пользовати работают - этого "1 штука"
а у вас как, товарищ машка?

[mashka]

Ну здасьте... У тебя что, "продакшн" в едином физическом/логичеком экземпляре что-ли????

и вам тоже здрасьте.
продакшн это то с чем конечные пользователи работают.

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

то с чем конечные пользовати работают - этого "1 штука"
а у вас как, товарищ машка?

"У нас Машек" как минимум в двойном количестве. Причем на разном железе.
Если, конечно, тебе важно 24/7.
Для тестирования можо в принципе одно физическое железо использовать, но разное виртуальное....

[Guest]

"У нас Машек" как минимум в двойном количестве. Причем на разном железе.
Если, конечно, тебе важно 24/7.
Для тестирования можо в принципе одно физическое железо использовать, но разное виртуальное....

не у меня не 24/7, обычный вебсайт. можно ночью повесить табличку "maintanance", минут так на 30

[mashka]

"У нас Машек" как минимум в двойном количестве. Причем на разном железе.
Если, конечно, тебе важно 24/7.
Для тестирования можо в принципе одно физическое железо использовать, но разное виртуальное....

не у меня не 24/7, обычный вебсайт. можно ночью повесить табличку "maintanance", минут так на 30

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

[Guest]

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

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