이전 포스팅에서 Jenkins, Docker를 사용해서 CI/CD환경을 구축했는데 크게 2가지 정도 개선해야할 사항이 있습니다.

이전에는 push이벤트가 발생할 때 build CI/CD가 이루어 졌었습니다. 이를 master 브랜치에 pull request가 발생했을 때 CI/CD가 진행되고 build가 성공되었을 경우 master 브랜치에 merge가 가능하도록 하여 master에 무분별하게 merge를 할 수 없도록 하였습니다.

또한 민감한 정보는 Github에 올릴 수 없기 때문에 이를 환경변수로 관리할 수 있도록 하였습니다.

📌 Pull Request 발생시 CI/CD진행

1. Github Webhook 설정

Github 배포할 Repository > Settings > Webhooks

위 경로로 들어와서 webhooks 설정에서 Pull requests를 선택합니다.

2. Github 브랜치 보호 규칙

Github 배포할 Repository > Settings > Branches

위 경로로 들어와 Add rule 버튼을 클릭하여 Branch protextion rule을 생성합니다.

Branch name pattern : 브랜치 보호 규칙을 설정할 브랜치
Require a pull request before merging : 함부로 merge 할 수 없도록 pull requst를 통해서만 merge할 수 있도록 설정
Require approvals : merge를 진행하기 위해 필요한 동의 인원수
Require status checks to pass before merging : merge를 하기전 pull request의 상태를 체크하여 merge되기 위한 설정
(jenkins에서 build전 pending 상태로 수정하고 build의 결과에 따라 성공 또는 실패 상태에 따라 pull reuqest의 상태를 수정)

3. Jenkins Configure 설정

Dashboard > Jenkins Item > Configureation

Branch to build에 merge가 될 대상인 master 브랜치 외에 추가로 개발을 진행중인 브랜치를 추가해줍니다.

저는 feat브랜치라고 따로 개발을 진행할 브랜치를 통해 master 브랜치로 pull request를 진행하였습니다.

빌드 유발에서 GitHub Pull Requsts를 선택해줍니다.

GitHub Pull Requests : Github Pull Requests 발생시 Build 유발
Set status before build : Build가 진행되기전 Pull Requests 의 상태를 pending 상태로 수정
Trigger Events : Pull Request가 Open 되었을 경우 Build가 진행
Branch Restriction : master 브랜치에 대해서 Pull Requst가 생성되었을 때 Build유발이 되기 위해 Whitelist로 master 등록

빌드 후 조치에 GitHub RP: set PR status를 통해 Build 성공 실패 여부에 따라 Pull Requst의 상태를 수정하기 위해 아래와 같이 설정

Pull Request 생성 후 진행 과정

여기까지 진행 후 Pull Requst를 생성하면 아래와 같이 pending 상태로 jenkins의 build 과정을 기다리게 됩니다.

Build가 성공했을 경우에 Pull Request도 성공 상태로 수정하여 Merge가 가능하게 됩니다.

Buil가 실패했을 경우 Pull Reuqest도 실패 상태로 수정하여 Merge를 할 수 없게 됩니다.

📌 민감한 정보 환경변수로 관리

1. Project Dockerfile 및 yml

민갑한 정보들의 경우 yml 파일에 따로 환경변수로 값을 받을 수 있도록 처리해줍니다.
예시로 아래와 같이 application-dev.yml을 생성해줍니다.

server:
  port: 8080

application:
  value1: ${APPLICATION_VALUE1}
  value2: ${APPLICATION_VALUE2}

Dockerfile에서 dev 프로필로 build가 될 수 있도록 아래와 같이 작성합니다.

FROM amazoncorretto:17 AS builder

WORKDIR /app
COPY build/libs/*-SNAPSHOT.jar app.jar

FROM amazoncorretto:17

WORKDIR /app
COPY --from=builder /app/app.jar app.jar

ENV PROFILE="dev"

ENTRYPOINT java -jar app.jar --spring.profiles.active=$PROFILE

2. Jenkins 환경변수 등록

Dashboard > Jenkins 관리 > System

Global properties에 아래와 같이 yml파일에 있는 환경변수를 등록해줍니다.

3. Jenkins Configure 설정

Dashboard > Jenkins Item > Configuration

Build Steps에 Execute shell을 추가하여 최상단으로 옮겨 주고 아래와 같이 sed 명령어를 통해 application-dev.yml에 있는 환경변수를 Jenkins에 등록한 환경변수로 수정해줍니다.

sed -i "s/\${APPLICATION_VALUE1}/${APPLICATION_VALUE1}/" "./src/main/resources/application-dev.yml"
sed -i "s/\${APPLICATION_VALUE2}/${APPLICATION_VALUE2}/" "./src/main/resources/application-dev.yml"

여기까지 진행하고 나서 CI/CD를 진행고 작업공간에 들어가면 Jenkins에 등록한 환경변수 값이 application-dev.yml에 성공적으로 들어갔음을 확인할 수 있습니다.

💣 트러블 슈팅

1. GitHub Pull Request Builder 설치 시 위험 경고표시

Pull Request로 Build 유발을 하기 위해 구글링시 GitHub Pull Request builder에 대한 블로그글이 많아 설치를 하니 아래와 같이 경고가 나옴.
보안적으로 취약한 점이 있어 Jenkins에서 위험 플러그인으로 등록하여 사용하지 않는 것을 권장하여 GitHub Integration Plugin안에 있는 기능을 사용

2. When using COPY with more than one source file, the destination must be a directory and end with a /

docker build 시 Dockerfile에 있는 명령어를 실행하면서 발생한 에러로 build가 진행하면 jar파일이 일반 버전과 plan 버전 2개가 생성되는데 이로 인해 발생한 문제로 아래와 같이 Dockerfile을 수정하여 해결

// 수정 전
COPY build/libs/jenkins-project-*.jar app.jar

// 수정 후
COPY build/libs/*-SNAPSHOT.jar app.jar

3. ERROR: Couldn't find any revision to build.

jenkins에서 지금 빌드 버튼을 클릭할 때 발생한 에러로 Pull Ruquest의 상태를 수정해주어야하는데 Pull Request를 찾을 수 없는 문제로 free style로 생성한 jenkins item에서 분기처리가 힘들어 한계라고 판단 -> free style item을 따로 하나 만들거나 Multibranch-pipeline을 이용해서 CI/CD 환경을 구축해야할 것 같음

4. feat브랜치의 코드로 build가 되지 않는 문제

Branch Specifier에 /master 만 등록이 되어있어서 feat브랜치의 코드로 build되지 않는 문제로 /feat 도 Branch Specifier에 등록하여 해결

✨ 마무리

Pull Requst이벤트를 Build trigger로 사용하면서 Branch 전략에 대해 공부하고 고민하게 되었습니다.
어떤 브랜치 전략으로 CI/CD 환경을 구축하는 것이 팀 프로젝트를 진행할 때 효율적일까는 프로젝트의 규모, 팀 단위 등에 따라 배포 프로세스를 빠르게 할 지 좀 제한을 줄지를 선택하면 되겠다는 생각을 하였습니다.

Freestyle 프로젝트에서 CI/CD 환경을 고도화하면서 조건에 따른 분기 처리에 한계를 느꼈습니다. 이를 극복하기 위해 다음에는 Pepiline 프로젝트를 통해 Script를 작성하여 CI/CD 파이프라인을 구축해보도록 하겠습니다.