Jenkins는 무엇입니까? CI 서버 설명

Jenkins는 파이프 라인을 사용하는 거의 모든 언어 및 소스 코드 리포지토리 조합에 대해 지속적 통합 또는 지속적 배포 (CI / CD) 환경을 설정하는 간단한 방법을 제공하고 기타 일상적인 개발 작업을 자동화합니다. Jenkins는 개별 단계에 대한 스크립트를 생성 할 필요성을 제거하지 않지만, 직접 쉽게 구축 할 수있는 것보다 전체 빌드, 테스트 및 배포 도구 체인을 통합하는 더 빠르고 강력한 방법을 제공합니다.

"야간 빌드를 깨지 마십시오!" 테스터를 위해 매일 아침 새로 빌드 된 일일 제품 버전을 게시하는 소프트웨어 개발 상점의 기본 규칙입니다. Jenkins 이전에 개발자가 야간 빌드 중단을 방지하기 위해 할 수있는 최선의 방법은 코드를 커밋하기 전에 로컬 시스템에서 신중하고 성공적으로 빌드하고 테스트하는 것이 었습니다. 그러나 그것은 다른 모든 사람의 일일 커밋 없이 자신의 변경 사항을 격리 테스트하는 것을 의미했습니다 . 야간 빌드가 자신의 커밋에서 살아남을 것이라는 확고한 보장이 없었습니다.

Jenkins (원래 Hudson)는 이러한 제한에 대한 직접적인 대응이었습니다.

허드슨과 젠킨스

2004 년에 Kohsuke Kawaguchi는 Sun의 Java 개발자였습니다. Kawaguchi는 개발 작업에서 빌드를 깨는 것에 지 쳤고 코드가 작동할지 여부를 저장소에 커밋하기 전에 알 수있는 방법을 찾고 싶었습니다. 그래서 Kawaguchi는 Hudson이라고하는 Java 용 자동화 서버를 구축했습니다. Hudson은 Sun에서 인기를 얻었고 오픈 소스로 다른 회사에 퍼졌습니다.

2011 년으로 넘어 가고 Oracle (Sun을 인수 한)과 독립 Hudson 오픈 소스 커뮤니티 간의 분쟁으로 인해 Jenkins라는 이름이 변경되었습니다. 2014 년 Kawaguchi는 Jenkins 기반의 지속적 배포 제품을 제공하는 CloudBees의 CTO가되었습니다.

Jenkins는 훨씬 더 활동적 이었지만 두 포크 모두 계속 존재했습니다. 오늘날 Jenkins 프로젝트는 여전히 활성 상태입니다. 허드슨 웹 사이트는 2020 년 1 월 31 일에 폐쇄되었습니다.

2019 년 3 월 Linux Foundation은 CloudBees, Google 및 기타 여러 회사와 함께 CDF (Continuous Delivery Foundation)라는 새로운 오픈 소스 소프트웨어 재단을 시작했습니다. Jenkins 기여자들은 그들의 프로젝트가이 새로운 재단에 합류해야한다고 결정했습니다. Kawaguchi는 당시 사용자에게 중요한 것은 변경되지 않을 것이라고 썼습니다.

2020 년 1 월 Kawaguchi는 자신의 새로운 스타트 업인 Launchable로 이동한다고 발표했습니다. 그는 또한 Continuous Delivery Foundation의 기술 감독위원회에 남아 있고 CloudBees에서 자신의 역할을 고문으로 전환하지만 공식적으로 Jenkins에서 물러날 것이라고 말했습니다.

관련 비디오 : CI / CD로 코드를 더 빠르게 제공하는 방법

Jenkins 자동화

현재 Jenkins는 모든 종류의 개발 작업의 자동화를 지원하는 약 1,600 개의 플러그인이있는 선도적 인 오픈 소스 자동화 서버입니다. Kawaguchi가 원래 해결하려고했던 문제, 지속적인 통합 및 Java 코드의 지속적인 전달 (예 : 프로젝트 빌드, 테스트 실행, 정적 코드 분석 수행 및 배포)은 사람들이 Jenkins로 자동화하는 많은 프로세스 중 하나 일뿐입니다. 이러한 1,600 개의 플러그인은 플랫폼, UI, 관리, 소스 코드 관리 및 가장 자주 빌드 관리의 5 개 영역에 걸쳐 있습니다.

