지속적인 통합-요구 사항
다음은 지속적인 통합을위한 가장 중요한 요구 사항 목록입니다.
Check-In Regularly− 지속적 통합이 제대로 작동하기위한 가장 중요한 관행은 소스 코드 저장소의 트렁크 또는 메인 라인에 자주 체크인하는 것입니다. 코드 체크인은 적어도 하루에 두 번 이상 이루어져야합니다. 정기적으로 체크인하면 다른 많은 이점이 있습니다. 변경 사항을 더 작게 만들어 빌드를 중단 할 가능성이 적습니다. 이는 후속 빌드에서 실수가있을 때 되돌릴 소프트웨어의 최신 버전이 알려져 있음을 의미합니다.
또한 코드 리팩토링에 대해 더 잘 훈련하고 동작을 보존하는 작은 변경 사항을 고수하는 데 도움이됩니다. 많은 파일을 변경하는 변경 사항이 다른 사람의 작업과 충돌 할 가능성을 줄이는 데 도움이됩니다. 이를 통해 개발자는 마지막으로 커밋 된 버전으로 되돌려 아이디어를 시도하고 폐기 할 수 있습니다.
Create a Comprehensive Automated Test Suite− 포괄적 인 자동화 테스트 모음이없는 경우 빌드를 통과하면 애플리케이션을 컴파일하고 어셈블 할 수 있다는 의미 일뿐입니다. 일부 팀의 경우 이것은 큰 단계이지만 애플리케이션이 실제로 작동하고 있다는 확신을 제공하기 위해 일정 수준의 자동화 된 테스트를 수행하는 것이 필수적입니다.
일반적으로 Continuous Integration에서는 3 가지 유형의 테스트를 수행합니다. unit tests, component tests, 및 acceptance tests.
단위 테스트는 애플리케이션의 작은 부분의 동작을 격리하여 테스트하기 위해 작성되었습니다. 일반적으로 전체 응용 프로그램을 시작하지 않고 실행할 수 있습니다. 데이터베이스 (응용 프로그램에있는 경우), 파일 시스템 또는 네트워크에 도달하지 않습니다. 프로덕션과 유사한 환경에서 애플리케이션을 실행할 필요가 없습니다. 단위 테스트는 매우 빠르게 실행되어야합니다. 대규모 애플리케이션의 경우에도 전체 제품군을 10 분 이내에 실행할 수 있어야합니다.
구성 요소 테스트는 응용 프로그램의 여러 구성 요소 동작을 테스트합니다. 단위 테스트와 마찬가지로 항상 전체 애플리케이션을 시작할 필요는 없습니다. 그러나 데이터베이스, 파일 시스템 또는 기타 시스템 (스텁 아웃 될 수 있음)에 충돌 할 수 있습니다. 구성 요소 테스트는 일반적으로 실행하는 데 더 오래 걸립니다.
Keep the Build and Test Process Short − 코드를 빌드하고 단위 테스트를 실행하는 데 너무 오래 걸리면 다음과 같은 문제가 발생합니다.
사람들은 전체 빌드를 중지하고 체크인하기 전에 테스트를 실행합니다. 실패한 빌드가 더 많이 발생하기 시작합니다.
지속적 통합 프로세스는 빌드를 다시 실행할 수있을 때까지 여러 커밋이 발생했을 정도로 오래 걸리므로 어떤 체크인이 빌드를 중단했는지 알 수 없습니다.
사람들은 소프트웨어가 빌드되고 테스트가 실행될 때까지 오래 기다려야하기 때문에 체크인 빈도가 줄어 듭니다.
Don’t Check-In on a Broken Build− 지속적인 통합의 가장 큰 실수는 손상된 빌드를 확인하는 것입니다. 빌드가 중단되면 책임있는 개발자가 수정을 기다리고 있습니다. 그들은 가능한 한 빨리 파손의 원인을 식별하고 수정합니다. 이 전략을 채택하면 항상 파손의 원인을 파악하고 즉시 수정할 수있는 최상의 위치에있을 것입니다.
동료 중 한 명이 체크인하여 빌드를 망가 뜨린 경우 문제를 해결할 수있는 최상의 기회를 얻으려면 문제에 대한 명확한 실행이 필요합니다. 이 규칙을 어기면 빌드를 수정하는 데 시간이 더 오래 걸립니다. 사람들은 빌드가 깨지는 것을 보는 데 익숙해지고, 빌드가 항상 깨져있는 상황에 매우 빠르게 접하게됩니다.
Always Run All Commit Tests Locally Before Committing− 항상 애플리케이션 용으로 설계된 테스트를 CI 서버에서 실행하기 전에 먼저 로컬 컴퓨터에서 실행해야합니다. 이는 올바른 테스트 케이스가 작성되었는지 확인하고 CI 프로세스에 실패가있는 경우 실패한 테스트 결과 때문입니다.
Take Responsibility for All Breakages that Result from Your Changes− 변경 사항을 커밋하고 작성한 모든 테스트는 통과했지만 다른 테스트가 중단되면 빌드가 여전히 중단됩니다. 일반적으로 이는 애플리케이션에 회귀 버그를 도입했음을 의미합니다. 변경을 수행했기 때문에 변경의 결과로 통과하지 못한 모든 테스트를 수정하는 것은 사용자의 책임입니다. CI의 맥락에서 이것은 분명해 보이지만 실제로는 많은 프로젝트에서 일반적인 관행이 아닙니다.