[지속적인 통합] 3장. 지속적인 통합을 이용해 위험 줄이기

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

목차

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

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

 

 

CHAPTER 3. 지속적인 통합을 이용해 위험 줄이기

• "품질이란 누가 보지 않을 때에도 제대로 돌아가는 걸 뜻한다" - 헨리 포드

 

• 3장에선 CI의 여러 측면을 활용하여 어떤 소프트웨어 위험 요소를 줄일 수 있는지에 대해 알아봄
  • 소프트웨어 위험 요소에 대한 소개와 설명
  • 시나리오
  • 위험 요소를 완화시킬 해결책

 

 

 

위험 요소 : 배포 가능한 소프트웨어의 부재

• 한두 달에 한 번씩 별도의 컴퓨터에서 소프트웨어를 빌드 -> 마감일에 제대로 동작하지 않는 인터페이스가 있고, 설정 파일을 빼먹었고, 중복된 컴포넌트가 여러 개이고, 병합하기 힘들다는걸 깨달음
• 별도의 컴퓨터에서 빌드하지 않음 -> 깨끗한 환경에서 빌드한게 아니므로 제대로 빌드하고 있는지 자신이 없음
• 이로 인한 문제점
  • 소프트웨어를 빌드할 수 있을지에 대해 자신감이 없음
  • 소프트웨어를 내부(테스트 팀 등)나 외부(고객 등)에 전달하기 전까지의 통합 기간이 길어지고, 그 사이에 다른 일을 할 수 없음
  • 테스트 가능한 빌드 결과물을 생산하고 재생산할 능력이 없음

 

시나리오 : "내 컴퓨터에선 되는데요"

• 문제 : 뭔가 문제가 생겼는데, 올린 사람 컴퓨터에서는 잘 돌아감! 알고보니 새로 추가한 파일을 VCS에 커밋하지 않은 것.
• 해결책 : IDE와 빌드 프로세스가 서로 강하게 얽혀있으면 안 된다. 소프트웨어 통합 전용 컴퓨터를 따로 사용할 것. 소프트웨어를 빌드할 때 필요한 모든 게 VCS에 있어야 한다.

 

시나리오: 데이터베이스와 동기화하기

• 문제 : 데이터베이스 팀과 개발 팀이 분리되어 있다면 서로 협력하는 데 힘쓰기보단 저마다 자기 팀이 맡은 일에 초점을 맞춘다. 예를들어 DB 관리자가 DB 스크립트 상당수를 VCS에 커밋하지 않을 수도 있다.
  • DB나 소스 코드를 변경하거나 리팩토링하기 무섭다.
  • 여러 가지 데이터 집합을 사용해 DB를 생성하기 힘들다.
  • 개발 및 테스트 환경을 유지보수하기가 힘들다.
• 해결책 : 모든 DB 산출물(스키마와 데이터를 다시 만드는데 필요한 모든 것. DB 생성 스크립트, 데이터 조작 스크립트, 저장 프로시저, 트리거와 그 밖의 DB 자산들)을 VCS에 넣어야 한다.(flyway도 좋을듯) 그리고 DB도 테스트해야 한다.

 

 

위험 요소 : 뒤늦은 결함 발견

• 몇몇 프로젝트에 대해 테스트를 직접 수행할 경우 최근에 소프트웨어를 변경한 코드가 다른 문제를 일으키진 않는지 알 도리가 없다. 테스트를 사람이 직접 수행하므로 개발자들이 테스트를 돌릴 거라는 보장이 없다.

 

시나리오: 회귀 테스트

• 문제 : 최신 코드만 테스트를 하는 경우, 결함을 고치면서 다른 연관된 결함이 드러나는 악순환이 생길 수 있다. 예를 들어 두 달 전에 발견하고 해결했던 코드가 최신 코드에 다시 나타날 수 있다.
• 해결책 : 모든 코드에 대해 테스트를 작성 -> 빌드 스크립트로 테스트를 돌릴 것 -> CI 시스템의 일부로써 테스트를 지속적으로 돌릴 것. (즉, 회귀 테스트를 자동화할 것)

 

시나리오: 테스트 적용범위(Test Coverage)

• 문제 : 짜둔 테스트 코드가 모두 통과하더라도 테스트 적용범위가 낮다면 당연히 모두 테스트해본게 아님
• 해결책 : 코드 적용범위 도구(소나큐브 등)를 돌려서 패키지나 클래스별로 적용범위를 백분율로 확인할 것.

 

 

위험 요소 : 프로젝트 가시성의 부재

• 사람이 직접 의사소통 매커니즘을 수행하게되면 프로젝트의 정보를 적절한 시기에 올바른 사람에 전달하기 어렵다. 예를들어 연락을 취하는 사람이 잊어먹을 수도 있다.
• 정보가 올바른 사람에게 제때 전달되어야 한다.

 

시나리오: "제가 남긴 메모 보셨나요?"

