[해외] 젠킨스(Jenkins)란 무엇입니까? CI 서버가 설명했습니다.

https://www.infoworld.com/article/3239666/devops/what-is-jenkins-the-ci-server-explained.html

 

 

젠킨스 란 무엇입니까? CI 서버가 설명했습니다.
Jenkins는 거의 모든 언어와 소스 코드 저장소의 조합에 대해 지속적인 통합 및 지속적인 전달 환경을 설정하는 간단한 방법을 제공합니다.

 

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

 

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

 

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

 

허드슨과 젠킨스

 

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

 

2011 년을 앞두고, 오라클 (Sun을 인수 한)과 독립 허드슨 오픈 소스 커뮤니티 간의 분쟁으로 인해 이름이 바뀐 포크 ( Jenkins)가되었습니다 . Jenkins는 훨씬 더 활동적이지만 포크는 계속 존재합니다. 2014 년 Kawaguchi는 Jenkins 기반의 연속 배송 제품을 제공하는 CloudBees의 CTO가되었습니다.

 

젠킨스의 자동화

 

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

 

젠킨스의 작동 방식

 

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

 

Tomcat과 같은 Java 응용 프로그램 서버에서 Jenkins WAR 독립 실행 형 또는 서블릿으로 실행할 수 있습니다. 두 경우 모두 웹 사용자 인터페이스를 생성하고 REST API에 대한 호출을 허용합니다.

 

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

 

젠킨스 플러그인

 

Jenkins를 설치하면 기본 플러그인 목록을 수락하거나 자신 만의 플러그인을 선택할 수 있습니다.

 

 

초기 플러그인 세트를 선택했으면 설치 버튼을 클릭하면 젠킨스가 플러그인을 추가합니다.

 

 

Jenkins 기본 화면에는 현재 빌드 큐 및 Executor 상태가 표시되고 새 항목 (작업)을 만들고, 사용자를 관리하고, 빌드 기록을보고, Jenkins를 관리하고, 사용자 정의보기를보고 자격 증명을 관리하는 링크가 제공됩니다.

 

 

새 Jenkins 항목은 여섯 가지 작업 유형과 항목 구성을위한 폴더 중 하나 일 수 있습니다.

 

 

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

 

 

젠킨스 파이프 라인

 

Jenkins를 구성한 후에는 Jenkins가 구축 할 수있는 프로젝트를 만들어야합니다. 당신이하는 동안 수 있습니다 스크립트를 만들 웹 UI를 사용하여, 현재 가장 좋은 방법은하는 것입니다 파이프 라인 스크립트 작성 Jenkinsfile라는 이름을 , 당신의 저장소에 그것을 확인. 아래의 스크린 샷은 멀티 브랜치 파이프 라인에 대한 구성 웹 양식을 보여줍니다.

 

 

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

 

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

 

pipeline {
    agent any

    stages {
        stage(‘Build’) {
            steps {
                echo ‘Building..’
            }
        }
        stage(‘Test’) {
            steps {
                echo ‘Testing..’
            }
        }
        stage(‘Deploy’) {
            steps {
                echo ‘Deploying....’
            }
        }
    }
}

pipelineJenkins 파이프 라인 플러그인을 호출하는 필수 외부 블록입니다. agent파이프 라인을 실행할 위치를 정의합니다. any사용 가능한 에이전트를 사용하여 파이프 라인이나 스테이지를 실행합니다. 특정 에이전트가 컨테이너에 사용할 선언 할 수 있습니다 (예 :

 

agent {
    docker {
        image ‘maven:3-alpine’
        label ‘my-defined-label’
        args  ‘-v /tmp:/tmp’
    }
}

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

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

 

pipeline {
    agent any

    stages {
        stage(‘Build’) {
            steps {
                sh ‘make’
                archiveArtifacts artifacts: ‘**/target/*.jar’, fingerprint: true
            }
        }
    }
}

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

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

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

 

pipeline {
    agent any
    stages {
        stage(‘Test’) {
            steps {
                sh ‘make check’
            }
        }
    }
    post {
        always {
            junit ‘**/target/*.xml’
        }
        failure {
            mail to: team@example.com, subject: ‘The Pipeline failed :(‘
        }
    }
}

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

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

 

선언적 파이프 라인

 

pipeline {
    agent { docker ‘node:6.3’ }
    stages {
        stage(‘build’) {
            steps {
                sh ‘npm —version’
            }
        }
    }
} 

스크립트 파이프 라인

 

node(‘docker’) {
    checkout scm
    stage(‘Build’) {
        docker.image(‘node:6.3’).inside {
            sh ‘npm —version’
        }
    }
}

Blue Ocean, Jenkins GUI

 

Jenkins의 최신 UI를 원한다면 Blue Ocean 플러그인을 사용할 수 있습니다.이 플러그인은 그래픽 사용자 환경을 제공합니다. 당신은 할 수 있습니다 기존 젠킨스 설치에 블루 오션 플러그인을 추가하거나 젠킨스 / 블루 오션 도커 컨테이너를 실행합니다 . Blue Ocean을 설치하면 Jenkins 기본 메뉴에 추가 아이콘이 표시됩니다.

 

 

원하는 경우 Blue Ocean을 직접 열 수 있습니다. Jenkins 서버의 / blue 폴더에 있습니다. Blue Ocean의 파이프 라인 생성은 일반 젠킨스 (Jenkins)보다 약간 더 그래픽 적입니다.

 

 

젠킨스 도커

 

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

 

여기에 Blue Ocean Docker 이미지가 있습니다.이 이미지는 기본 SCM 공급자 목록보다 몇 가지 더 많은 Git 서비스 플러그인이 설치되어 있습니다 :

 

 

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

 

 

지점 (상단) 및 활동을 확대 할 수도 있습니다. 

 

 

 

왜 젠킨스를 사용합니까?

 

우리가 사용하고있는 파이프 라인 플러그인은 CICD (Continuous Integration / Continuous Delivery) 유스 케이스를 지원합니다. 이는 젠킨스에서 가장 일반적으로 사용되는 케이스입니다. 다른 사용 사례에 대해서는 전문적인 고려 사항이 있습니다.

 

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 도구와 많은 제휴를 맺고 있습니다.

 

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

 

젠킨스 대 뱀부 (Jenkins vs Bamboo)

 

사람들은 종종 Jenkins 나 Atlassian Bamboo와 함께 CICD 서버를 사용하는 것이 더 나을지 물어 봅니다. 컨설턴트로서 나의 재고 대답은 "It depends."입니다.

 

우선 Jenkins는 무료 오픈 소스이고 Bamboo는 상용 소프트웨어입니다. Jenkins는 더 큰 커뮤니티와 더 많은 플러그인을 보유하고 있습니다. 반면 Bamboo는 Bitbucket, Jira 및 Confluence와 같은 다른 Atlassian 제품과 함께 즉시 통합되어 있습니다.

 

예전에는 Bamboo를 클라우드 서비스로 사용할 수 있었고 사내 구축 환경에서도 사용할 수있었습니다. 2017 년 1 월 현재 Bamboo Cloud는 더 이상 제공되지 않습니다. 대신 Atlassian은 Bitbucket 파이프 라인을 사용하기를 원합니다.

 

이 시점에서 Bamboo 서버를 계속 사용할 수 있고 클라우드 기반 컨테이너 또는 VM에서 호스팅 할 수 있다고해도, 사람들이 고아 제품이된다는 이유로 새 설치를 피할 것을 제안합니다. Bitbucket에서 리포지토리를 호스팅하고 Jenkins를 고려한다면 CICD를위한 Bitbucket Pipelines를 고려하는 것이 좋습니다.