Красная линия (forecast) строится на основе реальной ежедневной производительности команды (day velocity). Можно использовать производительность последнего дня, можно брать усредненную за какой-то промежуток. Мы используем усреднение за две недели (усреднение для большего промежутка времени дает примерно тот же результат).
Например, у нас есть команда из трех человек, которая суммарно за вчера «освоила» 16 часов (6+5+5). За позавчера — 17, за позапозавчера -14 и т.д. Берём среднее значение за этот промежуток времени (например, получилось 15). Соответственно при генерации красной линии (forecast) мы будем считать, что каждый последующий день у нас команда будет «осваивать» 15 часов от общего объёма работ.
> 1. Оси на вирталки чем разливаются?
Для тех серверов, где используется virtuozzo, при настройке сервера уже установлены осевые темплэйты, следовательно машинка очень быстро создаётся на этом же сервере без какого-либо дополнительного заливания… Запуск инициируется через ssh к хардварной ноде.
Для тех серверов, где, например, используются kvm или vmware, копии «эталонных» дампов осей заливаются со специального storage server по ssh, там они разворачиваются и переконфигуряются (смена ip адреса и тд). Для экономии времени на копирование дампа по сети у сервера есть так называемый «кэш», где хранятся эти дампы.
> 2. Билд на тест машины как заливаются?
Большинство продуктов у нас имеют свои автоинсталлеры, которые сами с разных репозиториев стягивают нужные им для установки продуктов. Если же автоинсталлера нет, но продукт заливается по ssh (то же касается самого автоинсталлера).
>3. Вся система в одном офисе или в нескольких?
Физически все сервера и люди, занимающиеся разработкой «начинки» облака находятся в одном офисе. Но ничего не мешает подключать сервера, расположенные географически в любом другом месте. Само облако и весь его функционал так же доступны из любой точки мира.
4. На виртуальных машинах демон живёт, с которым Test executor общается или как?
Если речь идёт про взаимодействие Test executor и виртуальной машинки (машинок), на которой установлен продукт, то Test executor на своей стороне запускает тесты, которое уже взаимодействуют с системой (сервисами), установленной на виртуальной машинке, и с интерфейсами (API, GUI, CLI), предоставляемыми продуктом.
Если в двух словах, то наш load balancer при выборе наиболее подходящего сервера учитывает следующие аспекты:
— аппаратные характеристики сервера (сколько именно виртуальных машинок с определёнными параметрами одновременно может быть запущено на нем);
— тип виртуализации, используемый на сервере;
— количество запущенных в данный момент виртуальных машинок на этом сервере;
— наличие идущих в данный момент «тяжёлых» задач на этом сервере (например, разворачивание дампов и инсталляция продуктов на них);
— наличие нужного дампа оси в кэше у сервера (например, экономия на передаче по сети дампа kvm или vmware машинки);
— и т.д.
Безусловно в этот будут свои огромные плюсы, но и забывать о минусах не стоит:
— высокая стоимость при большом потреблении ресурсов, которое будет возникать при интенсивном тестировании;
— конфиденциальность (готовы ли вы доверить инновационную идею и исходники своего продукта внешнему облаку?);
— неполный сет конфигураций (внешнее облако может не поддерживать весь сет конфигураций, которые обязан поддерживать ваш продукт)…
> Как создать такое облако для тестирование?
В конце статьи я перечислил верхнеуровневый список шагов по тому как создать облако с нуля. Видимо, вам хочется больше технических деталей. Расписать их все в комментариях не получится. Можно либо дождаться следующего поста, основанного на ваших вопросах, либо конкретизировать вопрос.
> Во сколько это обойдется? Если это дорого, то как выходить из положения стартапам, которые вы упомянули?
Все очень сильно зависит от задач, которые вы хотите решать с помощью облака и специфики ваших продуктов. Если вы маленький стартап с одним продуктом, который хочется тестировать автоматически, то можно начать с малого: взять один два сервера (либо использовать рабочие станции сотрудников в ночное время), развернуть на них системы виртуализации, написать скрипты по созданию виртуальных машинок, установке продуктов, запуску тестов… Решение маленьких задач будет стоить мало — пара серверов и месяц-два работы одного человека.
> Где взять такую панель?
Имеется ввиду нашу панель по управлению облаком или что-то аналогичное?
> Сколько ресурсов занимает каждая виртуальная машина, и, соответственно, как узнать, сколько серверов мне понадобится?
Зависит от:
— требований вашего продукта (например, мы знаем, что для нормальной работы продукта под среднестатистической нагрузкой, которую создают тесты, нам нужна машинка с 512Mb оперативной памяти и 2Gb дискового пространства, примерно такие мы и будем создавать),
— используемого для сервера железа (чем сервер мощнее, тем больше машинок на нем можно развернуть),
— типа виртуализации (у каждого типа виртуализации есть свои плюсы и минусы, в том числе, какие-то из них более прожорливы, чем другие),
— платформы (например, виндовых машинок на одном сервере удастся развернуть меньше)…
У нас в пуле на начальном этапе было много серверов, способных держать только по 4-8 машинок. Со временем мы добавляли туда более мощные сервера, способные держать по 50 виртуальных машинок, постепенно заменяя более слабые.
Continuous Integration — это лишь один из сценариев, которые нам позволяет реализовывать облако. Он был выбран, чтобы показать взаимодействие большинства узлов облака между собой.
Помимо него есть и такие сценарии, как:
— создание машинки (группы машинок) с нужными характеристиками, типом виртуализации, операционной системы;
— автоматическая установка продуктов на машинку/группу машин (в случае мультисерверных продуктов);
— запуск тест-плана с выбором наименее загруженных серверов и последующим распараллеливанием его исполнения между ними;
— performance-, density-, load-тестирование;
— и т.д.
Глава про Load balancer будет в отдельном посте вместе с другими главами, отвечающими на вопросы в комментариях.
Аудитория Хабра очень разнородная, у каждого свой багаж знаний и умений.
Я ориентировался на общий обзор нашего облака, который потом дополню информацией, исходя из вопросов заинтересовавшихся. Полное описание всех аспектов могло бы превратиться в маленькую книгу.
Например, у нас есть команда из трех человек, которая суммарно за вчера «освоила» 16 часов (6+5+5). За позавчера — 17, за позапозавчера -14 и т.д. Берём среднее значение за этот промежуток времени (например, получилось 15). Соответственно при генерации красной линии (forecast) мы будем считать, что каждый последующий день у нас команда будет «осваивать» 15 часов от общего объёма работ.
Для тех серверов, где используется virtuozzo, при настройке сервера уже установлены осевые темплэйты, следовательно машинка очень быстро создаётся на этом же сервере без какого-либо дополнительного заливания… Запуск инициируется через ssh к хардварной ноде.
Для тех серверов, где, например, используются kvm или vmware, копии «эталонных» дампов осей заливаются со специального storage server по ssh, там они разворачиваются и переконфигуряются (смена ip адреса и тд). Для экономии времени на копирование дампа по сети у сервера есть так называемый «кэш», где хранятся эти дампы.
> 2. Билд на тест машины как заливаются?
Большинство продуктов у нас имеют свои автоинсталлеры, которые сами с разных репозиториев стягивают нужные им для установки продуктов. Если же автоинсталлера нет, но продукт заливается по ssh (то же касается самого автоинсталлера).
>3. Вся система в одном офисе или в нескольких?
Физически все сервера и люди, занимающиеся разработкой «начинки» облака находятся в одном офисе. Но ничего не мешает подключать сервера, расположенные географически в любом другом месте. Само облако и весь его функционал так же доступны из любой точки мира.
4. На виртуальных машинах демон живёт, с которым Test executor общается или как?
Если речь идёт про взаимодействие Test executor и виртуальной машинки (машинок), на которой установлен продукт, то Test executor на своей стороне запускает тесты, которое уже взаимодействуют с системой (сервисами), установленной на виртуальной машинке, и с интерфейсами (API, GUI, CLI), предоставляемыми продуктом.
— аппаратные характеристики сервера (сколько именно виртуальных машинок с определёнными параметрами одновременно может быть запущено на нем);
— тип виртуализации, используемый на сервере;
— количество запущенных в данный момент виртуальных машинок на этом сервере;
— наличие идущих в данный момент «тяжёлых» задач на этом сервере (например, разворачивание дампов и инсталляция продуктов на них);
— наличие нужного дампа оси в кэше у сервера (например, экономия на передаче по сети дампа kvm или vmware машинки);
— и т.д.
— высокая стоимость при большом потреблении ресурсов, которое будет возникать при интенсивном тестировании;
— конфиденциальность (готовы ли вы доверить инновационную идею и исходники своего продукта внешнему облаку?);
— неполный сет конфигураций (внешнее облако может не поддерживать весь сет конфигураций, которые обязан поддерживать ваш продукт)…
В конце статьи я перечислил верхнеуровневый список шагов по тому как создать облако с нуля. Видимо, вам хочется больше технических деталей. Расписать их все в комментариях не получится. Можно либо дождаться следующего поста, основанного на ваших вопросах, либо конкретизировать вопрос.
> Во сколько это обойдется? Если это дорого, то как выходить из положения стартапам, которые вы упомянули?
Все очень сильно зависит от задач, которые вы хотите решать с помощью облака и специфики ваших продуктов. Если вы маленький стартап с одним продуктом, который хочется тестировать автоматически, то можно начать с малого: взять один два сервера (либо использовать рабочие станции сотрудников в ночное время), развернуть на них системы виртуализации, написать скрипты по созданию виртуальных машинок, установке продуктов, запуску тестов… Решение маленьких задач будет стоить мало — пара серверов и месяц-два работы одного человека.
> Где взять такую панель?
Имеется ввиду нашу панель по управлению облаком или что-то аналогичное?
> Сколько ресурсов занимает каждая виртуальная машина, и, соответственно, как узнать, сколько серверов мне понадобится?
Зависит от:
— требований вашего продукта (например, мы знаем, что для нормальной работы продукта под среднестатистической нагрузкой, которую создают тесты, нам нужна машинка с 512Mb оперативной памяти и 2Gb дискового пространства, примерно такие мы и будем создавать),
— используемого для сервера железа (чем сервер мощнее, тем больше машинок на нем можно развернуть),
— типа виртуализации (у каждого типа виртуализации есть свои плюсы и минусы, в том числе, какие-то из них более прожорливы, чем другие),
— платформы (например, виндовых машинок на одном сервере удастся развернуть меньше)…
У нас в пуле на начальном этапе было много серверов, способных держать только по 4-8 машинок. Со временем мы добавляли туда более мощные сервера, способные держать по 50 виртуальных машинок, постепенно заменяя более слабые.
Помимо него есть и такие сценарии, как:
— создание машинки (группы машинок) с нужными характеристиками, типом виртуализации, операционной системы;
— автоматическая установка продуктов на машинку/группу машин (в случае мультисерверных продуктов);
— запуск тест-плана с выбором наименее загруженных серверов и последующим распараллеливанием его исполнения между ними;
— performance-, density-, load-тестирование;
— и т.д.
Глава про Load balancer будет в отдельном посте вместе с другими главами, отвечающими на вопросы в комментариях.
Я ориентировался на общий обзор нашего облака, который потом дополню информацией, исходя из вопросов заинтересовавшихся. Полное описание всех аспектов могло бы превратиться в маленькую книгу.