[지속적인 통합] 4장. 변경될 때마다 소프트웨어를 빌드하기

지속적인 통합 스터디 메인 페이지

목차

* 주의 : 책(폴M 듀발 저 - 지속적인 통합) 내용 중 기억하고 싶은 내용 및 제 생각을 적은 글 입니다. 책이 나온지 오래되어 설명에 나온 기술스택이 현재 사용되지 않는게 많아 기술스택보다는 이론이나 책의 조언들 위주로 작성할 것 같고, 기술스택은 제가 알고있는대로 수정해서 작성합니다. 따라서 책에서 말하고자 하는 바와 다를 수 있습니다.

* 별도로 표기되어 있지 않다면 이미지 출처는 '지속적인 통합 (폴M 듀발 저)' 책 입니다.

 

 

 

CHAPTER 4. 변경될 때마다 소프트웨어를 빌드하기

• 하루 종일 수작업만 해야 한다면, 프로세스와 제품을 감시하고 개선하는 등의 다른 일을 할 시간적 여유가 전혀 없을 것이다.

 

• 4장에서는 CI 서버를 사용하여 변경이 발생할 때마다 통합 빌드를 수행하는 방식의 장점을 논의한다.

 

 

조언들

• 빌드를 자동화하기
  • 자동화된 빌드 스크립트를 작성하면 소프트웨어 프로젝트에서 수행하는 손이 가고, 반복적이며, 오류가 나기 쉬운 프로세스를 상당히 줄일 수 있다.빌드는 버튼을 누르는 것만큼 쉬어야 한다!

 

• 명렁어 하나로 빌드를 수행하기
  • "필요한 거라면 뭐든지 VCS에 넣어뒀다 빼내서 쓰세요. 그래야 명령어 하나로 시스템 전체를 빌드할 수 있습니다." - 마틴 파울러
  • 바보라도 빌드할 수 있는 프로세스가 있어야 한다.

 

• IDE에서 빌드 스크립트를 분리해내기
  • 빌드 스크립트와 IDE를 결헙시키는 일은 피해야 한다.
  • IDE는 빌드 스크립트에 의존해도 되지만, 빌드 스크립트는 IDE에 의존해선 안 된다.
  • 즉, IDE가 빌드 스크립트를 작성하기 쉽게 도와주긴 하지만 IDE 없이도 빌드 스크립트가 정상적으로 동작되어야만 한다.
    • 개발자마다 IDE가 다를 수 있으므로
    • CI 서버는 사람의 간섭 없이 자동화된 빌드를 실행시켜야 하므로

 

• 소프트웨어 자산을 중앙 집중화하기
  • 모든 소프트웨어 자산을 중앙 집중화해야 한다.
    • "내 컴퓨터에선 잘 되는데요" 문제 방지
  • VCS에 모든 파일을 올려놓자!
    • 소스 파일이나 라이브러리 파일과 같은 컴포넌트
    • JAR, DLL 등과 같은 외부 컴포넌트
    • 설정 파일
    • 어플리케이션을 초기화하는 데이터 파일
    • 빌드 스크립트와 빌드 환경 설정
    • 일부 컴포넌트를 설치하는 스크립트
    • 등. 어떤 것이 '전체'를 이루는지 판단 내리는 것은 우리들의 몫임.

 

• 일관성 있는 디렉터리 구조를 만들기
  • 프로젝트 내내 사용할 무수히 많은 자산의 조합을 저장소에서 가져올 수 있으려면, 일관되고 논리적인 디렉터리 구조 필요.
  • 구현 (implementation)
  • 요구사항 (requirements)
  • 설계 (design)
  • 관리 (management)
  • 배포 (deployment)
  • 테스트 (testing)
  • 도구 (tools)

 

• 빌드를 빨리 실패하게 만들기
  • 좋은 빌드는 빨리 실패하는 법을 안다.
  • 개별 프로젝트에서 가장 자주 실패할 법한 것이 무엇이냐에 따라 빌드 스크립트에서 더 먼저 실행해야 한다.
  • 예시
    
    • 저장소에서 최신 변경 사항을 가져와서 컴파일
    • DB나 다른 의존성이 없는 금방 실행되는 테스트를 돌린다.
    • 다른 자동화된 프로세스를 돌린다.

 

• 전용 통합 빌드 머신을 사용하기
  • "내 컴퓨터에선 작동하는데요"(마법의 컴퓨터) 문제 방지
  • 일반적으로 느려터진 빌드를 기다리느라 시간을 낭비하는 것보단 통합 빌드 컴퓨터에 쓸 하드웨어 자원을 증가시키는데 돈을 쓰는 편이 가치 있다.
  • 빌드를 효율적으로 돌릴 수 있는 전용 빌드 머신 사용 -> 빌드 프로세스를 자주 실행시킬 수 있고, 환경적인 가정을 줄임으로써 빌드 환경이 정말로 반복 가능해진다.

 

• 지속적인 통합 서버를 사용하기
  • CI를 수행할 때는 CI 서버를 쓰는게 이치에 맞다.
  • 직접 CI 서버를 만들어서 써도 되지만 젠킨스 등 이미 나온 멋진 서버들이 있으니 그거 쓰란 말임.

 

