연속 통합 (CI)이란 무엇이며 어떻게 유용합니까? [닫은]

Continious Integration의 개념을 이해하기 쉬운 방식으로 설명 할 수 있습니까? 그리고 회사는 왜 코드 전달 워크 플로우에서 CI를 채택해야합니까? 저는 개발자이며 회사 (주로 빌드 팀)는 Team City를 사용합니다. 개발자는 항상 SVN에 코드를 체크 아웃, 업데이트 및 커밋하지만 TeamCity 또는 CI에 대해 전혀 신경 쓰지 않아도됩니다. CI의 유용성이 무엇인지 이해하고 싶습니다. CI는 애자일 방법론의 일부입니까?

간단히 통합하면 작업을 저장하고 문서 관리 시스템 (귀하의 경우 SVN)으로 푸시하고 모든 테스트가 자동으로 실행되고 (단위, 통합, 기능 등 테스트) 응용 프로그램이 컴파일되고 준비됩니다. 배송 용 (예 : ISO 이미지 생성) 지속적인 통합은 지속적인 전달과 동일하지 않습니다. 배달은 여전히 ​​다른 순간에 이루어집니다. CI는 필요한 경우 제품을 더 이상 제공 할 수 있도록 보장합니다 .

문제가 생길 때마다 팀은 알림을받습니다. 일반적으로이 시점에서 모든 작업이 중단되고 모든 노력이 제품의 안정적인 방식을 유지하는 데 집중됩니다. 시스템이 녹색이 ​​아닌 동안 리포지토리에서 푸시 및 커밋이 발생하지 않습니다.

CI는 제품이 항상 안정적인 상태에 있고 언제라도 배송 될 수 있도록합니다. 안정은 기능 완료를 의미하지는 않습니다. 절반으로 구현 된 기능도있을 수 있지만 시스템은 안정적 일 수 있습니다.

CI는 일반적으로 애자일 방법론과 관련이 있지만 CI의 정확한 역사를 개인적으로 알지 못합니다.

지속적인 통합 : 실제로 실행되고 테스트 될 수있는 제품에 코드를 통합하는 것은 개발 수명주기 후반에 별도의 활동이 아니라 (이전과 마찬가지로) 항상 발생 합니다 .

애플리케이션의 빌드 프로세스가 완전히 자동화되고 자동화 된 테스트 스위트와 코드의 현재 상태를 빌드하고 테스트 스위트를 실행하는 서버가 필요합니다. 매일 또는 각 코드 체크인 후에도 발생합니다.

장점은 컴파일 오류를 유발하는 코드 변경 (예 : 개발자가 모든 변경 사항을 체크인하지 못하거나 빌드 시스템에없는 일부 구성 요소를 사용하기 때문에) 또는 테스트 사례 실패에 대한 즉각적인 피드백이 있다는 것입니다. 어떤 오류로 인해 오류가 발생했는지 알고 책임자는 여전히 자신이 한 일에 대한 새로운 기억을 가지고 있기 때문에 이러한 오류를 수정하기가 훨씬 쉽습니다.

CI가 없으면 이러한 모든 오류가 통합 단계에서 동시에 발생하여 수정하기가 매우 어렵습니다.

개발 에는 특정 스타일 이있을 수 있습니다 . 결제, 코딩, 컴파일, 확인, 저주, 변경, 컴파일, 응원, 커밋. 근무일이 끝날 때 또는 기능이 완료된 경우와 같이 덜 세분화 된 방식으로 작업 코드 만 커밋합니다. API 라이브러리를 가져올 때마다 종속성을 확인하십시오.

다른 사람과 함께 코딩을 시작하고 상호 종속성이있는 경우 지속적인 통합을 채택하는 것이 좋습니다. 코드에 의존하는 사람들에게 변경 사항이 미치는 영향을 알 수없고 가져 오기를 업데이트 할 때마다 신호가 수신되지 않기 때문입니다.

따라서 둘 중 하나를 변경하면 두 프로젝트를 함께 빌드하고 테스트해야합니다. 즉, 서로의 API에 대해 실행하고 새 라이브러리 등을 사용하여 빌드 및 테스트해야합니다. 이러한 테스트, 코드 및 다른 사람을 통합 테스트라고합니다.

왜 연속적인가? 코드베이스에 변경 사항이있을 때마다 사람을 위해 모든 것을 정리하는 것보다 깨끗한 빌드를 테스트하는 시스템에 통합 조정을 위임하는 것이 더 쉽기 때문입니다. 시스템을 확장 할 수 있습니다.

지속적인 통합에는 두 가지 측면이 있습니다.

1. 개발 소스 제어 전략을 통해 개발자는 진행중인 작업을 다른 개발자와 안정적인 코드로 지속적으로 통합 할 수 있습니다.
2. 소스 제어에 대한 커밋에 의해 트리거되는 소스 코드의 자동 빌드 및 테스트

포인트 1이 중요합니다. 개발자가 실제로 자주 수행하는 병합을 합병으로 전환하는 것이 합법적이고 소규모이기 때문에 병합의 성공 가능성이 훨씬 높습니다.

포인트 2는 포인트 1이 안전하게 발생하고 기존 코드를 손상시켜 실패한 병합을 신속하게 식별하는 데 필요한 도구 및 프레임 워크입니다.

얼마나 유용한가요?

엄청나게. 프로젝트를 진행하는 개발자는 대부분의 시간을 자신이하는 일에 집중하고 나머지 팀의 동시 작업에 대해 걱정하지 않아도됩니다. 현재 작업이 완료되면 나머지 팀에 변경 내용을 게시하고 다음 몇 시간 동안 변경 사항을 모두 현재 작업에 병합합니다.

그것없이 개발자들은 빅뱅 합병을하고 있습니다. 일반적으로 며칠 동안 작업을 수행하고 나머지 팀의 모든 변경 사항을 한 번에 병합해야합니다. 병합이 눈에 띄게 나빠지면 다른 개발자가 다른 작업으로 이동했을 가능성이 높으며 병합 혼란을 제거하는 데 도움이되는 세부 사항을 잊어 버릴 것입니다. 더 나쁜 것은, 지속적인 빌드와 테스트가 없다면 코드가 컴파일되는 한 병합 버그가 코드에 나타날 수 있으며 테스트 (또는 고객)가 찾을 때까지 포착되지 않습니다.

다음과 같은 경우 CI가 유용합니다.

• 코드 컴파일
• 실제 테스트 세트
• 소스 코드 (코드 적용 범위, 코드 표준 폭력 등)를 기반으로하는 보고서
• 코드가 성공적으로 컴파일 된 후 주기적으로 수행하는 루틴

목록을 계속할 수 있습니다 ..