지속적 전달에서의 테스트 자동화

 

 

이어지는 시리즈

• 지속적 통합(CI) 테스트 자동화
• 지속적 전달(CD) 테스트 자동화
• 지속적 배포(CD) 테스트 자동화

 

지속적 전달(Continuous Delivery)

새로운 코드 릴리스를 고객에게 가능한 빨리 제공하는 것
프로덕션에 모든 변경사항을 배포하지 않더라도, 항상 릴리스 될 준비가 되어있는지 확인
가능한 자주 프로덕션을 업데이트 → 변경 범위 작게 유지

 

 

 

CI → 자동화 테스트 → CD

'자동화 테스트'는 모든 개발 단계에서 실행되어 품질을 보증해주므로,

소프트웨어는 항상 배포 준비 상태로 유지됨!

 

 

어떤 종류의 테스트를 자동으로 수행할 수 있을까?

E2E 테스트, 단위 테스트, 통합 테스트, 성능 테스트, ...

 

End-to-End(E2E) 테스트

구현해야 할 가장 가치있는 테스트

사용자 수준의 경험을 시뮬레이션 → 주요 사용자 경험 흐름의 기록

ex. "A user can login.", "A user can change email settings." (사용자 수준 스토리)

빠른 일일 릴리스 하지 않는 경우, 수동 실행 적합!

 

단위(Unit) 테스트

각 function의 예상 입력값 = 예상 출력값

저렴하고 빠른 구현, 높은 ROI

 

통합(Integration) 테스트

외부 Dependency를 mock하고, 예상대로 상호작용되는지 확인

작성 방식과 도구 측면에서 단위 테스트와 유사 (단위 테스트의 저렴한 대안이 될 수 있음)

E2E 테스트 + 단위 테스트 존재 →  ROI 측면에서 통합 테스트가 필요하지 않을 수도.. 

 

성능(Performance) 테스트

소프트웨어 개발에서 성능이란? 프로젝트가 반응하는 속도와 응답성을 설명

ex. 페이지 로드 시간, 처음 렌더링 시간, 검색 결과 응답 시간

자동화된 성능 테스트 → 회귀 또는 속도 저하 경고

 

 

어떤 종류의 테스트를 수동으로 수행할 수 있을까?

탐색적 테스트, 시각적 회귀 테스트, ...

 

탐색적(Exploratory) 테스트

버그나 예기치 않은 행동들을 찾기위해 '랜덤 & 스크립트되지 않은 절차'를 시도

수동으로 인간의 창의성을 사용하여 소프트웨어 제품을 탐색 → 효과적

 

시각적 회귀(Visual Regression) 테스트

UI에 시각적 디자인 결함 생성 → 시각적 회귀 발생!

ex. 잘못된 UI 요소, 글꼴, 색상 등

자동화 도구 사용 → 높은 개발 비용, 널리 채택되지 않음

 

---

테스트 자동화 프레임워크 구축

고려사항

릴리즈 빈도 → 빠르게 릴리즈되는 제품 (매월/매주 고정 릴리즈는 수동이 적합)

사용가능도구 & ecosystem → 프로그래밍 언어(+유틸리티 ecosystem)와 도구 지원의 교차점 필요

제품 시장 적합성 및 코드 베이스 성숙도 → 타겟층이나 비지니스 모델이 입증되지 않은 경우, 자동화 테스트 X

자동화 테스트 = 예기치 않은 코드 회귀를 제한하는 보험 메커니즘

(코드가 급격하고 빠르게 변경될 때, 자동화 테스트 유지 관리 비용 ↑)

 

---

예. 지속적 전달(Continuous Delivery) 파이프라인 구축

    → 빌드가 테스트를 패스하면, staging에 자동으로 배포(deploy)하는 파이프라인

 

제품 배포(deployment)를 위한 2 가지 전략

1. 브랜치와 pull request 사용
2. 커스텀 파이프라인과 수동 트리거 사용

시작하기에 앞서, Bitbucket 파이프라인에 environment variables을 추가한다 (Heroku-무료 호스팅 서비스에 배포)

 - HEROKU_API_KEY, HEROKU_STAGING, HEROKU_PROD

 

여러 브랜치와 함께 하는 지속적 전달 (= production으로 향하는 게이트)

- 배포와 연결되어있는 릴리즈 브랜치가 있는 팀에게 적합, production으로 배포되기 전에 pull request의 변경을 리뷰할 수 있음

 

배포를 트리거하기 위한 2개의 브랜치

• master: master 브랜치로 push하면, 코드는 테스트 실행 후에 staging 환경에 배포
• production: production 브랜치에 코드가 병합(merge)되면, 자동으로 production 환경에 릴리즈

 

1. staging 환경에 배포 구성

    ★ branch-specific 파이프라인 사용하여, master 브랜치의 모든 push에 대해 실행되는 파이프라인 생성

          ☆ bitbucket-pipelines.yml

image: node:4.6.0   
clone:   
  depth: full   
pipelines:   
  branches:     
    master:       
      - step:           
        script:             
          - npm install             
          - npm test             
          - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git master

    ★ 애플리케이션 빌드 → 테스트 → 모든 push를 Heroku에 배포하는 파이프라인 구축!

    ★ 이 구성을 Bitbucket에 push하면, staging에 대한 첫번째 자동 배포 확인 가능

 

2. production 브랜치에 대한 다른 파이프라인 추가

    ★ 변경사항이 production 브랜치에 병합(merge)될 때, production 환경에 자동으로 릴리즈

        ☆ bitbucket-pipelines.yml

image: node:4.6.0   
# Doing a full clone to be able to push back to Heroku. 
clone:
  depth: full   
pipelines:   
  branches:
    # When code is pushed to the master branch it is deployed automatically to the staging environment.
    master:       
      - step:
        script:
          - npm install
          - npm test
          - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git master     
    production:
      - step:
        script:
          - npm install
          - npm test
          - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git production:master

     ★ production 브랜치에서 테스트를 다시 실행하여, 애플리케이션 출시 전 빌드에 영향을 미치는 것이 없는지 확인!

 

3. production 브랜치가 pull requests를 통해서만 병합을 허락할 수 있도록 제한

     ★ local machine에서 production으로 push하는 것을 방지

          ☆ 쓰기 권한(write access): 쓰기 권한 없음

          ☆ pull request를 통한 병합: 1명의 개발자만 브랜치로 병합할 수 있음

          ☆ 병합 체크(merge check): 병합하기 전에, source 브랜치가 최소 하나의 그린 빌드가 있는지 확인

 

4. pull request 생성하여 코드 병합(master → production),  production 환경에 새로운 변경 사항을 릴리즈

    ★ pull request 병합하면, production 브랜치에 트리거된 새로운 파이프라인을 볼 수 있음

 

5. 다 완성되면, 새로운 변경이 성공적으로 production 환경에 배포됨!

 

 

출처: www.atlassian.com/continuous-delivery/tutorials/continuous-delivery-tutorial