젠킨스로 배우는 CICD 파이프라인: CICD란?(1)

 

* 공부하게 된 취지? 

• AWS에 관심을 갖게 되다가 Devops라는 문화에서 또한 AWS가 도구로 많이 사용된다는 사실을 알게 되었고 데브옵스라는 문화는 코드의 통합과 배포를 위해서 실행되는 사이클을 이야기하며 이를 CI/CD라고 부르는 알게 되었다. 그리고 CI/CD를 위해서는 종합적으로 흐름을 진행해 줄 수 있는 도구가 필요한데 그중에서 Jekins라는 도구를 알게 되었다.
• 젠킨스는 CI/CD툴로 여러 CI 및 CD 툴들과 연동하여 파이프라인을 만들어서 코드를 통합시키고 검사하고 테스트시키고 배포까지 자동으로 도와주는 툴이다. 그래서 해당 툴을 한번 공부해 보고자 하자는 취지였다.
• 아래에는 공부할때 참고한 교재이다.
  • https://product.kyobobook.co.kr/detail/S000212572110

젠킨스로 배우는 CI/CD 파이프라인 구축 | 프라노데이 프라모드 딩가레 - 교보문고

 

 

 

* 애자일 모델 이란? 

• CI/CD라는 용어는 본래 '애자일'이라는 방법에서 나왔다.
• 애자일(Agile)의 뜻은 '민첩함', '기민함'이라는 뜻이 있다.
• 애자일 개발 모델이란 개발 팀에서 모든 팀원(개발자, 테스터, 기획자)이 같은 요구 사항에 대해서 일하는 방식.
• 고객의 요구사항에 지속적으로 대응하고 또한 반영을 빠르게 하기 위해서 만들어진 효율적인 개발 방식이다.
• 애자일에 반대되는 말은 'RAD'로 Rapid Application Development 의 약자로 신속한 개발을 요구하는 방식이다.
  • 이는 개발 모델에서 각자 다른 업무를 수행하며 예를 들어 기획자가 작성한 요구사항을 개발자가 구현하고 개발자가 완료한 작업은 테스트가 수행하는 식이다. 
• 애자일 개발 모델에서는 애플리케이션 요구 사항을 우선순위에 따라 분류하고 개발을 진행.
• 이때 분류한 일정량의 작업을 분석하고 구현하는데 할당된 작업기간을 스프린트(작은 개발 주기)라고 한다.
• 애자일에서 애플리케이션은 스프트린트를 반복하며 완성한다. 스프린트랑 주기 기간은 1~3주이다.
• 동일한 프로젝트에서 작업하는 개발자들은 각자 자신이 맡은 기능을 주현하고 변경된 코드는 한 번에 메인 브랜치에 커밋한다.
• 그러다 보면 한번에 여러 작업을 병합하는데 코드가 충돌 나거나 회귀 결함(이전에 작동하던 코드가 오류가 생기는 것) 증상이 발생하기도 한다. 
• 애자일 개발 모델에서는 이런 문제를 해결하기 위해서 지속적 통합 방식을 사용하여 짧은 주기로 코드를 통합하여서 코드의 충돌 문제를 더 빠르게 찾고 효율적으로 해결할 수 있게 하였다. 그리고 자동화된 배포를 통해서 문제가 생겼는지 빠르게 확인할 수 있다. 

 

 

* 개발 워크플로

• 개발 워크 플로는 팀이 어떤 프로젝트를 진행하기 위해 따르는 체계적으로 반복적인 시스템.
• 로컬 단위 테스트 실행
  • 개발자는 중앙 레포지터리에서 최신코드를 가져온다. 가져와서 요구 사항에 맞게 테스트 주도 개발을 한다.
  • 테스트 주도 개발이란 일종의 테스트 코드를 먼저 만들어서 구현해 나아가는 방식이다. 
  • 테스트 주도 개발 방식으로 여러 단위 테스트를 거쳐서 성공적으로 통과 할 때까지 반복적으로 수정한다.
• 중앙 리포지터리로 코드 푸시 및 병합
  • 개발자가 로컬에서 기능 구현을 완료한 후 중앙 리포지터리에 push하면 메인 브랜치에 병합된다.
• 병합 후 코드 컴파일
  • 구현을 완료한 코드가 메인 브랜치에 병합되면 컴파일을 수행하여 오류를 검출한다.
• 컴파일된 코드에서 테스트 실행
  • 병합된 코드가 컴파일이 완료된 후에 단위 테스트와 통합 테스트를 실행해 회귀 결함이 있는지 확인.
• 아티팩트 배포
  • 병합된 코드의 단계별 품질 점검이 끝나면 모든 코드를 패키징하고 최종 사용자가 사용할 수 있도록 서버에 배포.
  • 아티팩트는 개발로 인해서 만들어진 산출물을 의미한다. 보통 .war 이나 .jar 파일 형식이다.

 

 

* 지속적 통합/지속적 배포 > CI(Countine Integrate / Continue Deployment)/CD

• 위에서 처럼 개발 워크플로 반복적으로 진행하여 지속적인 통합을 하면 최대한 코드의 완성을 높여서 안정적으로 코드를 만들수 있다. 
• 지속적 통합에서는 애플리케이션 코드가 변경될 때마다 개발환경에서 테스트가 수행되고 빌드 결과가 공개된다.
• 정기적인 빌드 외에도 일상적인 코드 변경에도 테스트 및 확인 과정을 거치는 것이 중요하다.  
• 왜냐하면 개발 환경에서 잘 작동 되던 코드가 프로덕션 환경에서 문제를 일으킬 수도 있다. 기존과는 다른 소프트웨어나 하드웨어에서 호환되지 않기 때문이다.