지속적 통합(CI)에 대한 팀의 이행만큼 민첩성을 구축하거나 파괴하는 요소는 없습니다. 불길하게 들릴 수도 있지만(특히 팀이 아직 CI를 수용하지 않은 경우) 좋은 소식도 있습니다. 팀이 사용하는 기술과 관계없이 코드 베이스에 적합한 지속적 통합 및 자동화 테스트 프레임워크가 있을 가능성이 있습니다.
지속적 통합이란 무엇입니까?
지속적 통합은 코드 변경 사항을 리포지토리의 기본 브랜치에 일상적으로 통합하고 변경 사항을 가능한 한 조기에 자주 테스트하는 애자일 및 DevOps 모범 사례입니다. 이상적으로는 개발자가 하루에 여러 번은 아니더라도 매일 코드를 통합하는 것이 좋습니다.
지속적 통합의 장점
CI에 투자하면 코드 변경에 대한 피드백을 빠르게 얻을 수 있습니다. 여기서 빠르다는 건 "몇 분 이내"라는 뜻입니다. 주로 수동 테스트에 의존하는 팀은 몇 시간 내에 피드백을 받을지도 모르지만 사실 포괄적인 테스트 피드백은 코드가 변경된 후 하루 또는 며칠 후에 제공됩니다. 그때쯤 되면 더 많은 변경 사항이 발생하여 개발자는 문제의 근원에 도달하기 위해 마치 고고학 탐험처럼 여러 계층의 코드를 파헤치면서 버그 수정을 해야 합니다.
그러면 절대로 빠르지 않습니다.
지속적 빌드 및 테스트 자동화로 품질 보호
최신 소스 코드를 다운로드했는데 컴파일되지 않았거나 심각한 버그가 있다는 것을 발견한 경우가 얼마나 많습니까? 생산성 킬러입니다!
두 가지 관행을 통해 이 상황에서 벗어날 수 있습니다.
지속적 빌드: 변경이 이루어지는 즉시 프로젝트를 빌드합니다. 각 빌드 간의 델타는 단일 변경 집합인 편이 이상적입니다.
테스트 자동화: 품질을 보장하기 위해 소프트웨어를 프로그래밍 방식으로 검증합니다. 테스트는 UI(자세한 내용은 잠시 후 확인) 또는 백엔드 서비스 계층의 소프트웨어에서 작업을 시작할 수 있습니다.
두 가지 관행이 피넛버터와 젤리라고 생각해 보세요. 따로 먹어도 맛있고 함께 먹어도 맛있습니다. 지속적 통합은 지속적 빌드와 테스트 자동화를 결합하여 각 빌드가 코드 베이스의 품질도 평가하도록 합니다.
또한 장점을 완전히 실현하려면 팀이 개발을 일시 중지하고 오류를 즉시 해결할 수 있는 규율도 있어야 합니다. 빌드가 손상된 상태에서 약화된다면 팀이 테스트를 작성하고 자동화를 구성하는 데 '투자'하는 에너지는 모두 헛수고가 됩니다. CI에 대한 투자를 보호하고 코드 베이스의 품질을 보호하는 것은 결국 같은 일입니다.
CI 테스트: 단위, API 및 기능 테스트
CI 실행에는 두 가지 주요 단계가 있습니다. 1단계에서는 코드가 컴파일되는지 확인합니다. (또는 통역 언어의 경우 모든 코드를 하나로 모으기만 하면 됩니다.) 2단계에서는 코드가 디자인대로 작동하는지 확인합니다. 가장 확실하게 확인하는 방법은 제품의 모든 수준을 검증하는 일련의 자동화된 테스트를 사용하는 것입니다.
단위 테스트
단위 테스트는 코드의 핵심 구성 요소와 매우 가깝게 실행됩니다. 품질을 보장하는 첫 번째 방어선입니다.
장점: 코드 베이스의 아키텍처를 쉽게 작성하고 빠르게 실행하며 밀접하게 모델링할 수 있습니다.
단점: 단위 테스트는 소프트웨어의 핵심 구성 요소만 검증합니다. 여러 구성 요소가 함께 작동하는 사용자 워크플로는 반영되지 않습니다.
단위 테스트는 코드의 작동 방식을 설명하므로 개발자는 단위 테스트를 검토하여 코드의 해당 영역에 대한 최신 정보를 얻을 수 있습니다.
API 테스트
좋은 소프트웨어는 모듈식이므로 여러 애플리케이션에서 작업을 더 명확하게 구분할 수 있습니다. API는 서로 다른 모듈이 통신하는 끝점이며, API 테스트는 한 모듈에서 다른 모듈로 호출하여 유효성을 검사합니다.
장점: 일반적으로 쓰기 쉽고 빠르게 실행되며 애플리케이션이 상호 작용하는 방식을 쉽게 모델링할 수 있습니다.
단점: 코드의 간단한 영역에서 API 테스트는 일부 단위 테스트를 모방할 수 있습니다.
API는 애플리케이션 부분 간의 인터페이스이므로 릴리스를 준비할 때 특히 유용합니다. 릴리스 후보 빌드가 모든 API 테스트를 통과하면 팀은 훨씬 더 확신을 가지고 고객에게 제공할 수 있습니다.
기능 테스트
기능 테스트는 코드 베이스와 모델 사용자 워크플로의 더 넓은 영역에서 작동합니다. 예를 들어 웹 애플리케이션에서 HttpUnit 및 Selenium은 사용자 인터페이스와 직접 상호 작용하여 제품을 테스트합니다.
장점: 버그가 사용자 작업을 모방하고 여러 구성 요소의 상호 운용성을 테스트하므로 버그가 발견될 가능성이 높습니다.
단점: 단위 테스트보다 느리며, 네트워크 대기 시간이나 기술 스택 어딘가의 순간적인 중단으로 인해 거짓 음성이 보고되는 경우가 있습니다.
팀들은 실제 사용자 워크플로에 가까워질수록 자동화된 테스트 실행 속도가 느려진다는 사실을 종종 알게 됩니다. HttpUnit은 본격적인 웹 브라우저가 아니기 때문에 더 빠릅니다. Selenium은 웹 브라우저의 최대 속도만큼만 실행할 수 있지만 여러 웹 브라우저에서 병렬로 실행할 수 있다는 장점이 있습니다. 위와 같은 단점에도 불구하고 기능 테스트는 매우 가치가 있으며 인간 테스터보다 훨씬 빠르게 피드백을 제공합니다.
여기서 덧붙이자면...
일부 테스터는 자동화된 테스트를 실질적 위협으로 간주합니다. 이 생각은 근시안적이며 진실과 매우 거리가 멉니다. 테스터는 지긋지긋한 반복 테스트 작업에서 벗어나 위험 분석, 테스트 계획 및 코딩 학습과 같은 다른 스킬을 구축하는 데 시간을 할애할 수 있습니다.
지속적 통합을 빠르게 하기
Atlassian은 개발자가 계속 혁신하고 코드 베이스를 건강하게 유지할 수 있도록 노력합니다. 개발자의 "내부 피드백 루프" 즉 변경 사항을 구축하고 테스트 결과를 얻는 데 필요한 시간을 줄이는 것에 중점을 둡니다.
자동화된 테스트를 실행하면 구축 기간이 빠르게 늘어나고 늘어질 수 있습니다. 여러 서버에서 자동화된 테스트를 병렬화하거나 "에이전트를 구축"하여 CI 서버가 실제로 2개, 20개 또는 200개의 테스트를 동시에 실행하도록 하는 것도 한 가지 전략입니다. 클라우드 기술을 사용하면 테스트 스위트가 확장되면서 개발 팀의 요구 사항에 맞게 CPU를 쉽게 확장할 수 있습니다. 그러나 CPU는 무제한이 아닙니다. 코드의 각 영역을 완전히 테스트하지만 중복하여 테스트하지 않습니다. 중복 테스트는 구축 기간을 늘리고 CPU를 낭비합니다. 엔지니어가 녹색 표시등을 더 빨리 받을수록 백로그에서 다음 항목으로 더 빠르게 이동할 수 있습니다.
브랜칭 및 CI: 천생연분의 관계
많은 팀이 고통스러운 합병 때문에 브랜칭을 피합니다. Git과 같은 최신 버전 제어 기술을 사용하면 브랜칭 및 병합이 모두 쉬워집니다. 기본 코드 줄(Git 용어로 "main")이 정상적으로 유지되도록 하려면 모든 개발 및 안정 버전 브랜치에서도 동일한 수준의 지속적 통합을 실행합니다. 빌드가 브랜치를 통과하면 팀은 해당 코드를 업스트림으로 병합할 수 있다는 확신을 갖게 됩니다.
브랜칭, 지속적 통합 및 테스트 자동화를 통해 팀은 생산적이고 혁신적인 동시에 코드 품질을 보호할 수 있습니다.다음 단계를 밟을 준비가 되었으면 CI 시작을 위한 단계별 가이드를 확인하세요.
최고의 애자일 개발입니다. 기술적 부채를 최소화하고 독창성을 손상하지 않으면서도 제대로 작동하는 소프트웨어를 정기적으로 제공합니다.