젠킨스 CI/CD - 지속적 통합배포의 이해 및 젠킨스 소개

최근 애플리케이션 개발 방식에서는 빈번한 소스코드 변경으로 인해 애자일 개발 모델이 많이 사용된다.

 

💡애자일 개발 모델이란? 

개발 팀에 속한 모든 팀원(개발자, 테스터, 기획자 등)이 동시에 같은 요구사항에 대해서 작업을 하는 방식
반대 개념으로는 신속 애플리 케이션 개발 모델(RAD, Papid Application Development)이 있으며 각자가 다른 업무를 수행한다.

 

애자일 개발 모델에서는 애플리케이션 요구사항을 우선순위에 따라 분류하고, 분류된 요구 사항별로 개발을 진행하는데 이때 분류한 일정량의 작업을 분석하고 구현하는데 할당된 작업기간을 스프린트(=sprint)라고 한다.

 

애자일의 애플리케이션은 스프린트를 반복하며 완성되는데 스프린트 기간은 보통 1주~3주로 짧은 기간이며 동일한 프로젝트에서 작업하는 개발자들이 각자 자신이 맡은 기능을 구현하고 구현 과정에서 변경한 코드를 한꺼번에 메인 브랜치(빌드를 생성할 때 사용)에 커밋한다.

 

하지만 이렇게 변경 코드를 한 번에 병합하게 되면 코드 충돌같은 문제들이 발생할 수 있는데 애자일 개발 모델에서는 이 문제의 해결을 위해 개발자가 작업을 완료하는 즉시 메인 브랜치에 통합하는 지속적 통합 방식을 사용한다. 변경사항이 많지 않을 때 자주 통합하게 되면 개발자는 코드 충돌 문제를 좀 더 빠르게 발견할 수 있고, 회귀 결함이 발생해도 더 효율적으로 해결할 수 있다는 장점이 있다. 

💡회귀 버그란 이전에 제대로 작동하던 소프트웨어 기능에 문제가 생기는 것을 가리킨다. 

 

🖥️ 개발 워크플로

 

1️⃣ 로컬에서 단위 테스트 실행

   - GIT 또는 SVN 과 같은 형상 관리 중앙 리포지터리에서 최신 코드를 로컬로 가져와 요구 사항을 구현하며, 주로 TDD(테스트 주도 개발) 방식을 사용하여 구현한다.

TDD(Test-Driven Development)란?

- 테스트 주도 개발로 코드를 구현하기 전에 테스트 케이스를 먼저 작성하는 개발방식

- 처음엔 테스트 케이스만 작성되어있고 구현부는 없이 테스트를 해 모두 실패로 시작하게되며 구현부 코드를 작성해나가 점점 성공률을 높여 나간다.

2️⃣ 중앙 리포지터리로 코드 푸시 및 병합

   - 로컬에서 기능 구현 완료 후 중앙 리포지터리로 코드를 push, 메인 브랜치에 merge 한다.

3️⃣ 병합 후 코드 컴파일

   - 메인브랜치에 병합이 되면 코드 컴파일을 수행하는데 이때 새로 병합된 코드로 인해(잘못된 코드 작성 시) 컴파일 오류가 발생할 수도 있다.

4️⃣ 컴파일된 코드에서 테스트 실행

   - 컴파일 완료 후 단위 테스트와 통합테스트를 실행해 회귀결함이 있는지 확인하며 그 외에도 코딩 표준 준수 및 불필요한 코드의 존재 여부 체크와 같은 정적 분석 작업이 추가된다.

5️⃣ 아티팩트 배포

   - 단계별 품질 점검이 끝나면 모든 코드를 패키징(.war 또는 .jar 확장자)하고, 최종 사용자가 사용할 수 있도록 서버에 배포한다.

 

🖥️ 지속적 제공/지속적 배포(CI/CD) 워크플로

1️⃣ 최신 코드 가져오기

    - GIT 또는 SVN과 같은 중앙 코드 리포지터리에서 로컬 시스템으로 애플리케이션의 최신 코드를 가져온다.

2️⃣ 단위 테스트와 구현의 실행

   - 신규 요청 사항의 구현 코드를 작성하기 전 단위 테스트 케이스를 우선 작성한다. 구현부의 코드를 작성하지 않았기 때문에 처음엔 모든 테스트 케이스들이 실패한다.

3️⃣ 코드 개발

    - 실패한 테스트 케이스를 성공으로 바꾸기 위해 비어있던 기능의 구현부를 제대로 구현한다.

4️⃣ 단위 테스트 케이스 재실행

    - 단위 테스트 재실행 시 성공한다.

5️⃣ 코드 푸시와 병합

    - 새로 추가한 소스 코드를 중앙 리포지터리에 푸시하고, 애플리케이션 코드에 병합한다.

