신뢰할 수 있는 소프트웨어 출시 [1/15]

1장. 소프트웨어 인도의 문제점

• 배포 파이프 라인

  • 커밋 (컴파일, 단위테스트, 분석, 설치 프로그램 빌드)
  • 인수테스트 (기능테스트)
  • 인수테스트 (용량)
  • 수동 테스트 (시연, 탐색)
  • 출시

• 배포 파이프라인의 근간은 지속적 통합 이며, 본질적으로 배포 파이프 라인은 지속적 통합의 원칙을 논리적으로 발번 시킨 것이다.

• 대표적인 배포 안티패턴

  • 잘못된 방법 과 꼭 지켜야할 절차를 자세하게 설명한 문서가 있다.
  • 수동 테스트에 의존한다.
  • 애플리케이션 서버의 커넥션 풀 설정이 다르거나, 파일 시스템의 레이아웃이 다르게 설정되는 등 동일 클러스터 안에서도 환경 설정이 다르다.

• 대안

  • 배포 작업은 궁극적으로 완전 자동화가 이뤄져야 한다.
  • 배포를 자동화 하면 모든것이 스크립트에 명시 되므로 협업이 증대 된다.
  • 유사 실환경 배포는 개발 완료 배포 후에만 수행
  • 테스트와 배포 , 출시 활동을 개발 프로세스에 통합하는 것이다.
  • 테스트와 스테이징, 실환경, 특히 시스템의 서드 파티 요소 중 환경 설정 정보는 버전 관리 시스템으로부터 자동화 프로세스를 통해 적용한다.
  • 제품에 무엇이 포함되는지 정확하게 알아야 한다. 즉 제품에 대한 모든 변경이 기록되고 검사 돼야 함을 의미한다.

• 목적을 이루기 위한 방법

  • “완벽함은 양호함의 적이다.” 처럼 품질이 곧 완벽함을 의미하는건 아니지만 그래도 항상 적절한 품질의 소프트웨어가 사용자에게 인도 될 수 있게 해야 한다.

• 변경되는 모든 내용에 대해 피드백 프로세스가 적용돼야 한다.

  • 동작하는 소프트웨어 애플리케이션은 실행코드, 환경설정, 운영환경, 데이터, 이렇게 4개의 구성요소를 갇는다.
  • 소프트웨어는 반드시 단위 테스트를 통과해야 한다.
  • 소프트웨어는 테스트 커버리지나 그외의 기술적 지표 같은 품질 기준을 만족시켜야 한다.
  • 코드 커버리지 75% 이상으로 테스트가 통과하면 대체적으로 애플리케이션의 동작에 높은 신뢰도를 가질 수 있다.
  • 개발자는 버전 관리 시슽메에 자주 커밋해야 하고 규모가 크거나 분산된 팀을 관리하기 위해서는 컴포넌트별로 코드를 나눠야 한다.
  • 출시는 버튼 하나만 누르면 수생된다.

• 연습을 통해 완벽해진다.

  • 프로젝트의 경우 라도 지속적 통합이나 반복 점진적 개발 기술을 사용하는 팀이라면 애플리케이션을 자주 배포 할 수 있는 환경은 반드시 필요한다.

• 출시 후보

  • 지금까지 경험에 의하면 개발 프로세스가 완료 될때까지 테스트를 미루는 것이 애플리케이션 품질 저하의 원흉이다. 오류는 발생하는 그 순간이 발견하고 수정하기에 최적기다. 뒤늦게 발결할 수록 수정에 더 많은 비용이 든다.
  • 오류는 가능한 한 빠른 시점에 발견해 수정해야 하며, 반드시 코드 체크인 전에 완료 하는것이 바람직하다.

• 소프트웨어 인도의 원칙

  • 소프트웨어 출시는 쉬워야 하고 출시 이전에 모든 출시 과정이 수백번 테스트 될 수 있을 만큼 간단해야 한다.
  • 솔직히 많은 작업과 노력 없이는 빌드나 배포를 자동화하지 못한다.
  • 힘든 작업 일 수록 더 자주 그리고 많이 수행하라
    • 프로세스 막판까지 테스트를 미루지 말고 프로젝트가 시작될 때무터 지속적으로 테스트를 수행해야 한다.
  • 품실은 초기부터 관리한다.lean (린)
  • 고객에게 최고의 가치를 가장 빨리

• 출시해야 완료 한 것이다.

  • ‘80%’완료란 있을 수 없다. 완료이거나 아니거나 둘뿐이다.

• 인도 프로세스는 공동의 책임이다.

  • 궁극저으로 팀 목표의 성공이나 실패 여부가 개인이 아닌 팀의 책임이라는 의미다.

• 지속적 개선

  • 모든 팀은 정기적으로 모여 인도 프로세스에 대해 회고를 수행해야 한다. 팀은 잘된 일과 잘못된 일을 파악해 개선을 위한 아이디어 회의를 해야 한다.

• 애플리케이션 배포를 위해 주말을 서버실에서 보내기에는 인생이 너무 짧다.