Возник вопрос, как делает народ и как делать по фен шую.
Есть организация. Есть множество проектов. Для каждого проекта нужен дев стенд, нужен тестовый стенд, нужен стенд нагрузочного тестирования и тому подобное. Плюс сервера сборки, сервера документации, веб сайт организации и тому подобное.
Вопрос — как физически организовывать тестовые стенды проектов? Если хостить на одном мощном стенде и гонять под виртуалками, получается довольно дешево и легко администрировать. Но есть бяки — если что где то тормозит, хрен поймешь где и что. Что то будет ресурсоемкое на параллельной виртуалке, или бекап будет запущен — будут жутчайшие тормоза, и хрен поймешь что тормозит. Будет писаться что приложение жрет 100 процентов процессора, при этом там только сервер приложений запускается, до кода там вообще не дошло еще. А мат стоит черти какой. Аналогично если жутчайшие тормоза (грубо говоря запущен бакап виртуалок, плюс антивирус, плюс кто то на параллельной виртуалке нагрузочным тестированием решит полобоваться) — будут на других виртуалках такие тормоза, что аж коннект может пропадать. Некоторые (хотя какие некоторые — практически большинство) уже у заказчика даже прод разворачивают на виртуалке, и снова периодически мат на тормоза, что у вас сервер недоступен, у вас руки кривые, сервер внешне ничего ваш не делает, а загрузка процессора аж 100 процентов и все такое?
Как вообще народ поступает? По железной машине на стенд дороговато во всех смыслах ведь. Проектов до черта, там то один, то другой, когда нужно 30 стендов, когда 10, а когда и вообще 100. Задолбаешься то закупать машины, то отказываться от услуг. Зато производительность честная получается, можно и с профайлером погонять, и оптимизировать.
Здравствуйте, elmal, Вы писали:
E>Есть организация. Есть множество проектов. Для каждого проекта нужен дев стенд, нужен тестовый стенд, нужен стенд нагрузочного тестирования и тому подобное. Плюс сервера сборки, сервера документации, веб сайт организации и тому подобное.
E>Вопрос — как физически организовывать тестовые стенды проектов? Если хостить на одном мощном стенде и гонять под виртуалками, получается довольно дешево и легко администрировать. Но есть бяки — если что где то тормозит, хрен поймешь где и что. Что то будет ресурсоемкое на параллельной виртуалке, или бекап будет запущен — будут жутчайшие тормоза, и хрен поймешь что тормозит. Будет писаться что приложение жрет 100 процентов процессора, при этом там только сервер приложений запускается, до кода там вообще не дошло еще. А мат стоит черти какой. Аналогично если жутчайшие тормоза (грубо говоря запущен бакап виртуалок, плюс антивирус, плюс кто то на параллельной виртуалке нагрузочным тестированием решит полобоваться) — будут на других виртуалках такие тормоза, что аж коннект может пропадать. Некоторые (хотя какие некоторые — практически большинство) уже у заказчика даже прод разворачивают на виртуалке, и снова периодически мат на тормоза, что у вас сервер недоступен, у вас руки кривые, сервер внешне ничего ваш не делает, а загрузка процессора аж 100 процентов и все такое?
E>Как вообще народ поступает? По железной машине на стенд дороговато во всех смыслах ведь. Проектов до черта, там то один, то другой, когда нужно 30 стендов, когда 10, а когда и вообще 100. Задолбаешься то закупать машины, то отказываться от услуг. Зато производительность честная получается, можно и с профайлером погонять, и оптимизировать.
performance tests/load tests должны работать отдельно от всего остального, на отдельном железе, притом эксклюзивно — только один прогон в каждый момент времени, остальные — в очередь. Иначе хрен разберёшься, почему ВНЕЗАПНО поменялась производительность, кто виноват и что делать. А то что прогон каких-нибудь там юнит-тестов вдруг занял 10 минут вместо 5 — не обращать внимания.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, elmal, Вы писали:
E>Возник вопрос, как делает народ
Крупная международная корпорация, внутренняя разработка для нужд компании:
1. Используется термин "окружение" (environment). Есть окружения четырех типов с разными владельцами и разным SLA — изолированные (dev, CI, app SQA), интеграционные (staging, pre-production) и пром.эксплуатация (production).
2. Изолированные окружения содержат только одну систему плюс набор эмуляторов других систем: на них тестируется только эта система и ее интеграционные контракты. Dev окружение используется разработчиками для жесткой отладки и тестирования. CI — окружение непрерывной интеграции, на котором система развертывается после сборки и запускаются базовые приемочные тесты (написанные командой SQA на Selenium). Это окружение слабое, может значительно отличаться конфигурацией от боевого и не предполагает масштабного тестирования — только набор из 4-5 основных сценариев (полная регрессия бегает несколько часов, что неприемлемо для CI).
3. Изолированное окружение App SQA служит для интенсивного первичного автоматического и ручного тестирования продуктовыми командами SQA — его конфигурация отличается от боя по производительности в 3-4 раза, по объему хранилища данных значительно (на 2 порядка). Есть документ, показывающий приемлемость такой конфигурации. Здесь мы иногда гоняем тесты производительности, чтобы выявить неожиданные узкие места: изолированное окружения для этого отлично подходит, поскольку эмуляторы не содержат логики и влияние внешних систем на производительность исключено.
4. Интегрированные окружения типа staging служат для интеграционного автоматического и ручного тестирования соответствующей командой SQA — здесь проверяется работоспособность бизнес-сценариев на всем ансамбле систем и проводятся демо для бизнес-пользователей. Конфигурация может отличаться от боевой по производительности. Здесь есть тестовые копии ERP, CRM и систем управления производством. Есть документ, показывающий приемлемость такой конфигурации.
5. Pre-production служит для тестирования бизнес-пользователями и имеет конфигурацию, аналогичную боевой. Здесь также выполняются основные тесты производительности. Это окружение соответствует требованиям к процессу контроля качества FDA, и наполняется данными, близкими к реальным.
В год случается до десяти релизов, затрагивающих различные системы и связанных с десятками активных проектов, соответственно, вся эта инфраструктура заточена на параллельную разработку разных версий.
У нас используется слабая матричная структура управления проектами в терминах PMBoK, и есть выделенный менеджер проектов, управляющий календарем развертывания версий ПО на этих окружениях. Он координирует работу других PMов и функциональных команд в вопросах, связанных с деплойментом.
Есть выделенная команда DevOps, отвечающая за все окружения кроме боевого. Есть команда IT Ops, отвечающая за боевое окружение.
Команда DevOps использует различные инструменты для автоматизации деплоймента (Chef) и мониторинга состояния окружений (тут я даже не владею актуальной информацией — процесс очень живой).
И последнее: все окружения построены на виртуалках — специфических проблем связанных именно с этим у нас нет. Причем, не все виртуалки хостятся локально — часть уже переехала во внешние облака.
