개요
우선, Jenkins 기반의 CI/CD 환경을 구축하기 전 용어들의 개념, 특징들을 정리해서 개념을 익히고 가자.
DevOps
'Development' + 'Operation' 의 합성어로 개발(Development)와 운영(Operation)을 결합해 탄생한 개발 방법론이다.
시스템 개발자와 운영을 담당하는 정보기술 전문가 사이의 소통, 협업, 통합 및 자동화를 강조하는 소프트웨어 개발 방법론이다.
오늘 포스팅 할 글은 통합 및 자동화에 초점을 맞춘 CI/CD에 관한 글이다.
이러한 DevOps의 개념은 계획이나 문서를 기반으로 앞을 예측하며 개발하는 것이 아니라 고객과 소통하며 지속적으로 프로토 타입을 형성하고 필요한 요구사항을 파악하여 이에 따라 즉시 수정사항을 적용하는 적응형 개발방법인 애자일 소프트웨어 개발(Agile Software Develop)방법과 연관이 있다.
애자일(Agile)과 DevOps
- 애자일(Agile)을 통해 자주 배포하면 Ops는 병목현상이 일어나게 된다.
- 애자일은 개발에서 운영으로 소프트웨어를 넘겨주는 것을 완료로 본다면 DevOps는 운영을 포괄한다.
- 시작점이 다르기 때문에 강조하는 부분이 다를 뿐 지향점은 같고 본질도 다르지 않다.
CI/CD?
CI/CD를 구축하기 전 CI/CD가 무엇이고, 왜 구축해야 하는지 정리를 해보겠다.
CI(Continuous Integration)
CI(Continuous Integration)는 지속적 통합이다. 모든 개발자의 작업 복사본을 공유된 메인라인으로 하루에 몇 번씩 병합하는 소프트웨어 엔지니어링 작업 방식이다.
Application에 대한 새로운 코드변경 사항을 정기적으로 build 및 test 한 후, 공유 레포지토리에 통합하는 과정을 의미한다.
이것이 성공적으로 구현한다면 여러 명의 개발자가 동시에 Application 개발과 관련된 코드 작업을 하더라도 충돌 등의 문제 발생을 최소화 할 수있다.
CD(Continuous Delivery/Deployment)
CD(Continuous Delivery/Deployment)는 지속적 배포이다. 팀이 소프트웨어를 짧은 주기로 만들어 소프트웨어가 언제든지 안정적으로 출시될 수 있도록 하는 소프트웨어 엔지니어링 접근 방식이다.
앞서 정리한 CI의 확장으로 코드의 변경사항을 통합한 이후 이를 배포하는 과정까지 자동화하는 것을 의미한다.
CI/CD가 필요한 이유
- CI/CD는 불필요한 반복 작업을 줄여, 반복 작업을 통해 발생할 수 있는 문제나 과도한 시간 소요 같은 문제들을 최소화 할 수 있다.
- CI/CD를 이용하면 초기 설정에 다소 시간이 소요되겠지만, 한번만 잘 설정하면 Git이나 SVN과 같은 형상관리 툴에 코드 수정을 하더라도 버튼 클릭 한번 혹은 Push나 PR 승인 한번에 빌드 및 테스트, 배포를 자동화 할 수 있어 배포 과정이 매우 단순해지므로 혼자서 수십개의 배포 파이프라인을 관리할 수도 있다.
소프트웨어 개발 LifeCycle 내의 CI/CD
CI/CD를 사용하려면?
- 모든 작업에 대해 적어도 하루에 한번씩 자동화된 빌드 및 테스트를 수행해야 한다.
- 모든 개발자는 버전 관리에 대한 변경 사항을 적용해야 하며, Jenkins로 구축 및 테스트를 거쳐야 한다.
- Jenkins는 코드를 병합하거나 코드 충돌을 해결 해 주지는 않는다. (개발자의 몫)
CI/CD 프로세스 예시
- 개발자가 git과 같은 Repository에 commit 하는 순간 triggering이 되어 trigger가 발동된다.
즉, commit 이 많을 수록 CI/CD가 많이 돈다고 볼 수 있다. - trigger가 발동되면 CI/CD 서버가 돌게되는데 CI Server 내에서 Compile, Test, Package를 통해 실제 Web Server와 같은 서비스 서버에 Deploy 한다.
또 다른 방식의 docker를 이용한 CI/CD 방식도 있다.
- 개발자가 git과 같은 Repository에 commit을 하면 위 방식과 동일하게 triggering이 된다.
- CI Server에서는 Compile, Test를 거치고 패키징 되신 도커 이미지를 Build한다.
- Docker 입장에서 봤을 땐 image는 하나의 실행 파일이다.
- 이 image파일을 Host에 올리고 실행(Run)시키면 반영이 완료된다.
Jenkins
Jenkins 개념
모든 언어의 조합과 소스 코드 Repository에 대한 지속적인 통합(Continuous Integration, CI)과 지속적 배포(Continuous Delivery/Deployment, CD) 환경을 구축하기 위한 도구이다.
Build, Test, Deploy 프로세스를 자동화 하여 소프트웨어 품질과 개발 생산성을 높일 수 있다.
Jenkins 특징
- 편리한 설정
- 웹 기반의 콘솔로 다양한 인증 기반과 결합이 가능하며 권한 관리 기능을 통해 안전한 Build 및 Deploy 환경을 구축할 수 있다.
- 수많은 Plug In을 사용하여 자동화 할 수 있어 반복되는 작업을 줄일 수 있다.
- Build/Deploy 결과에 대해 통지 받을 수 있는 설정이 간편하고 다양한 채널을 통해 빠르게 피드백을 받을 수 있다.
- 안정적인 Build/Deploy 환경
- 버전 관리 툴(github, svn 등)과 연동하여 코드 변경을 감지하고, 자동화 테스트를 포함한 Build를 수행하여 소프트웨어 품질을 향상시킬 수 있다.
- 자동화 테스트에는 코딩 표준 준수 여부 체크, Unit Test, Integration Test 등을 설정할 수 있고 테스트 결과에 대한 피드백을 받아 잠재적인 오류를 사전에 예방할 수 있다.
- Build 결과물을 지속적으로 배포하도록 설정하여 개발 프로세스 전체를 자동화 할 수 있다.
Jenkins 장점
- 자유도가 높다.
- 어떤 환경에서든 적용 가능하다.
- 많이 사용되고 있는 오픈 소스 소프트웨어로 문서화가 잘 되어 있다.
- Build/Deploy 이외에도 스케줄링을 이용한 배치 작업에도 활용되는 등 다양한 적용 사례들을 참고할 수 있다.
- Plug in을 직접 개발하여 기능을 확장하는 것도 가능하다.
Jenkins 단점
- 운영하기 어렵다.
- 구축하고 관리하는 단계조차도 Cost이다.
Pipeline
Pipeline 개념
- 소프트웨어에 대한 모든 변경은 릴리즈 되는 과정에서 프로세스를 거쳐야 한다. (ex. 단위/인수/통합 테스트 수행 -> 빌드 수행 -> 배포수행)
- 위 예시와 같은 프로세스를 수동으로 한다면 개발할 수록 소프트웨어 변경 작업은 더욱 많아질 것이고 그럴 때마다 반복적인 수행을 해야한다.
- 반복적인 수행을 수동으로 하다보면 휴먼 에러가 발생할 여지가 있다.
- pipeline을 통해 여러 단계의 테스트 및 빌드, 그리고 배포를 자동화하여 반복을 줄일 수 있고, 안정적인 작업이 가능하다.
Pipeline 사용 이유
- 모든 브랜치에 대한 PR(Pull Request)에 대해 pipeline 빌드 프로세스를 생성하기 때문에 쉽게 배포할 수 있다.
- pipeline 프로세스 실행 시 로그 추적이 가능하여 문제가 생겼을 때 확인이 수월하다.
