Continuous Integration Certification

[emiling]

Continuous Integration Certification

출처 : https://martinfowler.com/bliki/ContinuousIntegrationCertification.html

[emiling]

지속적 통합(Continuous Integration)은 소프트웨어 개발에서 잘 알려진 기술입니다. 컨퍼런스에서 많은 개발자들이 CI를 어떻게 적용하고 있는지에 관해 말하고, CI 도구는 대부분의 개발 조직에서 흔하게 사용됩니다. 그러나 우리 모두 괜찮은 기술에는 인증 프로그램이 필요하다는 것을 알고 있고, 다행히도 그러한 인증 프로그램이 존재합니다. 지속적 배포(Continuous Delivery) 및 DevOps 분야의 최고 전문가 중 한 명이 개발한 이 솔루션은 관리 속도가 매우 빠르면서도 그 결과에 대한 통찰력이 매우 뛰어난 것으로 알려져 있습니다. 꽤 성숙된 기술이긴 하지만 생각보다 잘 알려지지 않았기 때문에, 한 명의 팬으로서 이 인증 프로그램을 독자들과 공유하는 것이 중요하다고 생각했습니다. CI 인증을 받을 준비가 되셨습니까? 그리고 이 인증을 치루었을 때 밝혀지는 충격적인 진실을 당신은 어떻게 해결할까요?

지금쯤이면 내 단골 독자들은 어디선가 이 포스팅에 대한 패러디(parady) 포스팅¹을 보지 않았나 생각할텐데, 정답입니다. 나는 티저를 공개하는 것에 약간 재미를 느낍니다. 그러나 어떠한 재밌는 농담도 그 안에는 중요한 진실의 핵심이 있습니다. Jez Humble에 의해 생성된 적절한 CI에 대한 매우 우수한 테스트가 있으며 그는 확실히 Continuous Delivery의 선두 전문가 입니다. 이는 또한 빠른 테스트이며, 그는 종종 연설 중에 청중에게 이 테스트를 시행합니다. 유일한 문제는 그가 이것을 인증 테스트라고 언급하는 것을 들어본 적이 없다는 것이고, 이는 단지 수익 계획에 대한 그의 비전이 부족하다는 것을 보여줍니다.

그는 보통 청중에게 CI를 수행하는 경우 손을 들어 달라고 요청하며 인증 프로세스를 시작합니다. 보통 대부분의 청중은 손을 듭니다.

그런 다음 그는 팀의 모든 사람이 최소 매일 공유 mainline (일반적으로 git 에서의 공유 마스터²)에 커밋하고 푸시하는 경우 손을 계속 들고 있도록 요청합니다.

손의 절반 이상이 내려갑니다.

그런 다음 각 커밋이 자동화된 빌드와 테스트를 동작시키는지 확인하도록 요청합니다. 나머지 손의 절반이 내려갑니다.

마지막으로 그는 빌드가 실패하면 일반적으로 10분 이내에 녹색 단계로 돌아오는지 묻습니다³.

그 마지막 질문으로 몇 명의 사람들만 남았습니다. 남아있는 사람들은 그의 인증 시험에 합격한 사람들입니다.

간단한 몇 가지 질문이지만 CI가 무엇인지에 대한 핵심을 간파합니다. 이는 어느 누구도 다른 사람의 코드 기반에서 크게 벗어나는 코드를 작업하지 않는다는 아이디어에서 기반합니다. CI는 팀이 현재 코드 상태를 실제로 알고 있음을 의미하며, 큰 병합(merge) 위험을 피하고 사람들은 필요한 만큼 코드를 수정하고 개선할 수 있습니다.

초반에 많은 사람들이 손을 든 이유는 CI라는 것이 "CI 서버" 에 그들의 feature 브랜치를 실행시키는 것을 의미한다는 일반적인 견해 때문입니다. 그러나 CI(원래 켄트 벡이 Extreme Programming의 일부로 설명하고 이름 붙인 것 처럼)는 도구와 아무런 관련이 없습니다. 처음에 이것은 인간의 작업 흐름이었고 Jim Shore는 그렇게 되어야 한다는 훌륭한 주장을 했습니다. 소스 코드 저장소에 대해 데몬 프로세스를 실행한다는 아이디어는 이후에 나온 것이며, 이는 유용하긴 하지만 사람들이 매일 커밋하는 공유된 mainline에 대해서 실행 될 때만 CI가 가능합니다. 모든 Feature Branch에서 이러한 프로세스를 실행하는 것은 CI theater⁴ 라는 그 이름을 비하하는 것으로, 전체 작업을 수행할 가치가 있는 이점을 제공하지 않는 워크 플로우를 만들게 됩니다.

Footnotes

1. 일반적으로 나는 소프트웨어 인증체계를 좋아하지 않습니다. 왜냐하면 그것들은 일반적으로 실패하기 때문입니다.
   https://martinfowler.com/bliki/CertificationCompetenceCorrelation.html ↩

2. (📝) develop 혹은 master 과 같은 성격의 브랜치를 말하는 것 같다. ↩

3. 이 단계에서 "녹색" 이라는 건 commit build를 통과한 것으로 간주되며, 일반적으로 컴파일 및 단위 테스트를 통과합니다. 일반적으로 전체 배포 파이프라인(Deployment Pipeline)이 실행되어 운영 환경에 릴리즈 될 것으로 예상되지만, 리포지토리는 개발자가 커밋 빌드가 녹색으로 설정된 후에 작업하는 것이 좋습니다. 10분 이내에 commit build를 작성해야 하므로, 수정 작업이 쉬운 경우 신속하게 수정하고 commit build 를 다시 실행합니다. 10분 이내에 녹색 commit build를 수정할 수 없으면 마지막 commit build로 되돌려야 합니다. ↩

4. CI theater의 문제는 의미론적 확산이 "CI"라는 용어를 쓸모 없게 만들었다고 주장하면서 Trunk-Based Development 이라는 이름을 사용하도록 유도합니다. 나는 그들의 관점을 이해하지만, 이러한 의미론적 확산에 굴복해선 안된다고 생각합니다. 대신 이러한 종류의 의미론적 공격("agile"과 "refactoring"과 같은)에 따라 다른 용어들과 함께 해야하는 것처럼, CI의 적절한 의미를 다시 설명하는 데 계속 노력할 필요가 있습니다. 결국 Kent 는 이 용어에 대한 정의가 상당히 명확해졌고, 다른 용어를 사용하는 것은 Extreme Programming 커뮤니티를 통해 기술을 대중화 하는 데 있어 그가 가지고 있던 중요한 역할을 감소시켰습니다. ↩