6️⃣ 코드 병합 후 컴파일

    - 소스코드가 병합되면 전체 애플리케이션이 컴파일 된다.

7️⃣ 병합된 코드에서 테스트 실행

   - 컴파일된 애플리케이션의 전체 통합 테스트를 실행해 추가된 코드로 인해 문제가 발생하지 않는지 확인한다.

8️⃣ 아티팩트 배포

   - 웹 애플리케이션을 빌드하고, 애플리케이션 서버(ex.톰캣)의 프로덕션 환경에 배포한다.

9️⃣ 배포 애플리케이션의 E-E 테스트 실행

   - 셀레늄 같은 UI 자동화 도구를 사용해 애플리케이션의 전체 워크플로가 정상 동작하는지 확인하는 종단간(End-To-End) 테스트를 실행한다.

셀레늄은 웹 애플리케이션 자동화 및 테스트를 위한 포터블 프레임워크이다. 셀레늄은 테스트 스크립트 언어를 학습할 필요 없이 기능 테스트를 만들기 위한 플레이백 도구를 제공한다.

---

🎈젠킨스란?

젠킨스는 소프트웨어 개발 프로세스의 다양한 단계를 자동화하는 도구로서 중앙 소스 코드 리포지터리에서 최신 코드 가져오기, 소스 코드 컴파일, 단위 테스트 실행, 산출물을 다양한 유형으로 패키징, 산출물을 여러 종류의 환경으로 배포하기 등의 기능을 제공하며 무료로 자유롭게 사용할 수 있는 오픈 소스 라이선스 소프트웨어이다.

 

젠킨스는 아파치 톰캣처럼 서블릿 컨테이너 내부에서 실행되는 서버 시스템이다. 자바로 작성됐고, 소프트웨어 개발과 관련된 다양한 도구를 지원한다. 

 

🧀젠킨스를 이용한 CI/CD 구현

 CI/CD 프로세스는 애플리케이션 코드에 변경이 발생하면, 그 변경 사항이 실행 파일이나 라이브러리 형태로 프로덕션 환경에 배포될 때까지 End-To-End 빌드 수명 주기 단계에서 검증을 하는 프로세스이다.

젠킨스에서는 파이프라인이라고 부르는 스크립트를 작성할 수 있는데 이를 사용해서 각 빌드 단계마다 젠킨스가 수행할 태스크 및 하위 태스크의 순서를 정의하며, 빌드 단계는 이전 단계의 결과가 다른 단계의 입력으로 주어지는 방식으로 순차적으로 이루어진다. 이렇게 순차적이고 종속적인 단계가 시작부터 끝까지 실행되면 최종적으로는 사용자가 실행할 수 있는 빌드가 생성된다.

만일 빌드 프로세스를 진행하는 중에 특정 단계에서 실패 발생 시 이 단계의 출력 결과를 사용하는 다음 단계는 실행되지 않고 빌드 프로세스 전체가 실패한다.

 

🎪 젠킨스 아키텍쳐

일반적인 젠킨스의 CI/CD 프로세스는 다음과 같다.

 

1️⃣다수의 개발자가 각자의 브랜치에서 변경 작업을 한 후, 이를 중앙 리포지터리로 푸시한다. 코드 리뷰가 끝나면 이를 다른 브랜치(개발 브랜치)에 병합한다.

2️⃣ 브랜치의 변경 사항이 젠킨스에 통보된다.

3️⃣ 젠킨스가 통보를 수신하면 작업(JOB)을 시작한다.

     3-1) 사용중인 소스코드 관리 시스템에 맞는 플러그인(git)을 사용해 리포지터리에서 변경된 파일을 가져온다.

     3-2) 메이븐(maven)같은 빌드 도구와 관련 젠킨스 플러그인을 사용해 변경된 파일을 컴파일한다.

     3-3) 빌드 도구를 재사용해 컴파일된 코드의 단위/통합 테스트를 실행한다.

     3-4) 정적 분석 도구를 실행해 코딩 표준을 준수하느지와 데드 코드가 있는지를 확인한다. 정적 분석 도구로는 소나큐브등을 사용한다.

     3-5) 컴파일과 테스트까지 완료된 파일들을 .jar 또는 .war 같은 라이브러리 형태로 번들링한다. 이 과정 역시 젠킨스 플러그인으로 실행되는 빌드 도구를 사용한다.

     3-6) 빌드된 라이브러리 파일을 테스트/프로덕션 환경으로 배포한다.

     3-7) E-E 테스트 자동화 도구를 사용해 배포된 애플리케이션을 대상으로 테스트를 실행한다.

     3-8) 새로 생성된 애플리케이션의 상태와 E-E 테스트 결과가 포함된 이메일을 프로젝트 팀원들에게 전송한다.