Як ви протестуєте зміни на плагіни Jenkins перед тим, як розгорнути їх?


14

Якщо вас коли-небудь вкусила оновлення плагінів, що порушило певну функціональність, ви, мабуть, задумалися над цією проблемою: якою має бути політика оновлення плагінів Jenkins? Як ви протестуєте зміни перед їх розгортанням?

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


Ви маєте на увазі командну політику Дженкінса чи свою політику (організацію)?
Дан Корнілеску

Я б зробив знімок вузла Дженкінса перед оновленням і просто перевірити його. З мого досвіду, Дженкінс ніколи не був важливою складовою місії. Якщо він "вниз" протягом 15 хвилин, оскільки якесь оновлення плагінів зламало його, зазвичай це жодним чином не блокує виробництво, тому ручне втручання є прийнятним. Звичайно, якщо це не так для вас (а Дженкінс повинен бути на 100% HA), це не правильний підхід.
Ассаф Лав'є

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

@AssafLavie Це дуже залежить від способу роботи Дженкінса: автономний сервер, VM, контейнер докера, кубернетні стручки (наш випадок). Зробити знімок поточного стану може бути непросто, щоб відновити його таким, яким він є. У нашому випадку ми можемо клонувати об'єм EBS, що містить дані про Дженкінса, але це відновлення часу та об'єму даних до певного стану - це ручний та трудомісткий процес.
Майкл Перейра

Привіт @MichaelPereira, якщо будь-яка з двох нижче відповідей вирішила ваше питання, будь ласка, подумайте про його прийняття , натиснувши галочку. Це вказує широкій спільноті на те, що ви знайшли рішення та надаєте певної репутації як відповідачу, так і собі. Не потрібно цього робити. Якщо ви не відчуваєте, що на ваше запитання відповіли, не соромтесь спілкуватися з авторами у коментарях.
Річард Слейтер

Відповіді:


4

Відповідно до політики компанії, в якій я працюю, ми маємо середовище для розробників, попереднього і попереднього продукту (на деяких сервісних розробниках може бути відсутніх). І шлях нової версії препрод-> тести-> перевірка-> прод.

У нашому випадку завдання в препродорі є досить важкими і складними, щоб бути впевненими, що нам не потрібно молитися під час впровадження в програмі :)

Примітка . Ми використовуємо svn для підтримки та доставки конфігурації. Ми не робимо змін на місці.


Як ви підтримуєте конфігурацію різних серверів Jenkins? Вручну?
Майкл Перейра

Ми використовуємо svn для підтримки та доставки конфігурації. Ми не робимо змін на місці
Ромео Нінов,

Я відчуваю, що це не зовсім відповідає на питання. Ця відповідь описує спосіб розгортання змін, але не тестує зміни через конвеєр розгортання.
jayhendren

2

Нам знадобилося 100% середовища HA Jenkins. ми часто оновлюємо плагіни / сам Дженкінс.

Це викликає великий головний біль, якщо збірка перервана після оновлення.

Найбезпечніший спосіб розібратися в цьому - це дійсно налаштування демо Дженкінса. Можливо, на одній машині, використовуючи кілька додатків Tomcat, ви можете досягти цього дешевше.

Що ми зробили, це створити окремий (демонстраційний) VM та відтворити налаштування продукту на демонстраційній машині. Перш ніж щось змінити / модернізувати, ми зробили знімок обох віртуальних машин. Тоді ми б протестували оновлення на Demo VM. Якщо він працює добре, змініть його на Prod.

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


0

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

Будь-яку невідповідність результату потрібно дослідити, щоб визначити, вони викликані оновленням плагіна чи ні. Можливо, ще кілька повторних запусків як із старими, так і з новими плагінами?


А як же, немає проблем.
Дан Корнілеску

З минулого досвіду моя думка часто не така популярна, тому в цілому я, як правило, уникаю уваги, якщо це можливо :) Мені також незнайомі модні інструменти. Але я не проти допомогти, особливо якщо це потрібно - я покладаю великі надії на цей сайт.
Дан Корнілеску
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.