지속적 통합 설정 방법
지속적 통합 및 자동 테스트를 도입하는 방법을 5단계로 알아보세요.
Sten Pittet
기고 작가
지속적 통합(CI)은 개발자가 코드 변경 사항을 메인 브랜치나 코드 리포지토리에 조기에 자주 통합하는 애자일 및 DevOps 모범 사례입니다. 목표는 프로젝트 또는 스프린트가 종료될 때까지 기다렸다가 모든 개발자의 작업을 병합하여 “통합 지옥”에 빠질 위험을 줄이는 것입니다. 배포를 자동화하기 때문에 팀이 비즈니스 요구 사항을 충족하고 코드 품질을 개선하며 보안을 강화할 수 있습니다.
CI를 도입할 때의 주요 이점은 충돌을 조기에 식별하고 해결하여 개발 주기에서 시간을 절약할 수 있다는 것입니다. 좋은 테스트 스위트를 만드는 데 더 중점을 두어 버그 수정과 회귀에 소요되는 시간을 줄일 수 있는 좋은 방법이기도 합니다. 마지막으로 고객을 위해 개발 중인 코드베이스와 기능을 더 잘 이해할 수 있습니다.
지속적 통합을 향한 여정의 첫 번째 단계: 자동 테스트 설정.
자동화된 테스트 시작하기
다양한 유형의 테스트 이해
CI의 이점을 최대한 활용하려면 테스트를 자동화하여 메인 리포지토리가 변경될 때마다 테스트를 실행해야 합니다. 메인 브랜치에만 초점을 맞추는 것이 아니라 리포지토리의 모든 브랜치에서 테스트를 실행해야 합니다. 이렇게 하면 문제를 조기에 포착하고 팀의 혼란을 최소화할 수 있습니다.
구현되는 테스트에는 여러 종류가 있지만 이제 막 시작하는 단계라면 모든 것을 한꺼번에 다 할 필요는 없습니다. 단위 테스트로 소규모로 시작하고 시간이 지나면서 커버리지를 늘릴 수 있습니다.
- 단위 테스트는 범위가 좁으며 일반적으로 개별 메서드나 함수의 동작을 검증합니다.
- 통합 테스트는 여러 컴포넌트가 제대로 동작하는지 확인합니다. 여기에는 여러 클래스는 물론 다른 서비스와의 통합 테스트도 포함될 수 있습니다.
- 수용 테스트는 통합 테스트와 비슷하지만 컴포넌트 자체보다는 비즈니스 사례에 초점을 맞춥니다.
- UI 테스트는 사용자의 관점에서 애플리케이션이 제대로 작동하는지 확인합니다.
솔루션 보기
Open DevOps로 소프트웨어를 구축 및 운영
관련 자료
자동화된 테스트에 대해 자세히 알아보기
모든 테스트는 다르며 Mike Cohn이 개발한 테스트 피라미드를 사용하면 얻을 수 있는 장단점을 시각화할 수 있습니다.
단위 테스트는 대부분 작은 코드를 검사하기 때문에 낮은 비용으로 빠르게 구현할 수 있습니다. 반면 전체 환경을 시작하고 브라우저나 모바일 동작을 에뮬레이션하기 위한 여러 서비스가 필요한 경우가 많기 때문에 UI 테스트는 구현하기가 복잡하고 실행 속도가 느립니다. 그 때문에 복잡한 UI 테스트의 수를 제한하고 기본적으로 효과적인 단위 테스트에 의존하여 빠른 빌드를 만들고 가능한 한 빨리 개발자에게 피드백을 받는 것이 좋을 수도 있습니다.
테스트 자동 실행
지속적 통합을 채택하려면 메인 브랜치에 푸시되는 모든 변경 사항에 대해 테스트를 실행해야 합니다. 그러려면 리포지토리를 모니터링하고 코드베이스에 대한 새로운 푸시 메시지를 수신할 수 있는 서비스가 필요합니다. 온프레미스와 클라우드 모두 선택 가능한 솔루션이 많습니다. 서버를 고르려면 다음 사항을 고려해야 합니다.
- 코드는 어디에서 호스팅됩니까? CI 서비스가 코드베이스에 액세스할 수 있습니까? 코드가 있을 수 있는 위치에 특별한 제한이 있습니까?
- 애플리케이션에 어떤 OS 및 리소스가 필요합니까? 애플리케이션 환경이 지원됩니까? 소프트웨어를 빌드하고 테스트하기 위해 알맞은 종속성을 설치할 수 있습니까?
- 테스트에 리소스가 얼마나 필요합니까? 일부 클라우드 애플리케이션은 사용 가능한 리소스에 제한이 있을 수 있습니다. 소프트웨어가 리소스를 많이 소비한다면 방화벽 뒤에 CI 서버를 호스팅하는 것이 좋을 수도 있습니다.
- 팀에 개발자가 몇 명입니까? 팀에서 CI를 실천하면 매일 많은 변경이 메인 리포지토리에 다시 푸시될 것입니다. 개발자가 빠른 피드백을 받으려면 빌드의 큐 시간을 줄여야 하고 올바른 동시성을 제공하는 서비스 또는 서버를 사용해야 합니다.
예전에는 보통 Bamboo 또는 Jenkins와 같은 별도의 CI 서버를 설치해야 했지만 이제는 Cloud에서 채택이 훨씬 간편한 솔루션을 찾을 수 있습니다. 예를 들어 코드가 Bitbucket Cloud에 호스팅되면 별도의 서버를 구성하거나 에이전트를 빌드하지 않아도 동시성에 대한 제한 없이 리포지토리에서 Pipelines 기능을 사용하여 푸시마다 테스트를 실행할 수 있습니다.
image: node:4.6.0 pipelines: default: - step: script: - npm install - npm testBitbucket Pipelines 자바스크립트 리포지토리를 테스트하는 구성의 예.
코드 검사를 이용하여 테스트되지 않은 코드 찾기
자동 테스트를 채택한 후에는 테스트 스위트가 코드베이스를 얼마나 포함하는지 알 수 있는 테스트 커버리지 도구와 결합하는 것이 좋습니다.
80% 이상의 커버리지를 목표로 하는 것도 좋지만 높은 비율의 커버리지를 효과적인 테스트 스위트와 혼동하지 않도록 합니다. 코드 검사 도구는 테스트되지 않은 코드를 찾을 수 있지만 결국 차이는 테스트의 품질에서 옵니다.
막 시작한 단계라면 코드베이스의 100% 커버리지를 얻기 위해 서두르지 말고 테스트 커버리지 도구를 사용하여 아직 테스트가 없는 애플리케이션의 주요 부분을 찾아내고 거기서부터 시작하세요.
리팩터링은 테스트를 추가할 기회
애플리케이션에 중대한 변경을 하려는 경우 영향을 받을 수 있는 기능에 대한 수용 테스트를 작성하는 것부터 시작해야 합니다. 이렇게 하면 코드를 리팩터링하거나 새 기능을 추가한 후에도 원래 동작이 영향을 받지 않도록 보장하는 안전망을 갖추게 됩니다.
지속적 통합을 채택하는 데 있어 중요한 성공 요소
테스트 자동화는 CI의 핵심적인 부분이기는 하지만 그 자체로는 충분하지 않습니다. 개발자가 변경 사항을 다시 메인 브랜치에 병합하지 않은 채로 며칠씩 기능 작업을 하지 않도록 팀 문화를 바꿔야 할 수도 있으며 초록색 빌드의 문화를 시행해야 합니다.
조기에 자주 통합
트렁크 기반 개발이든 기능 브랜치를 사용하든 개발자가 최대한 빨리 메인 리포지토리에 변경 사항을 통합하는 것이 중요합니다. 브랜치나 개발자 워크스테이션에 코드를 너무 오래 놔두면 메인 브랜치에 다시 병합하려고 할 때 충돌이 너무 많이 발생할 위험이 있습니다.
일찍 통합하면 변경의 범위가 줄어들어 충돌이 발생했을 때 더 쉽게 이해할 수 있습니다. 또 다른 장점은 개발자가 변경에 대해 더 쉽게 이해할 수 있으므로 개발자 간에 지식을 공유하기가 더 쉬워진다는 것입니다.
기존 기능에 영향을 줄 수 있는 변경 사항을 만드는 경우 기능 플래그를 사용하여 작업이 완료될 때까지 프로덕션에서 변경 사항을 비활성화할 수 있습니다.
빌드를 항상 초록색으로 유지
개발자가 메인 브랜치의 빌드를 고장내면 빌드를 고치는 것이 최우선 과제가 됩니다. 고장난 상태에서 빌드에 더 많은 변경 사항이 포함될수록 고장의 원인을 이해하기가 더 어려워지고 실패가 더 많이 발생할 위험도 있습니다.
테스트 스위트가 빠르게 실패할 수 있는지 확인하고 변경 사항을 푸시한 개발자에게 최대한 빨리 피드백을 제공하는 데 시간을 할애할 가치가 있습니다. 테스트를 분할하여 빠른 테스트(예: 단위 테스트)가 장기적으로 실행되는 테스트보다 먼저 실행되도록 할 수 있습니다. 테스트 스위트가 실패하는 데 항상 오랜 시간이 걸리면 이전 작업으로 돌아가서 고치기 위해 컨텍스트를 바꿔야 하므로 개발자의 시간을 많이 낭비하게 됩니다.
빌드가 고장날 때 개발자에게 알림을 받도록 설정하는 것도 잊지 마세요. 그리고 모두가 볼 수 있는 대시보드에 메인 브랜치의 상태를 표시하여 한층 더 노력할 수도 있습니다.
스토리의 일부로 테스트 작성
마지막으로, 개발되는 모든 기능에 자동 테스트가 있는지 확인해야 합니다. 개발 속도가 느려지는 것처럼 보일 수 있지만 이렇게 하면 팀이 반복마다 발생하는 회귀 또는 버그를 수정하는 데 걸리는 시간이 대폭 줄어듭니다. 또한 테스트 스위트는 이전에 개발한 모든 기능이 예상대로 작동하는지 빠르게 확인할 수 있기 때문에 안심하고 코드베이스를 변경할 수 있습니다.
효과적인 테스트를 작성하려면 개발자가 사용자 스토리의 정의에서 초기에 관여하도록 해야 합니다. 비즈니스 요구 사항을 더 잘 이해하고 제품 관리자와의 관계를 지원할 수 있는 훌륭한 방법입니다. 테스트를 완료할 코드를 구현하기 전에 테스트를 작성하는 것부터 시작해도 됩니다.
버그 수정 시 테스트 작성
기존 코드베이스가 있든 또는 이제 막 시작한 단계든 릴리스의 일부로 버그는 분명히 발생할 것입니다. 문제가 다시 발생하지 않도록 해결할 때 테스트를 추가하세요.
CI를 사용하면 QA 엔지니어가 품질을 규모에 맞게 확장할 수 있습니다
CI 및 자동화 채택에 따라 달라지는 또다른 역할은 QA 엔지니어의 역할입니다. 더 이상 애플리케이션의 사소한 기능을 수동으로 테스트할 필요가 없으며 이제 개발자를 지원하고 올바른 테스트 전략을 채택하도록 돕는 도구를 제공하는 데 더 많은 시간을 할애할 수 있습니다.
지속적 통합을 채택하기 시작하면 QA 엔지니어가 더 나은 도구와 데이터 세트로 테스트를 지원하는 데 집중하고 개발자가 더 나은 코드를 작성하는 능력을 기를 수 있습니다. 복잡한 사용 사례에 대한 예비 테스트도 여전히 있겠지만 이들의 업무에서 중요한 부분은 아닐 것입니다.
지속적 통합 설정을 위한 5단계
이제 지속적 통합의 이면에 있는 개념을 이해하셨을 것입니다. 요약하면 다음과 같습니다.
- 코드베이스의 중요한 부분에 대한 테스트 작성을 시작합니다.
- CI 서비스를 받아서 메인 리포지토리에 푸시할 때마다 해당 테스트를 자동으로 실행합니다.
- 팀이 매일 변경 사항을 통합하도록 합니다.
- 빌드가 고장나는 즉시 고칩니다.
- 새로 스토리를 구현할 때마다 테스트를 작성합니다.
쉬워 보일 수도 있지만 효과를 발휘하려면 팀의 진정한 헌신이 필요합니다. 처음에는 릴리스 속도를 늦춰야 하며 개발자가 테스트 없이 급하게 기능을 출시하지 않도록 제품 소유자의 승인을 받아야 합니다.
Atlassian에서 권장하는 사항은 관리하기 어려울 수 있는 더 복잡한 테스트 스위트를 구현하는 단계로 넘어가기 전에 간단한 테스트부터 소규모로 시작하여 새로운 루틴에 익숙해지는 것입니다.
Bitbucket Pipelines를 통한 지속적 통합에 대해 알아볼 수 있습니다. DevOps 도구 체인을 구축하려면 주요 공급업체 및 Marketplace 앱과의 통합이 포함된 Open DevOps를 확인해 보세요.
이 문서 공유
다음 주제
여러분께 도움을 드릴 자료를 추천합니다.
이러한 리소스에 책갈피를 지정하여 DevOps 팀의 유형에 대해 알아보거나 Atlassian에서 DevOps에 대한 지속적인 업데이트를 확인하세요.
DevOps 커뮤니티
블로그 읽기
