지속적 통합의 원칙
지속적 통합에 필요한 원칙을 살펴봅니다. 다음 원칙은 Martin Fowler가 제시한 원칙입니다. 그중에서도, 여러 가지 원칙 중 여러분이 현재 기억해야 할 항목을 먼저 소개하고, 천천히 이해해도 되는 부분을 구분하였습니다.
- 단일 소스 레파지토리를 유지해야 합니다.
- 프로젝트에서 제품을 빌드하기 위해 함께 조정해야 하는 수많은 파일이 포함되기 때문입니다.
- 이 모든 파일이 단일 소스 레파지토리가 아닌 곳에 뿔뿔이 흩어져 있다면 추적하는 것이 굉장히 힘들어질 것입니다.
- 빌드를 자동화해야 합니다.
- 사람들에게 이상한 명령을 입력하게 하거나 대화 상자를 클릭하게 하는 것은 시간 낭비입니다.
- 빌드가 수동으로 진행된다면, 수많은 실수를 낳을 수 있습니다.
- 셀프 테스팅 빌드를 만들어야 합니다.
- 빌드 프로세스에 자동화된 테스트를 포함 함으로써 버그를 더 빠르고 효율적으로 파악할 수 있습니다.
- 지속적 통합의 일부인 테스트 주도 개발(TDD)을 통해 손상된 빌드를 즉시 확인, 수정할 수 있습니다.
- 매일 메인라인에 커밋을 해야 합니다.
- 각자의 진행 상황을 추적하는 데 도움이 됩니다.
- 짧은 주기로 커밋을 하므로, 충돌이 발생한 후 빠르게 충돌 상황을 감지할 수 있습니다.
- 해당 시점에는 충돌이 많이 발생하지 않아 문제를 쉽게 해결할 수 있습니다.
- 만약 통합의 빈도가 길어 충돌을 늦게 발견하게 된다면 문제를 해결하기 매우 어려울 수 있습니다.
- 메인라인: 시스템의 현재 상태를 의미합니다. 회사마다 어떤 브랜치를 메인라인으로 두는지는 조금씩 다르지만, 여기서는 master 브랜치를 메인라인으로 취급하도록 하겠습니다.
- 모든 팀원이 무슨 일이 일어나고 있는지 알아야 합니다.
- 지속적 통합은 커뮤니케이션에 관한 것이므로 모든 사람이 시스템 상태와 시스템에 적용된 변경 사항을 쉽게 확인할 수 있어야 합니다.
기타 원칙
위에서 언급한 원칙 외에도, 그밖에 Martin Fowler가 제시한 나머지 원칙도 함께 소개합니다. 다음은 천천히 이해해도 좋습니다.
- 모든 커밋은 통합 서버의 메인라인에서 빌드 돼야 합니다.
- 개발자 간 개발 환경에 차이가 있기 때문입니다.
- 빌드의 오류를 즉시 수정할 수 있어야 합니다.
- 빌드가 중단되는 것이 나쁜 것은 아니지만, 이러한 상황이 매번 항상 발생하는 경우 사람들이 커밋 전에 로컬에서 업데이트 및 빌드에 대해 충분히 주의하지 않고 있음을 시사합니다.
- 지속적 통합 도구를 사용하면 빌드의 오류를 즉시 확인할 수 있습니다.
- 빌드가 빨리 되도록 유지해야 합니다.
- 지속적 통합의 요점은 신속한 피드백을 제공하는 것입니다.
- 오랜 시간이 걸리는 빌드는 지속적 통합의 가장 큰 장애물입니다.
- 운영 환경과 동일한 환경에서 테스트가 진행돼야 합니다.
- 다른 환경에서 테스트하는 경우 환경의 차이로 인해 테스트에서 발생하는 일이 프로덕션에서 발생하지 않을 위험이 있습니다.
- 누구나 최신 실행 파일을 쉽게 얻을 수 있어야 합니다.
- 배포 자동화가 이루어져야 합니다.
- 지속적 통합을 수행하려면 커밋 테스트를 실행하기 위한 환경과 2차 테스트를 실행하기 위한 하나 이상의 환경이 필요합니다. 이러한 환경 간에 실행 파일을 하루에 여러 번 이동하기 때문에 이 작업을 자동으로 수행하고 싶을 것입니다. 따라서 응용 프로그램을 모든 환경에 쉽게 배포할 수 있는 스크립트를 갖는 것이 중요합니다.
- 매일 프로덕션에 배포하지 않을 수도 있지만, 자동 배포는 프로세스 속도를 높이고 오류를 줄이는 데 도움이 됩니다. 또한 테스트 환경에 배포하는 데 사용하는 것과 동일한 기능을 사용하기 때문에 저렴한 옵션이 될 수 있습니다.
지속적 통합에서 테스트가 중요한 이유
- 테스트를 통해 결함과 버그를 조기에 발견할 수 있으며, 이는 개발자의 생산성을 향상할 수 있습니다.
- 제품의 결함과 버그를 발견하고 수정하는 것은 소프트웨어의 품질을 보증하고, 더 안정적이고 사용하기 쉽게 만듭니다.