데브옵스 스터디 9~10 장

9장

배포 파이프라인의 기반 생성

• 신속하고 안정적인 운영을 위해 유사 프로덕션 환경을 사용해야 한다.
• 위 방법은 자동화되어야 하며, 버전 관리 기반으로 전체 환경을 재구성할 수 있어야 한다.
  => 유사 프로덕션 환경을 통해 사전에 테스트하여 운영 환경 배포 이슈를 최소화한다.

엔터프라이즈 데이터 웨어하우스 이야기 (2009)

• 운영/개발 환경 간 버전 관리가 일치하지 않아 많은 결함이 발생했다.
• 환경 생성 프로세스를 자동화하여 프로젝트 진행에 필요한 환경을 조성하는데 1일로 단축되었다.

개발, 테스트, 프로덕션 환경을 온디맨드 방식으로 생성할 수 있게 하라

• 테스트 환경이 잘못되거나 운영과 다르다면 사전 테스트를 했음에도 실제 기능에 문제가 발생할 가능성이 있다.
• 이를 해결하기 위해 유사 프로덕션 환경을 생성해야 한다. => dev, alpha, ...
• 환경 명세는 문서화보단 공통 빌드 메커니즘을 만들어 누구나 쉽게 구축할 수 있도록 한다.
• 문서나 지식보단 자동화된 환경 구축 프로세스로 체계화되어야 한다.
  • VMware 이미지, docker 컨테이너, cloud 환경 등

전체 시스템을 위한 단일 저장소를 생성하라

• 애플리케이션 코드뿐 아니라 환경 구성, 스크립트, 배포 도구 모두를 단일 저장소에서 관리해야 한다.
• 가치 흐름을 제공하는 모든 관계자가 동일한 버전 관리 시스템을 통해 상황을 공유하고 빠르게 대응할 수 있기 위함이다.
  • 코드, 의존성 라이브러리, DDL Script, 환경 구성 파일, 배포 파이프라인, etc...

복구보다 재구축하기 쉬운 인프라스트럭처를 만들어라

• 많은 서버를 관리하기 위해선 환경 복구보단 재구축이 용이하다.
• 재구축에 용이한 환경 시스템을 보유하고 있다면 서버 수평 확장에도 용이하다.
• 배포 시, 신규 가상 머신 또는 컨테이너를 사용하여 새로운 프로덕션 환경을 구성하고 배포할 수 있다.
  => 불변 인프라스트럭쳐(k8s 파드 배포, docker container 배포 등)
  => 기존 환경을 유지한 채 신규 배포 후 교체하기 때문에 신규 기능 이슈로 인한 운영 환경 문제를 예방할 수 있다.
• 위 과정을 통해 환경을 최신 상태로 유지할 수 있다.(버전 관리 상태 = 실제 배포 상태)

유사 프로덕션 환경에서의 실행도 포함하게 개발 항목의 '완료' 정의를 수정하라

• 개발 완료는 유사 프로덕션 환경에서 온전히 동작하는 것을 포함해야 한다.
• 이를 위해 유사 프로덕션 환경은 수시로 최신화되어야 하며, 이는 자동화되어야 한다.
  => 예) 젠킨스 CI, ArgoCD CD

결론

프로젝트 초기 단계에 유사 프로덕션 환경을 빠르게 얻어야 한다.
유사 프로덕션 환경 기준 기능 적용 및 테스트가 완료되는 것을 "완료" 라고 인지해야 한다.
프로덕션과 관계된 모든 코드, 인프라 설정 등을 동일한 버전 관리에 포함해야 한다.

---

10장

빠르고 신뢰할 수 있는 자동화 테스팅을 활성화하라

• 자동화 테스트를 통해 테스트 비용과 시간을 절감해야 한다.
• 서비스에 대해 관측성과 별개로 배포 전 완전성을 검증해야 한다.
  • 관측성(Observability) - 외부에서 관찰 가능한 데이터를 통해 시스템 내부의 상태를 파악하고 이해하는 정도

구글의 웹 서버 이야기 (2005)

• 문제점
  • 팀 별 코드가 통합되지 않음.
  • 다른 팀과 코드 충돌 시, 모든 코드를 검사해야 함.
  • 테스트되지 않은 코드가 배포되기도 함.
• 해결 방안
  • 모든 기능에 대한 자동화 테스트 강제
  • 테스트 커버리지 모니터링
• 결과
  • 여러 팀의 변경 사항을 매주 통합할 수 있게 됨.
  • 배포 주기가 짧아짐
• 인상깊은 부분
  • 대부분의 코드가 단일 저장소에 존재함
  • 마인드셋
    • 모든 사람은 선한 일을 할 것이며, 높은 신뢰의 문화를 바탕으로 문제를 빠르게 해결할 수 있을 것이라고 믿는다.
    • 각 팀은 상호 존중하에 기능 개발을 위해 타 팀의 프로젝트를 고장낼 수 있다.
  • 궁금한 점) 시스템 커밋?
    • 배포 자동화를 위한 커밋인지..?

