달리기 전에 걷기: CD에서 CI 이해하기

주변에 떠도는 소문과 함께 연속 배달 (CD) 요즘에는 그것에 대해 말하는 것조차 구식인 것처럼 보일 수 있고, 더군다나 그것에 대해 글을 쓰는 것조차 구식인 것처럼 보일 수 있습니다. 지속적인 통합 (CI). 하지만 CD를 구현하려는 조직이나 구현 중(그리고 난관에 부딪히는) 조직들과 많은 대화를 나누면서, 조직의 CD 도입 의지를 뒷받침하는 기반적인 측면들 사이에는 커다란 간극이 존재한다는 것을 분명히 알게 되었습니다. CI는 핵심적인 지원 요소이지만, 그 원칙들은 아직 충분히 명확하게 이해되거나 구현되지 않았기 때문에 다시 살펴볼 가치가 있습니다.

마디 없는…

통합 빠르고 자동화된 피드백을 이끌어내는 프로세스입니다. 단정 코드가 변경될 때마다 애플리케이션의 변경 사항을 확인합니다.

배송 빠르고 자동화된 피드백을 제공하여 이전 개념을 기반으로 구축합니다. 단정 생산 준비 신청서에 변경 사항이 있을 때마다 코드, 인프라 또는 구성.

CD의 전제는 소프트웨어는 항상 배포 가능하다는 것입니다. 음, 익숙한 내용입니다. 최근 애자일 선언문의 원칙을 살펴보신 분 계신가요? 첫 번째 원칙은 다음과 같습니다.

“우리의 최우선 순위는 조기에 고객을 만족시키는 것입니다. 지속적인 배달 – 귀중한 소프트웨어.”

CD는 새로운 개념이라기보다는 오랜 약속을 실현하는 것에 더 가깝습니다. 그리고 이 이상을 실현하기 위한 핵심 전제 조건은 다음과 같습니다.

• 지속적인 통합
• 포괄적인 구성 관리
• 다단계 자동화 테스트

이 게시물의 나머지 부분에서는 CD의 CI 측면을 좀 더 자세히 살펴보겠습니다.

지속적인 통합

CI는 소프트웨어 빌드를 실행하는 프로세스입니다.Deploy- 최소한의 수동 개입으로 빈번하게 테스트(BDT) 주기를 거치며, 팀원 간의 지속적인 소통과 피드백을 기본 원칙으로 합니다. 소프트웨어 개발 분야의 저명한 저자이자 강연자인 마틴 파울러는 이를 다음과 같이 설명합니다.

"...팀원들이 각자의 업무를 자주 통합하는 소프트웨어 개발 관행으로, 일반적으로 각 구성원이 최소 하루에 한 번은 통합 작업을 수행하여 하루에 여러 건의 통합 작업을 하게 됩니다. 각 통합 작업은 자동화된 빌드(테스트 포함)를 통해 검증되어 통합 오류를 최대한 빨리 감지합니다. 많은 팀에서 이러한 접근 방식을 통해 통합 문제가 크게 줄어들고 팀이 응집력 있는 소프트웨어를 더욱 빠르게 개발할 수 있다는 것을 알게 되었습니다."

아프다면, 고통을 앞으로 가져오세요

CI는 소프트웨어 통합 오류를 신속하게 감지하는 프레임워크를 제공하여 팀이 통합 소프트웨어를 더욱 신속하게 개발할 수 있도록 지원하는 동시에 많은 소프트웨어 팀을 괴롭히는 "빅뱅" 통합과 그에 따른 코드 병합의 고통을 완화합니다. CI는 개발자들이 일상적인 개발 활동에 빈번한 작업 통합을 포함하도록 장려하여 통합의 불확실성을 없애는 것을 목표로 합니다. CI는 코드 병합 및 충돌 해결이라는 까다로운 작업을 완전히 없애는 것이 아니라, 매일 작고 점진적인 병합을 요구함으로써 빈번하지 않은 병합으로 인한 어려움을 크게 줄여줍니다. 나중에 겪는 고통 대신 오늘의 고통을 얻는 것입니다.

개발자의 일상 업무는 어떻게 바뀌나요?

CI는 사고방식이며, 프로세스를 수동으로 실행할 수도 있지만 대부분의 팀은 도구를 사용하여 규칙을 강화합니다. 아래 그림은 CI 서버라는 도구를 사용하여 CI를 구현하는 일반적인 통합 주기를 보여줍니다.

• 개발자가 소스 제어 저장소에서 최신 코드베이스를 가져오는 것으로 하루가 시작됩니다.
• 그 다음에는 전형적인 개발 활동이 있습니다(가급적 자동화된 단위 테스트에 의해 안내됨)
• 개발자는 코드를 저장소에 커밋할 준비가 되었으며 팀에 의도를 전달해야 할 수도 있습니다.
• 다른 사람이 코드 스트림을 업데이트했을 수 있으므로 저장소의 코드로 로컬 작업 사본을 업데이트합니다.
• 코드를 병합하고 로컬에서 모든 충돌을 해결합니다.
• 로컬에서 테스트를 빌드하고 통과하도록 보장합니다.
• 저장소에 코드를 커밋합니다.
• CI 서버는 코드 저장소의 변경 사항을 "수신"합니다. 변경 사항이 발생하면 빌드 및 테스트 주기가 자동으로 시작되고, 그 결과는 자동으로 팀원들에게 전달됩니다. 컴파일 또는 테스트 실패로 인해 빌드가 중단되거나 "적색"으로 표시되는 것은 통합 실패를 나타내므로 즉시 조치해야 합니다. CI 환경을 "녹색"으로 만드는 것은 개발자/팀의 최우선 과제가 되어야 합니다.

