Рекомендации по обновлению сервера сборки

Question

Как парень, который часто переключается между QA, сборкой и операциями, я постоянно сталкиваюсь с вопросом, что делать с обновлениями операционной системы на сервере сборки. Дихотомия одинакова для Windows, Linux, MacOS или любых других операционных систем, которые могут обновляться через Интернет:

• Команда QA хочет сохранить сервер сборки таким, какой он есть, от начала цикла выпуска продукта до конца, так как установка обновлений может дестабилизировать сервер и означает, что последовательные сборки не выполняются с той же базовой линией.
• Команда ops хочет, чтобы программное обеспечение было развернуто в системе со всеми последними обновлениями безопасности; это может означать, что программное обеспечение не развернуто на той же версии операционной системы, на которой оно было построено.

Обычно я смягчаю это, беря версии-кандидаты на сборку и устанавливая их на тестовом сервере с полностью обновленными версиями, повторяя автоматические тесты, выполняемые на сервере сборки, и проводя дополнительное тестирование на уровне системы. чтобы убедиться, что все выглядит хорошо перед развертыванием. Тем не менее, это кажется мне неэффективным; у кого-нибудь есть способ получше?

Answer 1

Лично я не думаю, что у вас есть большая проблема здесь - просто примените последние обновления к серверу сборки. Основные причины, по которым я говорю это:

• очень маловероятно, что ваш код или любая из зависимостей на сервере сборки настолько тесно связаны с версией ОС, что установка регулярных обновлений может повлиять на что-либо, не говоря уже о том, чтобы это сломать. Могут быть небольшие различия между оконными сообщениями и т. Д. Между версиями Windows, но они немногочисленны и далеко друг от друга, и, как правило, довольно хорошо документированы на веб-страницах. Если вы используете стеки управляемых технологий, такие как WPF / Silverlight или ASP.Net и даже в основном Winforms, то вы будете изолированы от этих изменений - они должны повлиять на вас, только если вы делаете хардкорные вещи, используя WinAPI непосредственно для создания ваших окон или рисования ваших окон. кнопки.

• Хорошая практика - всегда проектировать ваш продукт в соответствии с последней версией ОС, потому что вы должны поощрять своих клиентов также внедрять эти обновления - IOW, вы не должны быть в состоянии сказать на ваш клиент не устанавливать обновление xyz, потому что ваше приложение не будет работать с ним - особенно, если это обновление является критическим обновлением безопасности

• тестирование на наличие различий между версиями ОС должно проводиться командой QA и должно зависеть от того, что находится на сервере сборки

• вы не хотите, чтобы ваш сервер сборки входил в такое состояние, что он был настолько изолирован от процесса обновления компании, что, когда вы, наконец, применили их все, он повсеместно выплевывает и выплевывает расплавленный кремний. Таким образом, чем дольше вы ждете обновления, тем выше риск, что что-то пойдет не так и будет катастрофически. Небольшие и частые / инкрементные обновления имеют меньший риск, чем массовые обновления один раз в десятилетие:)

Обновления сервера сборки, к которым нужно относится с осторожностью, относятся к сторонним элементам управления или обновлениям библиотеки - они могут часто содержать критические изменения или значительно измененное поведение. Они действительно должны быть запланированы, а затем проведен раунд тестирования в поисках любых изменений.

Answer 2

Что ж, для наиболее стабильного процесса у меня было бы два сервера сборки: «Сборка с начальной конфигурацией, Сборка с обновлением конфигурации» и два сервера для автотестов с похожими различиями. Используйте виртуализацию, чтобы сделать это эффективно и в сценариях.

Answer 3

Отключите сервер сборки от сети, так что вам не нужно беспокоиться об установке обновлений безопасности. Загружайте источник только с компакт-диска, флэш-накопителя или любого другого средства.

Подключите его снова в конце цикла выпуска и затем разрешите все обновления.

Answer 4

Виртуализация!

Используя такие вещи, как VMWare Server, вы можете запрограммировать запуск и приостановку работы виртуальных машин. Таким образом, вы можете написать сценарий возобновления работы VM, запустить SSH, скопировать, приостановить VM, повторить. (Я говорю это, но я отказался от своей работы над этим. Тем не менее, я делал успехи в то время.)

Кроме того, вы можете доверять поставщикам ОС. Вы не можете?

Они заинтересованы в совместимости. Если вы используете Windows XP, она почти наверняка будет работать на XP SP3, Vista и Windows 7.

Если вы используете RedHat Enterprise 5, он лучше работает на 5.1, 5.2, 5.3, 5.4 и т. Д.

По моему опыту, до сих пор мне это удавалось, и я рекомендую использовать ваши самые низкие версии исправлений ОС. В частности, для Linux я обнаружил, что более новые выпуски связаны с более новыми библиотеками, недоступными в более старых версиях.

Конечно, не помешает проверить ваш код на копии сервера развертывания. Все зависит от того, насколько ты уверен в себе.