Jeśli kiedykolwiek ugryzła Cię aktualizacja wtyczki, która zepsuła niektóre funkcje, musisz pomyśleć o tym problemie: jakie powinny być zasady aktualizacji wtyczek Jenkins? Jak testujesz zmiany przed ich wdrożeniem?
Czy ktoś posunął się tak daleko, że ma instancję testową, która uruchamia fałszywe zadania do testowania nowych wersji, czy tylko modlisz się, aby uaktualnienie wersji niczego nie zepsuło?
Czy masz na myśli politykę zespołu Jeankinsa czy politykę (organizacji)?
—
Dan Cornilescu,
Zrobiłbym migawkę węzła Jenkins przed aktualizacją i po prostu przetestowałem. Z mojego doświadczenia wynika, że Jenkins nigdy nie był kluczowym elementem misji. Jeśli „nie działa” przez 15 minut, ponieważ zepsuła go jakaś aktualizacja wtyczki, zwykle nie blokuje w żaden sposób produkcji, więc ręczna interwencja jest dopuszczalna. Oczywiście, jeśli tak nie jest w twoim przypadku (a Jenkins musi mieć 100% HA), nie jest to właściwe podejście.
—
Assaf Lavie,
@DanCornilescu moja polityka organizacji, ponieważ dotyczy to naszego wewnętrznego serwera Jenkins
—
Michael Pereira
@AssafLavie Zależy to w dużej mierze od sposobu działania Jenkinsa: samodzielny serwer, VM, kontener dokerów, kubernetes pods (nasz przypadek). Wykonanie migawki bieżącego stanu może nie być łatwe do przywrócenia w obecnym stanie. W naszym przypadku możemy sklonować wolumin EBS zawierający dane Jenkinsa, ale jest to ręczny i czasochłonny proces przywracania zarówno kontenera, jak i woluminu danych do określonego stanu.
—
Michael Pereira,
Cześć @MichaelPereira, jeśli jedna z dwóch poniższych odpowiedzi rozwiązała pytanie, rozważ zaakceptowanie go , klikając znacznik wyboru. Oznacza to szerszej społeczności, że znalazłeś rozwiązanie i daje pewną reputację zarówno użytkownikowi, jak i odbiorcy. Nie ma takiego obowiązku. Jeśli uważasz, że nie ma odpowiedzi na twoje pytanie, zachęcamy do kontaktu z autorami w komentarzach.
—
Richard Slater