LINUX.ORG.RU
ФорумAdmin

как организовываются тестовые сервера?


0

1

Привет!

Как организовывается тестирование обновлений (или любых других изменений ПО) на серверах?

Например, есть несколько серверов (несколько десятков/сотен/тысяч). Все они обеспечивают какую-либо работу в компании.
Приезжают обновления системы. Никто в здравом уме не станет накатывать обновления на все эти сервера, не проверив, останется ли всё работоспособным после применения этих обновлений.

Вопрос в том, как происходит эта самая проверка?
Я понимаю, если сервер один-два: поднял локальную виртуальную машину с таким же содержимым, как и на «боевом» сервере, да протестировал. А если серверов много?

Что вообще используется в таких случаях? Может быть какие-то специализированные тесты?
Или парсятся логи, например, на предмет нестандартных записей (ошибки, уведомления)?

★★★★★

Ответ на: комментарий от minakov

minakov

а я хостинг юзаю с php4. Наверное чуть реже обновляют ради аптайма


Хостинг - это хостинг. Но на самом хостинге же тестируют всё хозяйство.
Вот и интересует как они это делают.

blackst0ne ★★★★★
() автор топика
Ответ на: комментарий от blackst0ne

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

anonymous
()
Ответ на: комментарий от anonymous

Блин, прошу прощения за ошибки с падежом в сообщении выше. Неужели так сложно сделать как это сделано на rulinux.net - чтобы все могли исправлять опечатки после отправки поста?

anonymous
()
Ответ на: комментарий от anonymous

тестируется посредством прогона тесткейсов

Ага, почитал про test cases. А есть какие-нибудь уже готовые test cases для определённых ОС? Ну понятно, что они не будут работать при сильной кастомизации, но, например, для «ванильных» случаев.

Грубо говоря, есть nginx версии 1. Приезжает обновление nginx версии 1.1. Есть ли какие-нибудь уже готовые test cases, которые можно прогнать на предмет работоспособности новой версии 1.1?

blackst0ne ★★★★★
() автор топика
Ответ на: комментарий от blackst0ne

Ты же не разрабатываешь ОС или nginx? Вот и гоняй СВОИ тест-кейсы - тестируй СВОЙ функционал на ихней ОС или nginx. А свои тесткейсы они должны гонять сами перед тем как высылать тебе обновления. Кастомизация - это то, что ты гоняешь на этих платформах. Никто не предполагает что ты вносишь изменения в платформу: разработчики ОС тестируют свою ОС на железе, разрабы nginx тестируют nginx на ОС, а ты своё приложение для nginx тестируешь на своём конкретном железе, с новой версией ОС и/или новой версией nginx - и после этого принимаешь решение следует ли переходить на новую версию или всё умрёт нафиг и надо рейзить баг-репорты и дожидаться пока твою проблему исправят.

anonymous
()
Ответ на: комментарий от anonymous

Ты же не разрабатываешь ОС или nginx? Вот и гоняй СВОИ тест-кейсы - тестируй СВОЙ функционал на ихней ОС или nginx. А свои тесткейсы они должны гонять сами перед тем как высылать тебе обновления. Кастомизация - это то, что ты гоняешь на этих платформах. Никто не предполагает что ты вносишь изменения в платформу: разработчики ОС тестируют свою ОС на железе, разрабы nginx тестируют nginx на ОС, а ты своё приложение для nginx тестируешь на своём конкретном железе, с новой версией ОС и/или новой версией nginx - и после этого принимаешь решение следует ли переходить на новую версию или всё умрёт нафиг и надо рейзить баг-репорты и дожидаться пока твою проблему исправят.



Я правильно понял, что в каждом случае создаются конкретные custom test cases?
Т.е. каждый системный администратор для своих конкретных нужд разрабатывает и применяет свои конкретные test cases?

blackst0ne ★★★★★
() автор топика

Тесты, тесты, тесты. Руками. Автоматизированно. Общие тесты на нормальные HTTP ответы на определенных URL'ах. Юнит-тесты конкретного приложения.

Если серверов много, то все они должны быть одинаковыми. И проверка, очевидно производится на серверах специально выделенных для тестинга. Ещё иногда делают pre-stable.

ei-grad ★★★★★
()
Ответ на: комментарий от ei-grad

>Если серверов много, то все они должны быть одинаковыми.

+1

drBatty ★★
()

Для рхела обычно делают свою репу с фиксированными обновлениями, потом с нее обновляют тесты и девы, гоняют сколько влезет разными тестами, потом с него обновляют прод. На личном опыте было два случая, когда после обновления ОС и всех стадий тестирования, обновления с существенными регрессиями вкатывали на прод. Один раз на линуксе, другой раз на аиксе, в обоих случаях увеличивалось использование CPU с 10-20% до 90%, но почему-то никто этого не заметил своевременно. На аиксе кстати ИБМ потом 2 месяца мурыжил пока не нашли в чем причина.

prizident ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.