• 빌드 시간을 짧게 만들기
  • 피드백을 기다리느라 개발 활동을 멈추면 프로젝트에 참여한 모든 사람이 개발 리듬이 느려진다.
  • 팀원들이 VCS에 코드를 자주 커밋하지 않는다면, 통합 빌드가 느린 탓일지도 모른다.
  • 켄트 백 : 빌드가 10분 내로 끝나도록 유지하는게 좋다.
  • 빌드 시간이 느리다면 다음과 같은 접근 방법을 써서 빌드 지속 시간을 진단하고 줄이자.
    • 빌드 메트릭(컴파일 시간, 소스 코드의 줄 수, 검사의 개수와 유형, 검사 시간, 배포 시간 등) 수집
    • 빌드 메트릭 분석
    • 개선 방안을 선택하고 수행
    • 다시 평가하고, 필요하다면 앞선 과정을 반복한다.

 

• 빌드를 여러 단계로 나누기
  • 가벼운 빌드를 먼저 돌리고 무거운 빌드를 나중에 돌리는 방법으로 빌드 지속 시간을 줄일 수 있다.

 

 

빌드 유형과 메커니즘

• 빌드 메커니즘
  • 주문형 : 누군가 직접 통합 빌드를 시작시키는 것
  • 일정 기반 : 예를들어 한 시간마다 빌드를 돌리는 것
  • 변경 사항을 폴링 : 일정 간격으로 CI서버에서 VCS의 변경사항을 확인해서 변경 사항을 감지하면 통합 빌드
  • 이벤트 주도 : 예를들어 PR이나 merge 시 빌드 시작

 

• 개인 빌드 - 주문형
  • VCS에 있는 최신 변경 사항을 자신이 변경한 코드와 통합해서 코드를 커밋하기 전에 개인 빌드를 돌려봐야 한다.
  • 절차
    • 저장소에서 고칠 코드를 체크아웃
    • 체크아웃한 코드를 변경
    • 저장소에서 가장 최근의 변경 사항을 가져옴
    • 단위 테스트를 포함하여 빌드를 돌린다
    • 변경한 코드를 저장소에 커밋

 

• 통합 빌드 - 주문형, 변경 사항 폴링, 일정 기반, 이벤트 주도
  • 팀이 저장소에 커밋해 넣은 변경 사항과 주흐름(Head나 Trunk라고도 알려진)을 통합
  • 별도의 전용 컴퓨터에서 돌려야 한다.

 

• 릴리즈 빌드 - 주문형, 일정 기반
  • 사용자에게 출시할 제품을 준비하는 과정

 

 

이런 게 과연 효과가 있을까요?

"내 프로젝트엔 70억 줄짜리 코드가 있습니다. 이런게 과연 효과가 있을까요?"

• 프로젝트가 클수록, 변경의 불변성을 위해서 CI가 더 필요합니다.
• CI가 없어도 된다는건 "난 차라리 코드 베이스에 문제가 있더라도 모르고 지낼래. 차라리 내가 무슨 일을 하고 있었는지 기억나지 않을 때까지 기다릴래" 라고 말하는 것과 동일하다.

 

레거시 애플리케이션이 있는데, 이런 게 과연 효과가 있을까요??

• 자동화된 테스트가 없더라도 변경 요청이 있을 때마다 자동화된 테스트를 추가하는 것부터 시작해보자.
• 물론 결함이 하나 있다면, 개발할때 만들지 않은 테스트부터 작성해야 한다는 점임.

 

"통합 빌드가 너무 오래 걸려요!"

• 빌드를 빠르게 만들자!

 

"빌드 실패가 자주 납니다. 뭔가 잘못하고 있는 걸까요?"

• 작동하지도 않는 코드를 커밋하고 있는 거임.
• 개발자 각자가 통합 빌드를 돌리는 것과 똑같은 프로세스들을 돌리는 '샌드박스'를 가져야 한다.

 

"빌드 머신을 별도로 둘 여력이 없습니다."

• 하드웨어는 통합 문제가 발생했을 때 잃게 될 시간과 비교하면 쌉니다.

 

"우리가 만드는 소프트웨어는 아주 복잡하다구요. 사람이 직접 해야 합니다."

• CI를 만들어야 하는 완벽한 이유가 됩니다.
• 한 번에 모든걸 밀어 넣기보단 조금씩 빌드를 발전시켜나가 보세요.
  
  • 대부분의 CI 시스템들은 이런 방식으로 만들어졌음!

 

 

질문

• 빌드를 자동화했습니까? IDE가 없어도 빌드를 돌릴 수 있나요?
• 모든 소프트웨어 자산을 버전 관리 저장소에 모아놨습니까? 버전 관리 저장소에서 필요한 파일을 모두 가져와서 빌드를 온전히 수행할 수 있나요?
• 가장 실패할 법한 빌드 태스크를 빌드 스크립트의 앞부분에 놓아서 빌드 실패 통지를 신속히 받을 수 있게 해놓았습니까?
• 소프트웨어 빌드 프로세스를 위한 '통합 버튼'이 있습니까? DB 통합을 자동화해 놨습니까? 테스트는요? 검사는요? 배포는 어떤가요? 빌드 프로세스로부터 피드백을 받아서 사용하고 있나요?
• 별도의 컴퓨터에서 통합 빌드 프로세스를 수행합니까?
• 통합 빌드에 걸리는 시간이 얼마나 됩니까? 빌드 시간을 짧게 줄여서 피드백을 개선할 방법을 찾고 있나요?
• CI 서버를 사용해서 소프트웨어를 통합하고 있습니까? 혹은 사람이 직접 빌드를 통합하기 위한 체계 잡힌 프로세스를 갖추고 있나요?
• 통합 빌드를 얼마나 자주 수행합니까? 매주마다? 저녁마다? 매시간마다? 아니면 변경될 때(지속적으로)마다 합니까?