[33일차] 지속적 통합
지속적 통합/ CI /Continuous Intergration
지속적 통합은 기존에 있던 기능과 새로운 기능의 통합을 의미한다.
개발자가 애플리케이션에 적용한 변경 사항이 병합되면 이러한 변경 사항이 애플리케이션을 손상시키지 않도록 자동으로 애플리케이션을 구축하고 각기 다른 레벨의 자동화 테스트(일반적으로 단위 테스트 및 통합 테스트) 실행을 통해 변경 사항이 애플리케이션에 제대로 적용되었는지를 확인한다. 자동화된 테스트에서 기존 코드와 신규 코드 간의 충돌이 발견되면 CI를 통해 이러한 버그를 더욱 빠르게 수정할 수 있다.
지속적 통합 도구
Jenkins
Jenkins는 오픈소스 자동화 서버이다.
빌드, 테스트, 배포와 같은 소프트웨어 개발의 일부분을 자동화하는 데 도움을 주며, 지속적 통합과 지속적 배포를 돕는다
- 특징
설치형: 별도의 서버가 필요하다.
다양한 플러그인을 활용할 수 있다.
쿠버네티스, Docker 등과 호환된다.
다양한 운영체제에서 사용이 가능하다.
무료로 사용할 수 있으며 1000개 이상의 플러그인을 통해 쉽게 기능을 확장 가능하다.
러닝 커브가 낮고 범용성이 높다.
- 단점
서버의 리소스를 초과해서 사용하는 CI/CD 작업을 실행시 서버가 다운될 수 있다.
장애가 나서 서비스가 내려갔을 경우 그동안 git webhook 이벤트를 받을 수 없다.
JVM으로 인해 사용중이지 않을 때도 메모리를 잡아먹으며 클라우드 환경에서는 불필요한 비용 발생한다.
K8S 환경에서 사용할 경우 추가적으로 플러그인을 설치해야 하며 자격증명을 위한 설정이 필요하다.
깃허브에 접근하기 위해 자격증명을 위한 설정이 필요하다.
플러그인을 최신 상태로 유지해야하며 업데이트 하지 않을 경우 장애가 발생 할 수 있다.
GitHub Action
Github에서 제공하는 빌드, 테스트 및 구축 파이프라인을 자동화할 수 있는 지속적인 통합 및 CI/CD(Continuous Delivery) 플랫폼이다.
- 특징
Local Hosted Runner 설치를 통해 원하는 환경 (linux, max, window)을 구성 가능
추가적인 설치 과정 없이 Github에서 제공하는 환경에서 CI/CD 진행 가능
GitHub에 접근할 때 자격증명을 위한 설정이 필요하지 않다.
GitHub 마켓플레이스를 통해 다른 사람들이 작성해 놓은 파이프라인을 사용하거나 자신이 작성한 파이프라인을 공유 가능하다.
CI/CD 과정을 GitHub 페이지에서 모두 확인 할 수 있다.
- 단점
깃허브에서 제공하는 환경은 Public Repository에서는 무료로 사용 가능하지만 Private Repository에서는 요금 발생한다.
Local Hosted Runner을 사용해 새로운 환경을 구축할 경우 서버에 장애가 일어나거나 리소스를 초과할 경우 개발자가 직접 문제를 해결해야 한다.
Jenkins vs GitHub Action
jenkins는 설정에 자신있고 완전한 제어와 비용에 문제가 되지않는다.
하지만 jenkins에 자신이 없고 더 나은 대안을 찾는사람들에게는 github action이 좋은 선택이다.
Jenkins는 다양한 IDE를 지원하고 커스터마이징이 다양하다.
또한 전세계 많은 사용자들이 이용하고 유명하기때문에 그만큼 문서도 다양하다.
하지만, 호스팅을 직접 하나부터 열까지 모두 해야하기에 관련된 모든 문서를 관리해야하는 부분과 이로인한 비용이 발생한다. 이로인해 젠킨스는 규모가 작은 프로젝트에도 설정하는데 많은 리소스가 발생해 github actions이 좋다.
반대로 규모가 클수록 GitHub Actions보다는 jenkins를 추천한다.
테스트 주도 개발(Test Driven Development, TDD)
테스트 주도 개발이란 테스트가 기능의 디자인을 주도하는 반복적인 개발 방법론을 뜻한다.
- 기존의 개발 과정
기존의 개발 프로세스는 아래와 같다.
- 요구사항 분석
- 요구 사항을 토대로 디자인(설계)을 진행
- 설계에 맞추어 기능을 개발.
- 구현 완료 후 수동으로 기능을 테스트
- 원하는 대로 동작하지 않거나 문제가 발생하면 디버깅을 통해 원인을 파악하고 수정
- 3 - 4의 과정을 개발이 완료될 때까지 반복
- 테스트 주도 개발 과정
기존의 개발 프로세스를 보완하기 위해 태어난 테스트 주도 개발(TDD)의 프로세스는 아래와 같다.
- 요구사항 분석
- 요구 사항을 토대로 디자인(설계)을 진행
- 설계를 기반으로 기능 테스트 진행
- 실패 시 다시 설계
- 테스트가 성공했다면 개발 진행
- 3 - 4의 과정을 개발이 완료될 때까지 반복
테스트의 종류
- 단위 테스트
말 그대로 작은 단위의 테스트 이다.
검증이 필요한 코드에 대해 테스트 케이스를 작성하는 절차 혹은 프로세스를 뜻한다.
유닛 테스트의 장점으로는 즉각적인 피드백이 나오는 것을 들 수 있다. 다만, 하나의 메서드가 잘 작동함은 보장할 수 있지만 그들이 결합하는 시점에서도 잘 작동 하는지에 대해서는 보장할 수 없기 때문에 염두에 두어야 한다.
- 통합 테스트
모듈을 통합하는 과정에서 모듈 간 호환성의 문제를 찾아내기 위해 수행되는 테스트이다.
단위 테스트에서 찾지 못하는 통합시 발생하는 버그 등을 찾을 수 있다.
- E2E 테스트 (End To End Test)
전체 시스템이 제대로 동작하는지 확인하기 위한 테스트이다.
사용자의 입장에서 사용자가 사용하는 상황을 가정하고 시뮬레이션을 진행한다.
실제 상황에서 발생할 수 있는 에러를 사전에 발견 할 수 있지만, 테스트 작성 시 들어가는 비용이 너무 많이 들어가고 수행 속도가 느리다