[Jenkins] 젠킨스로 자동 빌드하기

 

 

1. Jenkins에 Git 설정 추가 

 

1) 젠킨스 홈 - 왼쪽 메뉴 Jenkins 관리 - System

 

 하단으로 스크롤 하면 GitHub 관련 설정 메뉴가 있음

 

2) GitHub 서버 추가 - GitHub 서버 를 클릭하고 GitHub servers 정보 입력하기

GitHub servers 정보 입력

• Name: 깃허브 서버 이름을 사용하고싶은대로 입력해줌
• API URL: GitHub 서버 API 엔드포인트. 공개 github.com을 사용하려면 기본값에서 변경하지말고 GitHubEnterprise를 사용하는 경우 API 엔드포인트를 지정해야함.(GitHubEnterprise를 사용하지 않기 때문에 변경안함!
• Credentails: 아래에서 생성! 처음엔 없어서 none으로 보이고 아래+Add 버튼을 눌러 추가해준 후 설정 할 것
  • +Add 버튼 클릭 -> Jenkins 클릭

 

아래와 같이 입력하기

• Kind: Secret text
• Secret: 깃 토큰을 붙여넣기
• ID: 젠킨스 내부에서 사용할 ID 입력 

 

 

에러가 나거나 Credentials 목록에 안뜨면 새로고침이나 젠킨스 재접속해보면 됨!

 

3) 입력을 다하고 나면 오른쪽 하단에 Test connection 버튼 클릭

연결 성공 시 Credentials verified for user kimHaneul0202, rate limit:4998 메시지를 확인할 수 있음

 

🤯 중간에 발생한 실패 메시지 Failed to validate the account

젠킨스 재접속해서 하니까 해결됨

 

 

2. 젠킨스에 아이템 추가하기

 

👩🏻‍🏫 젠킨스에서 아이템이란?

• 작업의 단위를 나타냄
• 젠킨스에서 실행되는 각각의 프로젝트 또는 작업을 의미
• 아이템은 다양한 유형을 가질 수 있으며 각각의 유형에 따라 특정한 설정과 기능을 제공함

 

1) 젠킨스 홈 - 왼쪽 메뉴 '새로운 Item' 클릭

2) 아이템 이름 입력, Freestyle project 선택 -> OK 버튼

 

👩🏻‍🏫 젠킨스 아이템 유형 더 알아보기▼

1. 프리스타일 프로젝트 (Freestyle Project):
   • 가장 일반적인 유형의 아이템입니다.
   • 사용자가 원하는 방식으로 빌드 과정을 설정할 수 있습니다.
   • Shell 스크립트, 배치 파일 등의 명령을 실행하고, 소스 코드를 체크아웃하고, 빌드 환경을 구성할 수 있습니다.
2. 파이프라인 (Pipeline):
   • Jenkinsfile이라는 코드로 빌드 프로세스를 정의하는 스크립트 기반의 아이템입니다.
   • 코드로 빌드 프로세스를 관리하기 때문에 버전 관리 시스템에서 관리할 수 있고, 재사용 및 공유가 용이합니다.
   • Jenkins Pipeline은 단순한 선형 빌드부터 복잡한 CD(Continuous Delivery) 및 CI(Continuous Integration) 파이프라인까지 다양한 빌드 프로세스를 지원합니다.
3. Multi-configuration Project:
   • 이 아이템은 여러 구성을 가진 프로젝트를 생성할 때 사용됩니다.
   • 각각의 구성은 서로 다른 환경에서 빌드를 실행할 수 있는 하위 빌드를 나타냅니다.
   • 예를 들어, 테스트를 여러 버전의 소프트웨어 또는 여러 플랫폼에서 실행하려는 경우 사용될 수 있습니다.
   • Multi-configuration Project는 환경 변수, 빌드 파라미터 등을 통해 각 하위 빌드에 대한 구성을 지정할 수 있습니다.
