dev + qa = hq sw dev + qa = hq sw

일반적으로 사용할 수 있는 시나리오 예제 풀 리퀘스트(PR)가 생성되면, 테스트 실행 풀 리퀘스트가 develop 브랜치로 병합되면, QA 서버로 배포 풀 리퀘스트가 master 브랜치로 병합되면, production 서버로 배포 예) bitbucket-pipeline.yml (자바스크립트) image: node:15.8.0 pipelines: default: - step: script: - npm run test branches: master: - step: deployment: production script: - npm run test - ./deploy.sh production develop: - step: deployment: staging script: - npm run test - ./dep..

이어지는 시리즈 지속적 통합(CI) 테스트 자동화 지속적 전달(CD) 테스트 자동화 지속적 배포(CD) 테스트 자동화 지속적 배포(Continuous Deployment) 모든 변경사항은 자동으로 production에 배포 개발자 새로운 코드 작성 → 실제 사용자 시스템 코드 품질 유지를 위해 충분한 자동화 테스트 필요 레벨 테스트 (+ 수동 테스트) 예. Bitbucket Pipeline을 이용한 지속적 배포 셋업 어플리케이션, 자동화 테스트 준비 (Heroku 사용하는 경우) 환경 변수 추가 Pipelines > Environment variables로 이동 및 변수 추가 HEROKU_API_KEY: Heroku 계정 API 키 HEROKU_STAGING: staging 환경 이름 HEROKU_PRO..

YAML (YAML Ain't Markup Language) 사전적 의미: 모든 프로그래밍 언어를 위한 인간 친화적 데이터 직렬화(Serialization) 표준 CI/CD 파이프라인 빌드 구성(configuration)을 정의 Repository 루트에 존재 파이프 라인은 단계 리스트로 구성 default 브랜치 섹션에서 정의된 브랜치를 제외한 repository에 대한 모든 푸시에 실행 (+tags/bookmarks에 실행 X) branches 모든 브랜치별 빌드 파이프 라인에 대한 섹션 정의 (names, expressions) tags 모든 태그별 빌드 파이프 라인 정의 (names, expressions) bookmarks 모든 북마크별 빌드 파이프 라인 정의 (names, expressions..

이어지는 시리즈 지속적 통합(CI) 테스트 자동화 지속적 전달(CD) 테스트 자동화 지속적 배포(CD) 테스트 자동화 지속적 전달(Continuous Delivery) 새로운 코드 릴리스를 고객에게 가능한 빨리 제공하는 것 프로덕션에 모든 변경사항을 배포하지 않더라도, 항상 릴리스 될 준비가 되어있는지 확인 가능한 자주 프로덕션을 업데이트 → 변경 범위 작게 유지 CI → 자동화 테스트 → CD '자동화 테스트'는 모든 개발 단계에서 실행되어 품질을 보증해주므로, 소프트웨어는 항상 배포 준비 상태로 유지됨! 어떤 종류의 테스트를 자동으로 수행할 수 있을까? E2E 테스트, 단위 테스트, 통합 테스트, 성능 테스트, ... End-to-End(E2E) 테스트 구현해야 할 가장 가치있는 테스트 사용자 수준의..

이어지는 시리즈 지속적 통합(CI) 테스트 자동화 지속적 전달(CD) 테스트 자동화 지속적 배포(CD) 테스트 자동화 지속적 통합(Continuous Integration) 개발팀이 초기에 자주 코드를 메인 브랜치 또는 Repository에 통합하는 방식 충돌 조기 식별/해결, 개발 주기 시간 절약, 버그/회귀 수정 시간 절약, 개발 중인 기능 이해↑ 자동화 테스트(Automated Testing) 셋업 자동화(된) 테스트 ≠ 테스트 자동화 '자동화 테스트'를 실행하는 테스트 프로세스 '자동화' = 테스트 자동화 Main Repository의 모든 변경 사항에 대해 테스트를 자동으로 실행할 수 있도록 우선적으로 '자동화 테스트' 필요! repo의 (메인 브랜치뿐만 아닌) 모든 브랜치에 테스트 실행 가능 ..