개발자가 코드를 수정하고 빌드와 테스트를 하고 배포까지 한다면 많은 시간이 소요됩니다. 하지만 Git에 올리는 것만으로 누군가 이 과정을 해준다면 시간을 단축시킬 수 있습니다.
CI/CD는 애플리케이션 개발 단계부터 배포까지 모든 단계를 자동화하여 좀 더 효율적이고 빠르게 사용자에게 빈번히 배포할 수 있는 것을 말합니다.
CI ( Continous Integration ) 는 지속적인 통합
이라는 의미로 간단히 요약하면 빌드/테스트 자동화 과정
을 말합니다.
애플리케이션의 버그 수정이나 새로운 코드 변경이 주기적으로 빌드 및 테스트
하면서 레파지토리에 통합 ( merge ) 하는 것을 의미하며 여러 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 코드 충돌이 발생할 수 있는 문제를 방지할 수 있습니다.
지속적인 통합은 커밋할 때 마다 빌드와 테스트가 자동으로 이루어져 문제가 발생하는 것을 방지합니다.
개발자들이 하나의 프로젝트를 진행하고 있으며, 형상관리 툴 ( git , svn 등.. ) 을 사용하고 있습니다. 여기서 여러 개발자들이 빈번하게 merge 하지 않고 오랜 기간 동안 개발을 진행하면서 작업한 많은 코드를 한번에 merge하게 되면 충돌되는 코드가 많이 생길 수 있습니다.
이렇게 되면 새로운 기능의 코드를 작성하는 시간보다, 충돌된 코드들를 수정하는 데 더 많은 시간을 쓸것입니다.
그렇기때문에, 가능한 작은 단위로 나누어서 주기적으로 빈번히 개발하고 계속해서 통합하는 것이 중요합니다.
주기적으로 merge된 코드의 Build와 Test 과정은 자동적으로 되어야 합니다.
개발자들은 하루에 몇차례 코드의 변경사항을 레포지토리에 푸시를 하면 CI 스크립트가 코드를 build 하고 , Test 를 실행하여 배포합니다. 이런 과정은 단순 반복이므로 개발자가 하는것은 비 효율적입니다.
주기적인 merge로 충돌 가능성이 낮아져 개발 생산성이 증가하며 버그와 문제점을 빠르게 찾을 수 있습니다. 또한 테스트를 통과한 코드만 레포지토리에 올라가기 때문에 안정성있고 좋은 퀄리티를 유지할 수 있습니다.
CD ( Continuous Delivery ) 는 지속적인 제공
이라는 의미와 , CD ( Continuous Deployment ) 지속적인 배포
라는 의미가 있습니다.
CI 에서 Build 되고 Test 된 후에, 배포 단계에서 release할 준비 단계를 거치고 문제가 없는지 개발자나 검증하는 팀이 검증을 하게 되고 이후에 서비스를 제공해도 되겠다는 판단이 되면 수동적으로 프로덕션 환경으로 배포를 진행하는 것이 CD ( Continuous Delivery ) 지속적인 제공
이라 말하고
CD ( Continuous Deployment ) 지속적인 배포
는 CI 에서 Build 되고 Test 된 후에, 배포 단계에서 release 할 준비가 되면 자동화를 통해 고객이 사용 가능한 프로덕션 환경까지 배포하는 것을 의미합니다.
지속적인 제공은 개발팀과 비즈니스 팀 사이의 가시성과 커뮤니케이션 문제를 해결해 주고, 지속적인 배포는 수동 프로세스로 인한 운영팀의 프로세스 과부하 문제를 해결합니다!
배포 단계에서 release할 준비 단계를 거치게 된다는 뜻은 레포지토리에 업로드 된다는 것을 말합니다.
개발자는 배포보다는 개발에 더욱 신경을 쓸 수 있으며 품질 저하 없이 최대한 빨리 사용자에게 새로운 기능을 제공할 수 있습니다.
파이프라인이라고 하는 이유는 배포 자동화 과정들이 물이 흐르듯 흘러가는 것을 묘사해 그렇게 부르게 된것입니다.
컴퓨터 과학에서 파이프 라인은 제공된 데이터 또는 코드에 대해 사전정의된 작업을 수행하는 일련의 처리 단계입니다. 파이프 라인의 사용 목적은 반복적인 프로세스를 자동화하여 시간을 절약하고 정밀도를 높히는 것으로 파이프라인의 이러한 장점은 CI/CD 인프라와의 호환성와 효율성을 높여줍니다.
CI / CD 파이프 라인의 목표는 빌드 , 테스트 및 제공을 수동 처리보다 더 빠르고 안정적으로 만드는 것입니다.
젠킨스는 소프트웨어 개발 시 배포 서비스와 통합 서비스를 제공하는 자동화 도구 입니다. 젠킨스를 사용하면 소프트웨어 개발 프로세스의 자동화를 통해 개발자들이 소스 코드의 변경 사항을 빠르게 테스트하고 배포할 수 있습니다.
서버 어플리케이션에 기능을 추가하려면 개발자가 개발을 완료하고 테스트를 한 다음 빌드
과정을 끝마치고 서버에 반영하는 배포
를 해야합니다. 젠킨스는 소프트웨어의 버전 충돌을 방지하고 CI 가 가능하게 하는 도구로 Git 과 같은 버전관리 시스템과 연동하여 사용합니다.
빌드
는 서버에 올릴 수 있는 상태를 말하는 것을 말하며 서버에 올려서 사용자가 사용할 수 있게 만드는 것을 배포
라고 합니다.
SpringBoot 어플리케이션을 Maven이나 Gradle로 빌드해서 .jar .war 로 만든다음에 Docker 빌드로 Docker Image를 만듭니다. 이후 AWS EC2 서버에 도커 이미지를 실행시키는 것을 말합니다.
빌드는 하루에 한번할 수 있고 이 시간이 몇년동안 하게 된다면 많은 시간이 걸릴 수 있습니다. 그 예시로 자바를 빌드할 때 javac 라는 명령어를 사용했지만 지금은 IDEA 를 이용해 실행할 경우 javac를 하고 java를 실행합니다. 이렇게 반복되는 과정을 버튼 하나로 축약할 필요가 있습니다.
그 이유는 이 작업을 하는데에도 체력이 소모되며, 시간이 꽤 걸리는 작업으로 빌드를 하는 시간을 모아보면 엄청 걸릴 것 입니다.
위의 빌드를 자동화 해주는 툴입니다. 대표적인 기능으로 다음과 같습니다.
1. 대시보드 제공
하며 여러가지 배포 작업의 상황을 모니터링할 수 있습니다.
2. 배포 스크립트 실행가능
하며 배포 스크립트를 개발자 로컬에서도 실행할 수 있는데 젠킨스 프로그램을 띄워놓으면 스케줄링을 합니다.
3. 다양한 플러그인
이 있는데 이는 빌드를 하는 환경이 다양하고 언어도 다 다릅니다. 이것을 커버하기 위해 다양한 플러그인을 제공합니다.
Jenkins를 사용하기 위해 젠킨스 서버를 띄워야 합니다. 만약 AWS EC2 서버에 젠킨스를 띄우려면 VPS , Security Group , IAM 등을 알아야 하며 부족한 지식은 젠킨스가 서버에 접근하지 못합니다.
편리한 설정
웹 기반의 콘솔로 다양한 인증 기반과 결합하여 권한 관리 기능을 통해 안전한 빌트 / 배포 환경을 구축할 수 있습니다. 수많은 플러그인을 사용하여 자동화 할 수 있어 반복되는 작업을 줄일 수 있습니다. 빌드 / 배포의 결과에 대해 통지 받을 수 있는 설정이 간편하고 다양한 채널을 통해 빠르게 피드백을 받을 수 있습니다.
안정적인 빌드 / 배포 환경
소스 버전 관리 툴과 연동하여 코드 변경 사항을 감지하고, 자동화 테스트를 포함한 빌드를 수행하여 소프트웨어 품질을 향상시킬 수 있습니다. 자동화 테스트에는 코딩 표준 준수 여부 체크, 유닛 테스트, 통합 테스트 등을 설정할 수 있고 테스트 결과에 대한 피드백을 받아 잠재적인 오류를 사전에 예방할 수 있습니다. 빌드 결과물을 지속적으로 배포하여 개발 프로세스 전체를 자동화할 수 있습니다.
다양한 활용 및 손쉬운 확장
Jenkins는 많이 사용하는 오픈 소스 소프트웨어로 문서화가 잘 되어 있습니다. 빌드 / 배포 외에도 스케쥴링을 이용한 배치 작업에도 활용되는 등 다양한 적용 사례들을 참고할 수 있습니다. 플러그인을 직접 개발할 수 있습니다.
젠킨스는 자동화된 빌드와 테스트 작업을 하게 되는 여기서 젠킨스가 가져다주는 이점은 다음과 같습니다.
젠킨스와 같은 CI 툴이 등작하기 전에는 일정시간마다 빌드를 실행하는 방법이 일반적이었는데, 젠킨스는 서브버전 , Git 과 같은 버전 관리 시스템과 연동해서 소스의 커밋을 감지하면 자동적으로 자동화 테스트가 포함된 빌드가 작동하게 하여 편의성을 증가시켜 줍니다.
이러한 기능을 수행하는 젠킨스는 컴파일 오류를 검출
하고 , 자동화 테스트를 수행
하며, 정적 코드 분석으로 인한 코딩 규약 준수 여부
를 확인하고 프로파일링 툴을 통해 성능 변화 감시
, 결합 테스트 환경에 대한 배포 작업에 도움을 줍니다.
각종 배치 작업의 간략화
프로젝트 기간 중에 개발자들은 개발 작업 이외에 데이터베이스의 구축 , Deploy 작업과 같은 단순 작업에 시간과 노력을 들이는데, 이러한 작업들을 젠킨스를 사용함으로 해결할 수 있습니다.
코드 표준 준수여부 검사와 빌드 파이프라인 구성
젠킨스는 개인이 미처 하지 못한 코딩 표준 준수 여부나 정적 분석을 통한 코드 품질 검사
를 빌드 내부에서 수행합니다. 또한 2개 이상의 모듈로 구성되는 레이어드 아키텍처가 적용된 프로젝트에서 빌드 파이프라인 구성을 간단히 할 수 있으며, 스크립트를 통해 복잡한 제어까지 가능합니다.
자동화 테스트
자동화 테스트가 포함되지 않은 빌드는 CI 자체가 불가능에 가깝습니다. 젠킨스는 버전 관리 시스템과 연동하여 코드 변경을 감지하고 자동화 테스트를 수행하기 때문에 만약 개인이 실시하지 못한 테스트가 있어도 젠킨스가 테스트를 한번 더 수행합니다.
Agent Section
여러 slave를 두고 작업할 때 어떤 젠킨스가 어떤 일을 할지 정의
Post Section
각 스테이지가 끝난 후 후속 조치 설정
ex ) Success / failure / always / cleanup
Stage Section
어떤 일들을 처리할 것인지에 대한 Stage 정의 ( 카테고리 )
Declaratives
- Environ ment ( 파이프라인 및 stage scope의 환경변수 설정 )
Steps
실행할 작업 정의
Credentials Plugin
각종 리소스에 접근하기 위한 토큰, 키 등을 저장하고 관리하기 위한 플러그인
Git
git의 소스코드를 가져와 빌드하는 등 git과의 연동을 위한 플러그인
Pipeline
젠킨스의 핵심 기능인 파이프라인을 관리하기 위한 플러그인
Kubernetes
쿠버네티스 클러스터에서 동적인 에이전트 실행
Docker 이미지로 정의된 각 에이전트에 대한 pods를 작성하여 빌드 후 실행 후 종료
AWS CodeDeploy
젠킨스 프로젝트의 빌드 후 AWS 인스턴스로의 애플리케이션 배포
zip 파일을 Amazon 인스턴스 집합으로 roll-out 하여 배포
Blue Ocean
젠킨스 파이프라인을 가시성 좋게 변환하여 표시
Maven Integration
Maven을 이용하여 프로젝트를 빌드하고 JAR 또는 WAR 빌드 아티팩트 생성
Apache Maven을 사용하는 프로젝트에서 활용
JIRA Plugin
이슈 추적 도구인 JIRA와 Jenkins를 연동하는 플러그인
JIRA REST API를 이용하여 젠킨스 빌드 페이지에 대한 백 포인터 역할
Build Pipeline
업스트림 및 다운스트림 연결 작업을 미리보기로 시각화 하고 처음부터 끝까지 빌드 프로세스에 대한 개요 제공
작업에 수동 트리거를 추가하여 배포 전 검토와 같은 외부 프로세스를 파이프라인에 맞추기 가능
ThinBackup
빌드 기록으로 작업의 백업 및 구성 관리
자동 백업 기능을 통해 프로젝트를 쉽게 관리
Docker Build Step
동적인 프로비저닝을 위한 플러그인
다양한 도커 명령을 빌드 단계에서 사용
이미지에서 컨테이너 생성 / 컨테이너 시작 및 중지 등
=> 이외 Docker / Docker Pipeline 등이 있음
Jenkins Disk-usage
디스크 사용량 분석 플러그인
젠킨스 프로젝트의 디스크 사용량을 분석하여 알리고 예상치 못한 디스크 사용을 예방
Amazon EC2
: EC2 인스턴스와 젠킨스의 연동을 위한 플러그인
: ssh를 통한 publish를 하지 않아도 됨
Pipeline
CI/CD 파이프라인을 젠킨스에 구현하기 위한 플러그인 들의 구성
여러 플러그인들을 파이프라인에서 용도에 맞게 사용하고 정의하여 서비스 배포
Pipeline DSL(Domain Specific Language)로 작성
참고 블로그 1 : https://seosh817.tistory.com/104
참고 블로그 2 : 링크
참고 블로그 3 : https://krksap.tistory.com/1377
참고 블로그 4 : https://krksap.tistory.com/1806
참고 블로그 5 : https://2mukee.tistory.com/237
참고 블로그 6 : 링크
참고 유튜브 1 : https://www.youtube.com/watch?v=0Emq5FypiMM
블로그 1 ( 젠킨스 이론 ) : https://ict-nroo.tistory.com/31
블로그 2 : https://yeonyeon.tistory.com/56