• 문제 : 테스트를 하려는데 최신 빌드가 QA 팀에서 배포되길 기다리고 있는 A 개발자. 사실 이틀전에 테스트 서버에 배포됬는데, A가 며칠동안 회사에 없었어서 몰랐음.
• 해결책 : CI 서버에서 빌드가 실패하면 관련자에게 이메일 등을 보내는 자동화 매커니즘 도입 필요하다.

 

시나리오: 소프트웨어를 시각화할 역량의 부재

• 문제 : 프로젝트에 신규로 참여하게 된 개발자 A가 설계를 검토해보고 싶어서 UML 다이어그램을 요청했는데, 그런건 없고 코드 읽어보라고 함. A는 큰 그림을 보고 아키텍처 전체를 파악하길 원했음!
• 해결책 : CI 시스템을 사용해 설계 다이어그램 생성(책에선 Doxygen으로 예를 듬).

 

 

위험 요소 : 저품질의 소프트웨어

• 코드 냄새
  • 냄새 : 무언가 잘못됐다는 징후
  • 눈에 보이는 결함 뿐 아니라 잠재적인 결함도 있다.
• 코드 냄새가 결함이 되기 전에 찾아내면 엄청난 시간과 돈을 절약할 수 있고, 그에 따라 품질 좋은 소프트웨어가 만들어진다.

 

시나리오: 코딩 표준 준수

• 문제 : 개발자 A는 현재 팀에 코딩 표준 문서가 있음에도 지난 번 직장에서 했던 대로 코드를 작성하고 있었음. 팀은 코드를 검토하고 업데이트하느라 시간을 더 잡아먹게 됨.
• 해결책 : CI 빌드 스크립트를 돌릴 때 자동화된 검사 도구가 코딩 표준을 강요하도록 만들 수 있음(소나큐브 등에서 지원해줌). 최종적으로 코딩 표준을 위반할 시 빌드가 통과하지 못하게 만들 수 있음.

 

시나리오: 설계 지침 준수

• 문제 : 의도한 설계를 따르지 않는 소스 코드는 유지 보수하기 더 어렵다. 예를들어 설계 지침을 위반하고 데이터 계층에서 곧바로 컴포넌트를 호출하게 할 경우 등. 이 때 UML 다이어그램 같은것을 통해 설계 지침을 전파시키려면 UML 다이어그램이 변경될 시 따라가기 힘들어진다.
• 해결책 : 자동화된 검사 도구를 넣어서 프로젝트 아키텍처 표준을 준수하는지 평가할 것. (Archunit 등을 사용하면 될 듯)

 

시나리오: 중복 코드

• 문제 : 중복 코드는 코드를 유지보수하기 더 어렵게 만들고 비용을 증가시킨다. 복붙한 코드는 모든 프로젝트에 위험이 된다.
  • A : User 객체 콜렉션을 어떻게 순회하면 되는지 아세요?
  • B : 아 제가 지난 주에 짜둔거 있어요. User 패키지 찾아보세요
  • A : ㄳㄳ 복붙할께요.
• 해결책 : 정적 분석 도구와 같은 자동화된 검사 도구를 추가해 중복된 소스 코드를 보고하게 할 것(이것도 소나큐브에서 가능).

 

 

질문

• 프로젝트를 하면서 결함을 주로 발견하는 시기는 언제입니까? 생명 주기 초기입니까? 아니면 나중입니까?
• 품질을 어떤 식으로 파악합니까? 품질을 측정할 수 있나요?
• 어떤 과정을 사람이 직접 하나요? 자동화할 수 있거나 또는 자동화해야 하는 프로세스는 어느 것인지 파악해본 적이 있습니까?
• 데이터베이스와 데이터를 다시 빌드할 때 필요한 스크립트를 모두 버전 관리 저장소에 넣어놨나요? 빌드하는 와중에 데이터베이스와 테스트 데이터를 다시 빌드할 수 있습니까?
• 소프트웨어가 변경될 때마다 회귀 테스트를 수행할 수 있습니까? 기능, 통합, 부하 및 성능 테스트를 비롯한 다양한 유형의 회귀 테스트를 돌릴 수 있나요?
• 어떤 소스 코드에 그에 상응하는 테스트가 없는지 파악할 역량이 있습니까? 테스트 적용범위 도구를 사용합니까?
• 소프트웨어 중 몇 퍼센트가 중복 코드인지 압니까? 그 양을 줄여보려 노력합니까?
• 어느 시점에서라도 그 때의 소스 코드가 소프트웨어 아키텍처에 부합하는지 여부를 검증할 수 있습니까?
• 빌드 산출물이나 배포 산출물이 테스트할 준비가 됐다는 걸 어떻게 알립니까? 의사소통 메커니즘 중 어느 부분을 사람이 직접 맡고 있는지, 그리고 어느 부분을 자동화해야 하는지 알고 있습니까?
• 소프트웨어의 지금 구조를 다이어그램으로 보일 수 있습니까? 프로젝트에 들어온 신참 개발자에게 소프트웨어의 아키텍처를 어떻게 전달합니까?