DevOps Day 33 (4.20) 지속적 통합

지속적인 통합
팀 구성원이 각자의 작업을 자주 통합하는 소프트웨어 개발 방식 – Martin Fowler

이 방법을 도입함으로써 얻을 수 있는 장점에 대해서는 앞서 다음과 같이 설명했습니다 :
- 버그를 일찍 발견할 수 있다.
- 빌드 및 테스트와 같이 사람이 해야 할 일들을 자동화할 수 있다.
- 테스트가 완료된 코드에 대해 빠른 전달이 가능하다.
- 지속적인 배포가 가능해진다.
- 개발자의 생산성을 향상할 수 있다.

 

생각해봐야하는 질문들 :
지속적 통합이 있기 전에는 어떻게 릴리스를 만들었을까요?
지속적 통합을 도입함으로써 기존의 개발 방식의 어떠한 문제를 해결해 주었을까요?
지속적 통합을 통해 어떻게 버그를 일찍 발견할 수 있는 걸까요?
지속적 통합 과정에서 반드시 자동화가 이뤄져야 하는 부분은 어떤 부분인가요?

 

지속적 통합의 원칙과 장점
지속적 통합의 원칙 :
1. 단일 소스 레파지토리를 유지해야 합니다.
 - 프로젝트에서 제품을 빌드하기 위해 함께 조정해야 하는 수많은 파일이 포함되기 때문입니다.
 - 이 모든 파일이 단일 소스 레파지토리가 아닌 곳에 뿔뿔이 흩어져 있다면 추적하는 것이 굉장히 힘들어질 것입니다.

 

2. 빌드를 자동화해야 합니다.
 - 사람들에게 이상한 명령을 입력하게 하거나 대화 상자를 클릭하게 하는 것은 시간 낭비입니다.
 - 빌드가 수동으로 진행된다면, 수많은 실수를 낳을 수 있습니다.

 

3. 셀프 테스팅 빌드를 만들어야 합니다.
 - 빌드 프로세스에 자동화된 테스트를 포함 함으로써 버그를 더 빠르고 효율적으로 파악할 수 있습니다.
 - 지속적 통합의 일부인 테스트 주도 개발(TDD)을 통해 손상된 빌드를 즉시 확인, 수정할 수 있습니다.

 

4. 매일 메인라인에 커밋을 해야 합니다.
메인라인: 시스템의 현재 상태를 의미합니다.
 - 각자의 진행 상황을 추적하는 데 도움이 됩니다.
 - 짧은 주기로 커밋을 하므로, 충돌이 발생한 후 빠르게 충돌 상황을 감지할 수 있습니다.
   - 해당 시점에는 충돌이 많이 발생하지 않아 문제를 쉽게 해결할 수 있습니다.
   - 만약 통합의 빈도가 길어 충돌을 늦게 발견하게 된다면 문제를 해결하기 매우 어려울 수 있습니다.

 

5. 모든 팀원이 무슨 일이 일어나고 있는지 알아야 합니다.
- 지속적 통합은 커뮤니케이션에 관한 것이므로 모든 사람이 시스템 상태와 시스템에 적용된 변경 사항을 쉽게 확인할 수 있어야 합니다.

 

기타 원칙 :
6. 모든 커밋은 통합 서버의 메인라인에서 빌드 돼야 합니다.
 - 개발자 간 개발 환경에 차이가 있기 때문입니다.

 

7. 빌드의 오류를 즉시 수정할 수 있어야 합니다.
- 로컬에서 업데이트 및 빌드에 대해 충분히 주의하지 않고 있음을 시사합니다.
- 지속적 통합 도구를 사용하면 빌드의 오류를 즉시 확인할 수 있습니다.

 

8. 빌드가 빨리 되도록 유지해야 합니다.
- 지속적 통합의 요점은 신속한 피드백을 제공하는 것입니다.
- 오랜 시간이 걸리는 빌드는 지속적 통합의 가장 큰 장애물입니다.

 

9. 운영 환경과 동일한 환경에서 테스트가 진행돼야 합니다.
- 환경의 차이로 인해 테스트에서 발생하는 일이 프로덕션에서 발생하지 않을 위험이 있습니다

 

10. 누구나 최신 실행 파일을 쉽게 얻을 수 있어야 합니다.

 

11. 배포 자동화가 이루어져야 합니다.
- 응용 프로그램을 모든 환경에 쉽게 배포할 수 있는 스크립트를 갖는 것이 중요합니다.
- 매일 프로덕션에 배포하지 않을 수도 있지만, 자동 배포는 프로세스 속도를 높이고 오류를 줄이는 데 도움이 됩니다. 또한 테스트 환경에 배포하는 데 사용하는 것과 동일한 기능을 사용하기 때문에 저렴한 옵션이 될 수 있습니다.

 

지속적 통합에서 테스트가 중요한 이유 :
- 테스트를 통해 결함과 버그를 조기에 발견할 수 있으며, 이는 개발자의 생산성을 향상할 수 있습니다.
- 제품의 결함과 버그를 발견하고 수정하는 것은 소프트웨어의 품질을 보증하고, 더 안정적이고 사용하기 쉽게 만듭니다.