귀하의 질문에 완벽하게 반영되는 CI (Continuous Integration)에 대한 한 가지 근본적인 문제가 있습니다. CI 서버 소프트웨어는 설정하기가 쉽지 않기 때문에 CI 사례를 구현하고 방어하기가 어렵거나 프로젝트를 CI를 통해 실행하는 것이 쉽지 않습니다. 섬기는 사람. 이를 통해 실제로 CI 수용의 이점이 어디에 있는지 알기가 어려워집니다.
우선, CI는 통찰력과 품질에 관한 것입니다. Good CI는 프로젝트에보다 가까이 다가 가고 품질 메트릭, 문서, 코딩 표준 준수 등에 대한 적절한 피드백을 제공합니다.이 모든 것을 쉽게 시각화하고 한눈에 파악하고 쉽게 이해할 수있는 도구를 제공해야합니다. 일련의 변경 사항을 이러한 모든 프로젝트 메트릭의 특정 스냅 샷과 연결하십시오.
단순히 단위 테스트를 실행하는 것이 아닙니다 . 전혀! 어느 정도 품질을 제공합니다. CI는 오류를 수용하며, 오류를 피하거나 버리지 않습니다. 그것이하는 일은 나중에 대신에 일찍 오류를내는 도구를 제공하는 것입니다. 따라서 이전에 테스트 한 코드를 CI 서버에 실제로 커밋하지 않습니다. 깨끗하고 깨지지 않은 코드를 커밋하려고 노력해야하지만 실제로는 CI 서버를 사용하여 코드를 통해 자동으로 통합 빌더를 자동으로 실행하고 모든 것이 올바르게 완료되었는지 평가해야합니다. 있다면 깔끔한! 문제가 해결되지 않았다면 아무런 문제가 없습니다. 훌륭한 CI 관행은 다음 우선 순위가 깨져있는 것을 고쳐야한다는 것입니다. 좋은 CI 서버에서는 쉽게 지적 할 수 있습니다.
팀 규모가 커짐에 따라 모든 사람의 코드 통합이 자연스럽게 어려워집니다. 중앙 집중식 CI 서버가 모든 통합 부품을 테스트하고 팀 구성원에게 부담을주는 것이 작업이어야합니다. 따라서 모든 사람이 조기에 (그리고 가능한 한 깨끗하게) 커밋 한 다음 빌드 상태를 모니터링해야합니다 (보통 알림이 포함되어 있음). 또한 개발자의 커밋으로 인해 문제가 발생하면 즉시 문제를 해결하고 자동화 된 빌드를 즉시 OK 상태로 되돌릴 책임이 있습니다.
제 생각에는 모든 단일 프로젝트가 지속적으로 통합되는 것이 좋습니다. 지금까지 내가 아는 모든 단일 CI 서버의 복잡한 복잡성 때문에 사람들은 소규모 / 간단한 프로젝트에서 CI 관행을 실제로 지키지 못했습니다. 사람들은 추악하고 지나치게 복잡하며 배달이 부족한 부풀린 소프트웨어를 구성하는 데 며칠을 소비하는 것보다 더 좋은 일을하기 때문입니다.
나는 똑같은 문제를 겪었고, 그 때문에 약 1 년 전부터 자유 시간에 Cintient를 개발하게되었습니다. 저의 전제는 설치, 구성 및 사용을 간단하게하고 다른 모든 제품이 거의 실패하거나 미달하는 품질 메트릭을 제공하도록하는 것이 었습니다. 그래서이 긴 대답 후에 프로젝트에 대한 GitHub 링크 (무료 및 오픈 소스, natch)를 지적하는 뻔뻔스러운 플러그가옵니다. 또한 멋진 스크린 샷이 있습니다. :-) https://github.com/matamouros/cintient
내가 당신을 도왔기를 바랍니다.
(참고 : Bryan Oakley의 의견에 따라 더 나은 답변을 얻기 위해 더 많은 시간을 할애해야한다는 사실에 대해 편집했습니다. 또한 그가 옳다고 생각합니다.)