Предыстория
До недавнего времени я работал эникейщиком в крупной российской компании, имеющей множество офисов по всей стране. В моём ведении были одиннадцать площадок, находящихся в разных городах Дальнего востока (это важно). В каждом из этих офисов была своя, не связанная с другими, сетевая инфраструктура — свой домен AD, своя подсеть и т.д.
Однажды руководство поставило мне задачу организовать процесс автоматического обновления ОС и программ от MS и разрешило развернуть на подотчётных площадках WSUS.
Проблема
После того, как WSUS был развернут, политики привязки компьютеров к группам WSUS настроены, синхронизация каталогов содержимого с серверами MS проведена и т.п., возник вопрос: а кто же, и, главное, как, будет одобрять обновления?
Представьте себе: 11 городов, связь с которыми настолько «быстра» и «стабильна», что редкие минуты, когда задержки ICMP-ответов составляют всего 800 мс, воспринимаются, как неслыханное везение. И в каждом необходимо проводить тестирование всех обновлений перед развертыванием. При этом доступ к серверам на площадках был только по RDP, т.е. нужно было еженедельно (распоряжение устанавливало именно такую периодичность) подключаться к серверу каждого города и вручную одобрять использование новых обновлений в тестовых группах и, соответственно, переводить испытанные обновления в промышленную эксплуатацию:
Читать полностью »
Эта статья написана по мотивам одноименного доклада на Highload++'2012. Предназначена она для руководителей, которые смогут, взглянув на наше тестирование, сравнить его с тестированием в своем проекте, для программистов и системных администраторов, которым представится возможность посмотреть на тестирование как на очень интересную работу, и, конечно, для тестировщиков.