Jenkins 플러그인의 변경 사항을 배포하기 전에 어떻게 테스트합니까?

일부 기능을 손상시킨 플러그인 업그레이드로 물린 적이 있다면이 문제에 대해 몇 가지 생각을해야합니다. Jenkins 플러그인 업그레이드 정책은 무엇입니까? 변경 사항을 배포하기 전에 어떻게 테스트합니까?

새로운 버전을 테스트하기 위해 더미 작업을 실행하는 테스트 인스턴스를 가진 사람이 있습니까? 아니면 버전을 업그레이드해도 아무런 문제가되지 않기를 바랍니다.

내가 일하는 회사의 정책에 따르면 개발, 사전 및 생산 환경이 있습니다 (일부 서비스 개발에서는 누락 될 수 있음). 그리고 새 버전 preprod-> tests-> validation-> prod의 경로.

우리의 경우에 preprod에서의 일자리는 prod로 구현할 때기도 할 필요가 없을 정도로 무겁고 복잡합니다. :)

참고 : 우리는 svn을 사용하여 구성을 유지하고 제공합니다. 우리는 제자리를 바꾸지 않습니다.

우리는 100 % HA Jenkins 환경이 필요했습니다. 우리는 종종 플러그인 / Jenkins 자체를 업그레이드합니다.

업그레이드 후 빌드가 중단되면 큰 두통이 발생합니다.

이것을 정렬하는 가장 안전한 방법은 실제로 데모 젠킨스 설정을 얻는 것입니다. 여러 Tomcat 응용 프로그램을 사용하는 동일한 컴퓨터에서이 저렴한 가격을 얻을 수 있습니다.

우리가 한 일은 별도의 (Demo) VM을 만들고 데모 VM에서 제품 설정을 복제하는 것입니다. 무엇이든 변경 / 업그레이드하기 전에 두 VM의 스냅 샷을 만듭니다. 그런 다음 데모 VM에서 업그레이드를 테스트합니다. 제대로 작동하면 Prod에서 변경하십시오.

누군가 당신이 계획하고있는 플러그인에 문제가 발생하면 (SE / SO와 같은) 커뮤니티를 찾을 수 있다고 생각합니다.

각 플러그인을 사용하는 모든 관련 프로젝트 / 지점에서 적어도 하나의 최근 녹색 (또는 거의 녹색) 레이블에서 항상 수동으로 재실행을 실행하고 동일한 결과를 얻었는지 확인합니다. 안전한 편이 되려면

플러그인 업데이트로 인한 것인지 아닌지를 결정하기 위해 모든 결과 불일치를 조사해야합니다. 이전 플러그인과 새 플러그인으로 다시 몇 번 더 실행할 수 있습니까?