코드를 지속적으로 빌드 및 테스트하고 환경과 통합하라

• 커밋할 때마다 자동으로 빌드→단위/통합 테스트→환경 검증이 수행되어야 함
• 이를 통해 항상 "배포 가능한" 코드 상태가 유지됨
  => 배포 파이프라인(젠킨스 파이프라인, tekton 파이프라인, etc...)
• 배포 파이프라인 구축 후 세 가지 프랙티스를 수행해야 함.
  1. 배포 가능 상태에 있음을 검증하는 포괄적이고 신뢰할 수 있는 자동화 테스트
  2. 검증 테스트가 실패했을 때 '전체 프로덕션 라인을 중단'하는 문화
  3. 지속적 통합 배포를 위한 작은 단위의 브랜치 작업 개발자

빠르고 신뢰도가 높으며 자동화된 검증 테스트 스위트를 만들어라

• 단위 테스트
  • 단일 메소드, 클래스 또는 독립된 기능을 테스트
  • 자동으로 진행된다.
• 인수 테스트
  • API 의 정확성 등 어플리케이션 전체 테스트
  • 고객의 의도대로 동작하는 것을 증명해야 한다.
  • 자동으로 진행된다.
• 통합 테스트
  • 어플리케이션이 다른 프로덕션과 올바르게 상호 작용하는지 검증 => 실제 호출, E2E 테스트?
  • 외부와 의존성이 강하기에 취약하며, 갯수를 최소화하는 것을 원한다...
• 테스트 작성을 감시하기 위해 커버리지 수치를 측정하고 시각화할 수 있다.
  => 커버리지 80% 이하면 실패 등

가능한 한 초기에 자동화 테스트의 오류를 찾아내라

• 오류는 가능한 한 처음 코드 작성 또는 커밋 단계에서 발견되어야 한다.

• 통합 테스팅에서는 오류 발견이 어려우며, 과정이 복잡한만큼 오류 재현 및 수정 검증 과정 모두 복잡해진다.
  

• 테스트가 빠르게 실행되게 하라

  • 병렬 테스트를 가능하게 하여 모든 테스트가 가능한 빈번하게 수행되고 지속적으로 수행되어야 한다.

• 테스트 주도 개발

  • 신뢰할 수 있는 자동화 테스트를 보유하기 위한 효과적인 방법은 TDD, ATDD
    • TDD(Red-Green-Refactor): 개발자 중심
      
    • ATDD
      고객, 개발자, 테스터 간의 커뮤니케이션을 기반으로 하는 개발 방법론으로써, 고객-개발자-테스터 간의 협업 중심
      요구사항을 기준으로 테스트를 작성하고 이후 TDD 절차에 맞춰 개발-배포 진행
      

• 수동 테스트를 가능한 자동화하라.

  • 잘못된 자동화 테스트를 보완하기 위한 수동 테스트를 지양해야 한다.
    => 신뢰할 수 있는 자동화 테스트를 시작으로 점차 자동화 테스트를 추가하라.

• 테스트 스위트에 성능 테스팅을 통합하라

  • DB 쿼리 시간 증가, 트래픽 증가, 호출횟수 증가 등 부하가 발생하는 환경에 대비한 성능 테스트가 필요하다.
  • 인수 테스트를 병렬로 실행시키면 성능 테스트로 활용할 수 있다.

• 비기능 요구사항에 대한 테스팅을 테스트 스위트와 통합하라

  • 프로덕션 요구사항 외 유지보수, 품질 관점 등 비기능 요구사항에 대한 테스트가 필요하다.
    • DB, 라이브러리, 애플리케이션 지원
    • 언어 지원 => 버전도 포함?
    • OS, 그 외 모든 의존성

배포 파이프라인이 망가지면 안돈 코드를 당겨라

• 배포 파이프라인이 망가지면 안돈 코드를 당기고 즉시 조치를 취해야 한다.
• 해결하지 않을경우 아래와 같은 문제가 발생할 수 있다.
  • 문제가 발생한 코드에 새로운 기능이 체크인되어 새로운 기능이 테스트되지 않는다.
  • 새로운 기능에 대한 테스트가 온전히 성공하는지 확인하기 어렵다.
  • 이미 오류가 발생하고 있기에 신규 테스트를 만들지 않을 가능성이 높다. => ??

결론

올바른 테스트를 작성하고 이를 자동화하여 코드 품질을 올릴 수있다.
이를 배포 파이프라인으로 조직화하여 테스트의 효율성을 올릴 수 있다.
위 과정을 통해 소규모 팀이 독립적이고 안전하게 개발과 테스트를 수행하고 배포할 수 있다.