4. Folder:
   • Folder는 Jenkins 내에서 프로젝트를 구성하고 관리하기 위한 그룹화 도구입니다.
   • 프로젝트를 논리적으로 그룹화하고 특정 팀 또는 기능에 대한 프로젝트를 구성할 때 사용됩니다.
   • Folder를 사용하여 프로젝트를 조직화하고, 액세스 제어를 구현하고, 빌드 이력을 관리할 수 있습니다.
5. Multibranch Pipeline:
   • Multibranch Pipeline은 여러 브랜치에 대한 파이프라인을 자동으로 생성하고 관리하는 아이템입니다.
   • 각 브랜치는 자체 파이프라인을 가질 수 있으며, 각각의 브랜치에서 변경 사항이 감지될 때마다 해당 브랜치의 파이프라인이 실행됩니다.
   • 주로 Git, SVN 등의 소스 코드 관리 시스템에서 여러 브랜치를 사용하는 프로젝트에 사용됩니다.
   • Jenkinsfile을 각 브랜치에 함께 저장하여 각 브랜치의 빌드 프로세스를 정의할 수 있습니다.
6. Organization Folder:
   • Organization Folder는 GitHub Organization, Bitbucket Team, GitLab Group과 같은 소스 코드 저장소 기반의 그룹화된 프로젝트를 Jenkins에 동적으로 추가하는 데 사용됩니다.
   • 이 아이템을 사용하면 저장소의 조직 구조를 기반으로 Jenkins에서 프로젝트를 자동으로 생성하고 관리할 수 있습니다.
   • Organization Folder를 설정하면 Jenkins가 지속적으로 소스 코드 저장소를 모니터링하고, 새로운 저장소가 생성되면 자동으로 Jenkins에 프로젝트를 추가합니다.

 

3) 아이템 설정하기

[Configure - General]

GitHub project를 체크하고 레포지토리 URL 입력

 

[Configure - 소스 코드 관리]

Git 체크 -> Repository URL 입력 -> Credintail 선택(1. 젠킨스에 Git 설정하기 중 Credentials 추가한 것을 선택하면 됨)

 

빌드할 브랜치 입력

나는 main 브랜치를 이용하니까 main 으로 입력

 

[Configure - 소스 코드 관리 - 빌드 유발]

빌드가 자동으로 시작되도록 하는 조건이나 이벤트를 설정

나는 git push 시에 빌드가 유발 되도록 설정하였음

👩🏻‍🏫 빌드 유발 종류 자세히 ▼

1) 빌드를 원격으로 유발

미리 정의된 특수 URL(스크립트에 편리함)에 액세스하여 새 빌드를 트리거하려면 이 옵션을 활성화하세요.
이 기능의 일반적인 예는 누군가가 방금 저장소에 변경 사항을 커밋했을 때 소스 제어 시스템의 후크 스크립트에서 또는 소스 제어 이메일 알림을 구문 분석하는 스크립트에서 새 빌드를 트리거하는 것입니다.

이를 아는 사람만 이 프로젝트의 빌드를 원격으로 트리거할 수 있도록 인증 토큰을 문자열 형식으로 제공해야 합니다.

이는 Jenkins 인스턴스가 익명 사용자에게 이 작업에 대한 읽기 액세스 권한을 부여할 때 가장 유용합니다.

그렇지 않은 경우 Jenkins는 올바른 토큰이 지정된 경우에도 트리거 URL로 전송된 요청을 거부합니다.

이 문제를 해결하려면 HTTP 요청을 작업에 필요한 읽기 권한이 있는 사용자로 인증해야 합니다. 하지만 어쨌든 이 사용자에게 이를 빌드할 수 있는 권한을 부여할 수도 있습니다.

또 다른 옵션은 빌드 토큰 루트 플러그인을 사용하는 것입니다. 이 플러그인은 이 토큰을 사용하여 빌드를 트리거하기 위한 추가 URL 끝점을 제공하며 이를 위해 필요한 전체/읽기 및 작업/읽기 권한이 필요하지 않습니다.

 

2) Build after other projects are built