Jenkins의 작동 원리

Jenkins는 WAR 아카이브 및 주요 운영 체제 용 설치 프로그램 패키지, Homebrew 패키지, Docker 이미지 및 소스 코드로 배포됩니다. 소스 코드는 대부분 Java이며 몇 개의 Groovy, Ruby 및 Antlr 파일이 있습니다.

Jenkins WAR을 독립형으로 실행하거나 Tomcat과 같은 Java 애플리케이션 서버에서 서블릿으로 실행할 수 있습니다. 두 경우 모두 웹 사용자 인터페이스를 생성하고 REST API에 대한 호출을 수락합니다.

Jenkins를 처음 실행하면 긴 임의의 암호를 가진 관리자가 생성되며, 초기 웹 페이지에 붙여 넣어 설치 잠금을 해제 할 수 있습니다.

Jenkins 플러그인

Jenkins를 설치하면 기본 플러그인 목록을 수락하거나 고유 한 플러그인을 선택할 수 있습니다.

초기 플러그인 세트를 선택한 후 설치 버튼을 클릭하면 Jenkins가 플러그인을 추가합니다.

Jenkins 기본 화면은 현재 빌드 대기열 및 실행자 상태를 표시하고 새 항목 (작업) 생성, 사용자 관리, 빌드 기록보기, Jenkins 관리, 사용자 지정보기보기 및 자격 증명 관리를위한 링크를 제공합니다.

새 Jenkins 항목은 6 가지 유형의 작업과 항목을 구성하기위한 폴더가 될 수 있습니다.

명령 줄 인터페이스를 여는 옵션을 포함하여 Jenkins 관리 페이지에서 수행 할 수있는 18 가지 작업이 있습니다. 그러나이 시점에서는 일반적으로 스크립트에 의해 정의되는 향상된 워크 플로 인 파이프 라인을 살펴보아야합니다.

Jenkins 파이프 라인

Jenkins를 구성했으면 Jenkins가 빌드 할 수있는 몇 가지 프로젝트를 만들 차례입니다. 당신이하는 동안 수 있습니다 스크립트를 만들 웹 UI를 사용하여, 현재 가장 좋은 방법은 Jenkinsfile라는 이름의 파이프 라인 스크립트를 생성하는 것입니다 , 당신의 저장소에 그것을 확인. 아래 스크린 샷은 다중 분기 파이프 라인에 대한 구성 웹 양식을 보여줍니다.

보시다시피 기본 Jenkins 설치에서 이러한 종류의 파이프 라인에 대한 분기 소스는 GitHub를 포함한 Git 또는 Subversion 저장소 일 수 있습니다. 다른 종류의 리포지토리 나 다른 온라인 리포지토리 서비스가 필요한 경우 적절한 플러그인을 추가하고 Jenkins를 재부팅하면됩니다. 시도했지만 Jenkins 플러그인이 아직 나열되지 않은 소스 코드 관리 시스템 (SCM)을 생각할 수 없었습니다.

Jenkins 파이프 라인은 선언적이거나 스크립팅 될 수 있습니다. 선언 파이프 라인, 두 가지의 단순한는 그루비 호환 구문 및 사용 당신이 원한다면, 당신은 파일을 시작할 수 #!groovy올바른 방향으로 코드 편집기를 가리 키도록. 선언적 파이프 라인은 아래의 3 단계 예 와 같이 pipeline블록으로 시작하여를 agent정의 stages하고 실행 파일을 포함하는 정의 steps합니다.

파이프 라인 {

    에이전트 모두

    stage {

        stage ( 'Build') {

            단계 {

                echo '빌딩 ..'

            }

        }

        stage ( 'Test') {

            단계 {

                echo '테스트 중 ..'

            }

        }

        stage ( 'Deploy') {

            단계 {

                echo '배포 중 ....'

            }

        }

    }

}

