Как вы тестируете изменения в плагинах Jenkins перед их развертыванием?


14

Если вас когда-либо укусило обновление плагина, которое нарушало некоторые функциональные возможности, вы должны были задуматься над этой проблемой: какой должна быть политика обновления плагинов Jenkins? Как вы тестируете изменения перед их развертыванием?

Кто-нибудь зашел так далеко, что на тестовом экземпляре выполнялись фиктивные задания для тестирования новых версий, или вы просто молитесь, чтобы обновление версий ничего не сломало?


Вы имеете в виду командную политику Jeankins или политику вашей организации?
Дан

Я бы сделал снимок узла Jenkins перед обновлением и просто протестировал его. По моему опыту, Дженкинс никогда не был критически важным компонентом. Если он не работает в течение 15 минут из-за какого-либо обновления плагина, он обычно не блокирует производство, поэтому ручное вмешательство приемлемо. Конечно, если это не так для вас (а Дженкинс должен быть на 100% HA), это не правильный подход.
Ассаф Лави

@DanCornilescu моя политика организации, так как это для нашего внутреннего сервера Jenkins
Майкл Перейра

@AssafLavie Это в значительной степени зависит от того, как работает Jenkins: автономный сервер, виртуальная машина, контейнер докеров, модули kubernetes (в нашем случае). Может быть нелегко сделать снимок текущего состояния, чтобы восстановить его как есть. В нашем случае мы можем клонировать том EBS, содержащий данные Jenkins, но это ручной и трудоемкий процесс для восстановления как контейнера, так и тома данных до определенного состояния.
Майкл Перейра

Привет @MichaelPereira, если любой из двух ответов ниже решил ваш вопрос, пожалуйста, примите его , нажав на галочку. Это указывает более широкому сообществу, что вы нашли решение, и дает некоторую репутацию как ответчику, так и вам. Там нет обязательств сделать это. Если вы не чувствуете, что на ваш вопрос ответили, пожалуйста, не стесняйтесь общаться с авторами в комментариях.
Ричард Слейтер

Ответы:


4

В соответствии с политикой компании, в которой я работаю, у нас есть среды dev, preprod и prod (в некоторых сервисах dev может отсутствовать). И путь новой версии preprod-> tests-> validation-> prod.

В нашем случае задания в preprod достаточно тяжелые и достаточно сложные, чтобы быть уверенными, что нам не нужно молиться, когда они реализованы в prod :)

Примечание : мы используем SVN для поддержки и доставки конфигурации. Мы не вносим изменения на месте.


Как вы поддерживаете конфигурацию различных серверов Jenkins? Вручную?
Майкл Перейра

Мы используем SVN для поддержки и доставки конфигурации. Мы не
Ромео Нинов

Я чувствую, что это не совсем отвечает на вопрос полностью. Этот ответ описывает, как вы внедряете изменения, но не как вы тестируете изменения через конвейер развертывания.
Jayhendren

2

Нам нужна была 100% среда Дженкинса. мы часто обновляем плагины / сам Jenkins.

Это вызывает большую головную боль, если сборка ломается после обновления.

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

Мы создали отдельную (демонстрационную) виртуальную машину и повторили настройку продукта на демонстрационной виртуальной машине. Прежде чем что-либо менять / обновлять, мы бы сделали снимок обеих виртуальных машин. Затем мы будем тестировать обновления на демо-виртуальной машине. Если он работает хорошо, измените его на Prod.

Я думаю, вы можете посмотреть сообщество (например, SE / SO), если у кого-то возникли проблемы с плагином, который вы планируете.


0

Я всегда вручную запускаю один или два повторных запуска по крайней мере на одной недавней зеленой (или почти зеленой) метке для каждого соответствующего проекта / ветви, использующей соответствующий плагин, и проверяю, чтобы я получал одинаковые результаты. Просто чтобы быть на безопасной стороне.

Любое несоответствие результатов должно быть исследовано, чтобы определить, вызвано ли оно обновлением плагина или нет. Может быть, еще несколько повторов со старыми и новыми плагинами?


Конечно, нет проблем.
Дан

Из прошлого опыта мои мнения часто не так популярны, поэтому в целом я стараюсь избегать внимания, если это возможно :) Я также незнаком с инструментами модов. Но я не против помочь, особенно если это необходимо - у меня большие надежды на этот сайт.
Дан
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.