다른 프로젝트의 빌드가 완료되면 이 프로젝트에 대한 새 빌드가 예약되도록 트리거를 설정하세요. 예를 들어, 이는 빌드가 완료된 후 광범위한 테스트를 실행하는 데 편리합니다.

이 구성은 업스트림 프로젝트의 "빌드 후 작업"에 있는 "다른 프로젝트 빌드" 섹션을 보완하지만 다운스트림 프로젝트를 구성하려는 경우에 권장됩니다.

 

3) Build periodically

이 프로젝트를 주기적으로 실행하기 위해 cron과 유사한 기능을 제공합니다.
이 기능은 주로 Jenkins를 cron 대체품으로 사용하기 위한 것이며 지속적으로 소프트웨어 프로젝트를 구축하는 데는 적합하지 않습니다. 사람들이 처음 지속적인 통합을 시작할 때 야간/매주와 같이 정기적으로 예약된 빌드 아이디어에 너무 익숙해서 이 기능을 사용하는 경우가 많습니다. 그러나 지속적인 통합의 핵심은 변경이 발생하는 즉시 빌드를 시작하여 변경 사항에 대한 빠른 피드백을 제공하는 것입니다. 그렇게 하려면 SCM 변경 알림을 Jenkins에 연결해야 합니다.

따라서 이 기능을 사용하기 전에 잠시 멈추고 이것이 정말로 원하는 것인지 스스로에게 물어보십시오.

 

4) GitHub hook trigger for GITScm polling

Jenkins가 GitHub 푸시 후크를 수신하면 GitHub 플러그인은 해당 후크가 이 작업의 SCM/Git 섹션에 정의된 Git 저장소와 일치하는 GitHub 저장소에서 나온 것인지 확인합니다. 일치하고 이 옵션이 활성화되면 GitHub 플러그인은 GITScm에서 일회성 폴링을 트리거합니다. GITScm은 GitHub를 폴링할 때 변경 사항이 있음을 발견하고 빌드를 시작합니다. 마지막 문장은 Git 플러그인의 동작을 설명하므로 빌드 폴링 및 시작은 GitHub 플러그인의 일부가 아닙니다.
(GitHub 플러그인에서)

 

5) poll SCM

SCM에서 변경 사항을 폴링하도록 Jenkins를 구성합니다.
모든 폴링에는 Jenkins가 전체 작업 공간을 스캔하고 서버에서 이를 확인해야 하므로 이는 CVS에 대한 비용이 많이 드는 작업이 될 것입니다. 이 문서에 설명된 대로 이러한 오버헤드를 방지하려면 "푸시" 트리거를 설정하는 것이 좋습니다.

 

3. 빌드 해보기

1) 왼쪽 메뉴 중 지금 빌드를 클릭하면 빌드가 실행됨

 

 

2) 빌드 실행과정 확인하기

실행된 빌드 버전(아래 스크린샷에서는 #9)을 선택하고 Console Output을 클릭하면 

젠킨스 빌드 작업의 실행과정을 확인해 볼 수 있음

 

 

🤯 빌드 시 겪은 문제

gitIgnore처리된 properties 파일은 깃에 push되지 않는다! 그렇다면 빌드가 실패할 수밖에 없음

일단 젠킨스 자동 빌드 및 배포 테스트를 위한 실습이므로 git ignore 처리된 properties 파일을 임의로 직접 빌드 작업하는 위치에 두고 빌드를 성공하긴함

찾아보니 이 부분에 대한 여러가지 대처 방법이 있었음

• jasypt 라이브러리를 이용하는 방법
• jenkins를 사용하여 key 파일 주입하는 방법: 파이프라인 스크립트에서 빌드전에 키를 주입하는 방법
• jenkins에 Config File Provider: 빌드 과정에서 추가 또는 기존 파일 대체하는 방법
• 설정파일에 ${변수명} 설정해서 이용하는 방법 

방법은 여러가지였는데 각 방법에 장단점이 있어서 이 부분에 대해서는 조금 더 고민 필요 할 듯