pipelineJenkins 파이프 라인 플러그인을 호출하기위한 필수 외부 블록입니다. agent파이프 라인을 실행할 위치를 정의합니다. any사용 가능한 에이전트를 사용하여 파이프 라인 또는 단계를 실행하라고 말합니다. 보다 구체적인 에이전트는 사용할 컨테이너를 선언 할 수 있습니다. 예를 들면 다음과 같습니다.

에이전트 {

    docker {

        이미지 'maven : 3-alpine'

        '내 정의 라벨'라벨

        인수 '-v / tmp : / tmp'

    }

}

stages하나 이상의 단계 지시문의 시퀀스를 포함합니다. 위의 예에서 세 단계는 빌드, 테스트 및 배포입니다.

steps실제 작업을 수행하십시오. 위의 예에서 단계는 메시지를 인쇄했습니다. 더 유용한 빌드 단계는 다음과 같습니다.

파이프 라인 {

    에이전트 모두

    stage {

        stage ( 'Build') {

            단계 {

                sh 'make'

                archiveArtifacts 아티팩트 : '** / target / *. jar', 지문 : true

            }

        }

    }

}

여기서는 make쉘에서 호출 한 다음 생성 된 JAR 파일을 Jenkins 아카이브에 보관합니다.

post섹션은 파이프 라인 실행 또는 단계가 끝날 때 실행될 작업을 정의합니다. 당신은 포스트 섹션 내 포스트 조건 블록의 번호를 사용할 수 있습니다 : always, changed, failure, success, unstable,와 aborted.

예를 들어 아래의 Jenkinsfile은 테스트 단계 후에 항상 JUnit을 실행하지만 파이프 라인이 실패한 경우에만 이메일을 보냅니다.

파이프 라인 {

    에이전트 모두

    stage {

        stage ( 'Test') {

            단계 {

                sh '확인 확인'

            }

        }

    }

    우편 {

        항상 {

            junit '** / target / *. xml'

        }

        실패 {

            메일 주소 : [email protected], 제목 : '파이프 라인 실패 :('

        }

    }

}

선언적 파이프 라인은 파이프 라인을 정의하는 데 필요한 대부분을 표현할 수 있으며 Groovy 기반 DSL 인 스크립팅 된 파이프 라인 구문보다 배우기가 훨씬 쉽습니다. 스크립팅 된 파이프 라인은 실제로 완전한 프로그래밍 환경입니다.

비교를 위해 다음 두 Jenkinsfile은 완전히 동일합니다.

선언적 파이프 라인

