Продолжение истории о борьбе с деградацией производительности сборочного сервера.
В прошлой заметке я остановился на том напряежённом моменте, когда специалист из IT-отдела признал их ответственность за деградацию производительности сервера и даже подтвердил то письмом.
С одной стороны это было хорошо, так как дало нам определенный козырь в переговорах с ними, но это так же было и плохо, так как корневая причина деградации оказалась вне моей зоны влияния. Любые мои попытки оптимизировать сборку путем перенастройки сборочного сервера или скриптов были лишь симптоматическим лечением и имели ограниченный потенциал. Корневая проблема - деградация виртуальной инфраструктуры - находилась во владениях другого отдела и была мне неподвластва. Конечно же, вопрос о качестве инфраструктуры был поднят, но решение его в разумные сроки нам не даже обещали.
Впрочем, временное средство для облегчения ситуации со сборкой всё же было найдено. Раз сеть замедляла обращение к виртуальному диску, расположенному вне хоста, надо было заменить этот "трудный" ресурс чем-то, расположенным внутри хоста, чего было в достатке. Очевидным стало решение с переносом сборки на RAM disk.
Чтобы это решение "взлетело", пришлось решить две небольшие проблемы:
1. Поскольку объем виртуального диска был ограничен, пришлось подправить build process workflow таким образом, чтобы он удалял все файлы после сборки.
2. Сборка вызывала много активности во временном каталоге (например, инструментарий WiX этим отличился), так что пришлось и его перенаправить на RAM disk.
Эти оптимизации позволили на время снизить время сборки до изначальных пяти минут, хотя оно практически сразу же стало деградировать снова. В конечном итоге, все оптимизации, которые можно было провести за разумные средства в пределах нашего проекта были исчерпаны и пришлось искать какие-то новые идеи для решения проблемы ухудшающейся производительности.
Эти идеи нашлись в форме использования тех ресурсов, которые оказались в нашем распоряжении практически случайно. У нас остались рабочии станции двух уволившихся ранее сотрудников, о которых наши IT-шники попросту забыли. Нет худа без добра: безалаберность их отдела, приведшая к бедам на виртуальной инфраструктуре, открыла нам нетрадиционную возможность для решения наших проблем :)
Эти компьютеры были переналажены как физические сборочный и тестовый стенды. Это дало нам некоторую передышку, которую мы используем для того, чтобы дожать IT-отдел, чтобы он привел виртуальную инфраструктуру в порядок и добиться полностью правильного решения проблемы.
В прошлой заметке я остановился на том напряежённом моменте, когда специалист из IT-отдела признал их ответственность за деградацию производительности сервера и даже подтвердил то письмом.
С одной стороны это было хорошо, так как дало нам определенный козырь в переговорах с ними, но это так же было и плохо, так как корневая причина деградации оказалась вне моей зоны влияния. Любые мои попытки оптимизировать сборку путем перенастройки сборочного сервера или скриптов были лишь симптоматическим лечением и имели ограниченный потенциал. Корневая проблема - деградация виртуальной инфраструктуры - находилась во владениях другого отдела и была мне неподвластва. Конечно же, вопрос о качестве инфраструктуры был поднят, но решение его в разумные сроки нам не даже обещали.
Впрочем, временное средство для облегчения ситуации со сборкой всё же было найдено. Раз сеть замедляла обращение к виртуальному диску, расположенному вне хоста, надо было заменить этот "трудный" ресурс чем-то, расположенным внутри хоста, чего было в достатке. Очевидным стало решение с переносом сборки на RAM disk.
Чтобы это решение "взлетело", пришлось решить две небольшие проблемы:
1. Поскольку объем виртуального диска был ограничен, пришлось подправить build process workflow таким образом, чтобы он удалял все файлы после сборки.
2. Сборка вызывала много активности во временном каталоге (например, инструментарий WiX этим отличился), так что пришлось и его перенаправить на RAM disk.
Эти оптимизации позволили на время снизить время сборки до изначальных пяти минут, хотя оно практически сразу же стало деградировать снова. В конечном итоге, все оптимизации, которые можно было провести за разумные средства в пределах нашего проекта были исчерпаны и пришлось искать какие-то новые идеи для решения проблемы ухудшающейся производительности.
Эти идеи нашлись в форме использования тех ресурсов, которые оказались в нашем распоряжении практически случайно. У нас остались рабочии станции двух уволившихся ранее сотрудников, о которых наши IT-шники попросту забыли. Нет худа без добра: безалаберность их отдела, приведшая к бедам на виртуальной инфраструктуре, открыла нам нетрадиционную возможность для решения наших проблем :)
Эти компьютеры были переналажены как физические сборочный и тестовый стенды. Это дало нам некоторую передышку, которую мы используем для того, чтобы дожать IT-отдел, чтобы он привел виртуальную инфраструктуру в порядок и добиться полностью правильного решения проблемы.
А какие тулы вы используете для CI?
ОтветитьУдалитьПривет.
УдалитьTFS 2013, вся сборка на нём.