CI(Continuous Integration) 개념, 개인 CI vs 팀 CI

2023.10.31 - [해축갤 프로젝트/테스트 코드] - postman 띡띡딸깍 귀찮아서 테스트 코드 짭니다

postman 띡띡딸깍 귀찮아서 테스트 코드 짭니다

이제 테스트 코드도 다 작성했겠다, CI 를 본격적으로 구축해 보기로 했다.

근데 사실 뭐 자동 테스트 빌드 등등의 키워드로만 알고 제대로는 알지 못해

어디 가서 아는 척좀 하려고 찾아봤다!

 

CI 란

지속적 통합은 자동화된 빌드 및 테스트가 수행된 후 개발자가 코드 변경 사항을
중앙 리포지토리에 정기적으로 병합하는 데브옵스 소프트웨어 개발 방식입니다.

출처 : https://aws.amazon.com/ko/devops/continuous-integration/

 

말이 좀 어려워서 쉽게 풀어보자면 

작업 중인 코드를 주기적으로 github에 합치는 것을 의미합니다.

합칠 때 (build + test 자동화)라는 프로세스를 거치고!

핵심 개념 및 장점 

핵심 개념에는 4가지로 볼 수 있겠습니다!

1. 빈번한 통합
   관리가 쉬워 개발자들이 코드 변경사항을 자주 github에 통합 가능
2. 자동화된 build & test
   매 통합마다 시스템이 자동으로 build&test
3. 신속한 문제 해결
   자동화된 build&test 로 초기에 오류 및 버그 탐지
4. S/W 품질 향상
   빈번한 통합을 통해 점진적 개선이 가능

사실 핵심 개념이 곧 장점이기도 하다마는

그래도 장점을 딱 정리해 보자면 다음과 같습니다.

• 개발자 생산성 향상 -> 프로세스가 자동화되어 있어서
• 버그 초기 발견 가능 -> 자동 test를 통해
• 신속한 업데이트 제공 -> 점진적 개선이 가능하기 때문에

개인, 팀 프로젝트에서의 CI의 차이

CI에 대한 글들을 찾아보면 대부분 개인 프로젝트 선에서 정리한 것들이 많습니다.

저 또한 해축갤 프로젝트가 개인 프로젝트이지만, 동시에 팀 프로젝트를 진행 중이기도 하고

실제로 회사에서 팀 프로젝트시에는 Git의 관리가 더 세분화되어 있기 때문에 조금 다를 것이라 생각이 들어

그 차이에 대해 한번 찾아봤습니다.

 

혼자 진행하는 프로젝트에서의 CI

1. 개발 및 로컬 테스트: 프로젝트 코드를 로컬에서 개발하고 테스트합니다. 이는 CI와 독립적으로 이루어지는 단계입니다.
2. 커밋 및 푸시: 개발한 코드를 Git 저장소(예: GitHub)에 커밋하고 푸시합니다.
3. CI 트리거: GitHub에 코드를 푸시하면, 이는 CI 시스템(예: Travis CI, Jenkins, GitHub Actions)을 트리거합니다.
4. 자동화된 빌드 및 테스트: CI 시스템은 코드를 자동으로 빌드하고 테스트합니다. 여기서 단위 테스트, 통합 테스트 등이 실행됩니다.
5. 결과 확인: 테스트와 빌드 결과는 CI 시스템의 대시보드에서 확인할 수 있습니다. 오류가 있으면 이를 수정하고 다시 푸시합니다.

팀 기반 프로젝트에서의 CI

1. 개발 및 로컬 테스트: 각 팀원은 로컬에서 개별적으로 코드를 개발하고 테스트합니다.
2. 코드 리뷰 및 통합: 개발한 코드는 팀 리뷰를 거쳐 중앙 저장소에 통합됩니다.
3. 커밋 및 푸시: 검증된 코드를 중앙 저장소(GitHub 등)에 커밋하고 푸시합니다.
4. CI 트리거 및 자동화된 테스트: 중앙 저장소에 코드가 통합될 때마다 CI 시스템이 자동으로 빌드 및 테스트를 수행합니다.
5. 결과 확인 및 피드백: 모든 팀원은 CI 시스템에서 빌드 및 테스트 결과를 확인하고 필요한 경우 수정 사항을 논의합니다.

사실 뭐 비슷하기는 하다만, 개인 프로젝트와 다르게 팀 프로젝트에서는

비즈니스 로직이라던지, 코드 리뷰와 같은 팀적인 프로세스가 좀 더 추가된다!

라고 보면 되겠습니다 :)

 

참고

지속적 통합이란 무엇입니까? – Amazon Web Services