파이프 라인 {

    에이전트 {docker 'node : 6.3'}

    stage {

        stage ( 'build') {

            단계 {

                sh 'npm — 버전'

            }

        }

    }

스크립팅 된 파이프 라인

node ( 'docker') {

    체크 아웃 scm

    stage ( 'Build') {

        docker.image ( 'node : 6.3'). inside {

            sh 'npm — 버전'

        }

    }

}

Blue Ocean, Jenkins GUI

최신의 최고의 Jenkins UI를 원한다면 그래픽 사용자 경험을 제공하는 Blue Ocean 플러그인을 사용할 수 있습니다. Blue Ocean 플러그인을 기존 Jenkins 설치에 추가하거나 Jenkins / Blue Ocean Docker 컨테이너를 실행할 수 있습니다. Blue Ocean이 설치되면 Jenkins 주 메뉴에 추가 아이콘이 있습니다.

원한다면 블루 오션을 바로 열 수 있습니다. Jenkins 서버의 / blue 폴더에 있습니다. Blue Ocean의 파이프 라인 생성은 일반 Jenkins보다 약간 더 그래픽 적입니다.

Jenkins Docker

앞서 언급했듯이 Jenkins는 Docker 이미지로도 배포됩니다. 프로세스에 더 이상은 없습니다. SCM 유형을 선택하면 URL과 자격 증명을 제공 한 다음 단일 리포지토리에서 파이프 라인을 생성하거나 조직의 모든 리포지토리를 스캔합니다. Jenkinsfile이있는 모든 분기에는 파이프 라인이 있습니다.

여기에서는 기본 SCM 공급자 목록보다 몇 가지 추가 Git 서비스 플러그인이 설치된 Blue Ocean Docker 이미지를 실행하고 있습니다.

일부 파이프 라인을 실행하면 Blue Ocean 플러그인이 위에 표시된대로 상태를 표시합니다. 개별 파이프 라인을 확대하여 단계와 단계를 볼 수 있습니다.

분기 (위) 및 활동 (아래)을 확대 할 수도 있습니다.  

Jenkins를 사용하는 이유는 무엇입니까?

우리가 사용해온 Jenkins Pipeline 플러그인은 Jenkins에서 가장 일반적으로 사용되는 일반적인 CICD (지속적 통합 / 지속적 배포) 사용 사례를 지원합니다. 다른 사용 사례에 대한 특별한 고려 사항이 있습니다.

Java 프로젝트는 Jenkins의 원래 이유였습니다. Jenkins가 Maven으로 빌드를 지원한다는 것을 이미 보았습니다. Ant, Gradle, JUnit, Nexus 및 Artifactory에서도 작동합니다.

Android는 일종의 Java를 실행하지만 다양한 Android 기기에서 테스트하는 방법에 대한 문제를 소개합니다. Android 에뮬레이터 플러그인을 사용하면 정의하려는만큼 에뮬레이트 된 기기에서 빌드하고 테스트 할 수 있습니다. Google Play 게시자 플러그인을 사용하면 실제 기기에서 출시 또는 추가 테스트를 위해 빌드를 Google Play의 알파 채널로 보낼 수 있습니다.

파이프 라인의 에이전트로 Docker 컨테이너를 지정하고 Docker 컨테이너에서 Jenkins와 Blue Ocean을 실행 한 예를 보여 드렸습니다. Docker 컨테이너는 속도, 확장 성 및 일관성을 개선하기 위해 Jenkins 환경에서 매우 유용합니다.

Jenkins 및 GitHub에는 두 가지 주요 사용 사례가 있습니다. 하나는 GitHub 저장소에 대한 모든 커밋에서 Jenkins를 트리거하는 서비스 후크를 포함 할 수있는 빌드 통합입니다. 두 번째는 GitHub 인증을 사용하여 OAuth를 통해 Jenkins에 대한 액세스를 제어하는 ​​것입니다.

Jenkins는 Java 외에 많은 다른 언어를 지원합니다. C / C ++의 경우 콘솔에서 오류 및 경고를 캡처하고, CMake로 빌드 스크립트를 생성하고, 단위 테스트를 실행하고, 정적 코드 분석을 수행하는 플러그인이 있습니다. Jenkins는 PHP 도구와 다양한 통합 기능을 제공합니다.

Python 코드를 빌드 할 필요는 없지만 (예를 들어 Cython을 사용하거나 설치를 위해 Python 휠을 생성하지 않는 한) Jenkins가 Nose2 및 Pytest와 같은 Python 테스트 및보고 도구, 코드 품질과 통합하는 것이 유용합니다. Pylint와 같은 도구. 마찬가지로 Jenkins는 Rake, Cucumber, Brakeman 및 CI :: Reporter와 같은 Ruby 도구와 통합됩니다.

CI / CD 용 Jenkins

전반적으로 Jenkins는 파이프 라인을 사용하는 거의 모든 언어 및 소스 코드 리포지토리 조합에 대한 CI / CD 환경을 설정하는 간단한 방법을 제공 할뿐만 아니라 기타 여러 일상적인 개발 작업을 자동화합니다. Jenkins는 개별 단계에 대한 스크립트를 생성 할 필요를 제거하지 않지만, 직접 쉽게 구축 할 수있는 것보다 전체 빌드, 테스트 및 배포 도구 체인을 통합하는 더 빠르고 강력한 방법을 제공합니다.