[지속적인 통합] 8장. 지속적인 배포

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

목차

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

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

 

 

CHAPTER 8. 지속적인 배포

• 소프트웨어를 작성하라고 급여를 준다면, 급여를 지급하는 조직은 예측가능하고 현실적인 시일이 지난 후엔 여러분이 최종 사용자에게 작동하는 소프트웨어를 제공하리라 기대한다.

 

• 배포 프로세스를 개발 프로세스만큼이나 제대로 수립해야한다.
  • 최소한의 노력으로 작동하는 소프트웨어를 언제든지, 그리고 어느 곳에서든지 배포할 수 있도록 해줄 잘 다듬은 실천 방법과 절차가 필요하다.

 

 

작동하는 소프트웨어를 언제, 어느 곳에서든 릴리즈하기

• 이 책에서 그동안 다루었던 CI 내용들의 한 가지 중요한 이점 = 언제, 어디서라도 제대로 작동하는 소프트웨어를 출시할 수 있다.

 

• 작동하는 소프트웨어를 배포하는 6단계 과정
  • 1. 저장소 안의 자산들에 꼬리표를 붙인다
  • 2. 가정이나 추측에서 자유로운 깨끗한 환경을 만든다
  • 3. 저장소에서 곧바로 빌드를 만든 후 꼬리표를 붙이고, 그렇게 만든 빌드를 대상 컴퓨터에 설치한다.
  • 4. 실제 환경을 복사한 곳에서 모든 단계의 테스트를 성공리에 돌려본다.
  • 5. 빌드 피드백 보고서를 만든다.
  • 6. 필요하다면 버전 관리 저장소에 기록해놓은 꼬리표를 이용해 릴리즈를 롤백한다.

 

 

깨끗한 환경 만들기

• 소프트웨어를 빌드할 때는 소프트웨어를 실패하게 만들 수 있는 파일이나 설정 환경을 남기면 안 된다.

 

 

각 빌드에 꼬리표 붙이기

• 빌드하여 나온 유일무이한 비ㅏ이너리 출력물 (릴리즈) 에 태그를 붙이는 것. 예를들어 git은 git tag로 붙일 수 있음.

 

 

테스트를 모두 돌리기

• 어떤 개발 단계에서는 특정 테스트만 돌려도 될지 모르지만, 배포 빌드를 패키징하기 전에는 모든 테스트를 반드시 돌려보고 통과시켜야 한다.'

 

• 가장 견고한 자동화된 테스트일지라도, 소프트웨어를 출시하기 전에 반드시 사용자의 활동을 모방해봐야 한다.

 

 

빌드 피드백 보고서 만들기

• 자동화된 빌드 피드백은 사람들이 파일이 뭐가 달라졌는지, 어떤 결함을 해결했는지, 그리고 어떤 기능을 구현했는지 등을 좀더 잘 이해하게 만들어준다.

 

 

릴리즈를 롤백할 수 있는 능력 확보하기

• 궁극적으로 배포를 원래대로 되돌리는 능력을 확보해야지만 개발을 효율적으로 할 수 있다.
• 꼬리표를 이용하면 이걸 쉽게 할 수 있다.

 

 

질문

• 릴리즈를 롤백할 수 있는 능력이 있습니까?
• 버전 관리 시스템에 들어있는 빌드에 꼬리표를 붙이고 있습니까?
• 릴리즈 후보를 사람이 직접 테스트한 후에 돌릴 자동화된 테스트를 제대로 갖췄습니까?
• 여러분의 팀은 릴리즈 수정을 어떻게 다룹니까?
• 버전 관리 꼬리표와 빌드 버전이 연관되어 있습니까?
• 빌드를 할 때 피드백 보고서를 생산합니까?
• 명령줄에서 명령어 하나만 치면 소프트웨어를 배포할 수 있습니까?
• 버전 관리 저장소에서 배포할 걸 만들어낼 수 있습니까?
• 다양한 환경을 위해 배포 설정을 바꿀 수 있습니까? 사용자 환경과 똑같은 '깨끗한' 환경에서 소프트웨어를 적절히 설치하고 돌리고 있나요?
• 버그 추적 시스템이 있습니까? 그 버그 추적 시스템은 보고서를 만들어낼 수 있습니까?