우리는 어디에서 시작합니까?

통합 주기에 대한 설명에서 알 수 있듯이 CI를 도입하려면 CI를 가능하고 효과적으로 만드는 데 필요한 특정 관행이 필요합니다.

단일 소스 저장소

배포 가능한 소프트웨어 아티팩트를 빌드하는 데 필요한 모든 소스 코드 파일, 데이터베이스 스크립트, 종속 라이브러리, 속성 파일은 일종의 소스 제어 시스템에서 버전 관리되어야 합니다. CI 서버가 코드 저장소의 변경 사항을 모니터링하여 BDT 사이클을 시작하기 때문입니다. 이러한 제약이 아무리 기초적인 것처럼 보일지라도, 중앙 집중식 소스 제어 및 버전 관리가 필수적인 성숙 단계에 아직 도달하지 못한 조직도 있습니다.

빌드 자동화

중앙 집중식 소스 제어가 구축되어 있음에도 불구하고, 많은 조직은 여전히 ​​배포 가능한 소프트웨어 아티팩트를 만드는 데 수동 프로세스에 의존하고 있으며, 이는 조직 사일로와 팀원 간의 협력을 필요로 합니다. CI의 전제는 사람의 개입 없이 빌드를 시작하는 것이므로, BDT(Build-To-Desk) 주기를 자동화하기 위해 단일 클릭 빌드 기능을 구축해야 합니다. 빌드 자동화의 기본 원칙은 실행 중인 시스템을 처음부터 구축하는 것입니다.

테스트 자동화

전제 조건은 아니지만, 테스트 자동화 소프트웨어 구성 요소가 통합되었을 뿐만 아니라 제대로 작동하고 있다는 신뢰할 수 있는 피드백을 팀에 제공하는 데 중요한 역할을 합니다. 테스트 자동화가 CI로의 전환을 방해해서는 안 되지만, CI의 이점을 제대로 활용하기 위해 자동화된 테스트를 도입하는 데 너무 오래 기다리지 않는 것이 좋습니다.

"모범 사례"에는 어떤 것이 있나요?

•  공통 코드 스트림에 대한 빈번한 커밋
• "손상된" 빌드에 대한 커밋을 허용하지 않음
• CI에서 "손상된" 빌드는 즉시 처리되어야 하며 이를 해결하는 것이 최우선 순위여야 합니다.
• 장기 실행 빌드를 처리하세요. 10~15분이 이상적이며, 의미 있는 빈번한 통합을 위한 최대 허용 시간은 20~30분입니다. 주기가 짧을수록 좋습니다. 가장 큰 원인은 단위 테스트로 위장한 통합 테스트일 수 있습니다. 필요한 경우 빌드를 단계적으로 실행하세요.
• 데이터베이스 재구축(0부터 구축)
• 프로덕션과 같은 플랫폼에서 빌드/배포/테스트
• QA에 타겟 빌드를 상위 레벨 환경에 배포할 수 있는 기능 제공

어떤 오해가 있나요?

CI는 Nightly Build와 동일합니다.

사실이 아닙니다. 야간 빌드는 QA 기능 테스트, 제품 검토 등 외부 사용을 위한 소프트웨어 아티팩트를 생성합니다. XP는 야간 빌드라는 개념을 극단으로 끌어올려 개발자가 시스템과 소통하여 적어도 당분간은 자신의 역할을 제대로 수행했는지 확인할 수 있도록 하루 중 코드 동기화 체크포인트를 자주 수행하도록 제안했습니다. 야간 빌드의 가치가 없다는 것은 아니며, CI를 사용하여 단계적으로 빌드를 생성할 수도 있습니다.

우리는 Agile하지 않으므로 CI를 수행하지 않습니다.

"지속적 통합(CI)"이라는 용어는 익스트림 프로그래밍(XP)에서 처음 도입되었지만, 더 빈번한 통합이라는 기본 개념은 XP보다 앞서 있습니다. 실제로 CI는 XP에서 제시하는 방법 중 가장 논란의 여지가 적은 방법 중 하나이며, 그 지침 원칙은 조직이 애자일을 도입했는지 여부와 관계없이 적용됩니다.

빈번한 Deployment 파괴적

CI를 도입했다고 해서 요청 여부와 관계없이 모든 "그린" 빌드가 상위 환경에 자동으로 배포되는 것은 아닙니다. 좋은 CI 구현은 QA 또는 기타 팀원이 필요에 따라 CI 서버에서 대상 빌드를 다른 환경에 배포할 수 있는 기능을 제공해야 합니다.

. 사람들을 위한 자동화 이 시리즈에서 폴 듀발은 몇 가지 일반적인 CI 안티 패턴과 오해를 나열하고 이를 피하는 방법을 설명합니다.

맺음말

CI의 가장 큰 이점은 위험 감소입니다. 지연되고 빈번하지 않은 통합으로 인한 문제는 프로젝트 후반부, 즉 위험 부담이 크고 납품 압박이 가장 클 때 종종 발생합니다. 더 나아가, 빌드 자동화, 테스트 자동화, 그리고 최근에는 지속적 배포(CDR)를 비롯한 여러 단계에서 자동화를 위한 토대를 마련해 주며, 이러한 모든 자동화는 더 높은 품질의 소프트웨어, 더 빠르게.

참고자료

• http://martinfowler.com/articles/continuousIntegration.html
• http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html
• 지속적인 통합: 소프트웨어 품질 개선 및 위험 감소 – Duvall, P & Matyas, S & Glover, A
• 지속적인 배포: 안정적인 소프트웨어 Release빌드, 테스트를 통해 Deploy자동화 – Humble, J & Farlay, D