6 min to read

Continuous Deployment (지속적 통합) / TIL

Continuous Deployment

Featured image

지속적 통합

전통적인 SW 전달 방식 : 폭포수 모델 (Waterfall)

여전히 모바일 앱이 사용하는 전달 방식으로, 출시 기한을 정해두고 소프트웨어를 완성하는 방식이다.

클라우드 서비스의 전달 방식 : 애자일 모델 (Agile)

서비스 전달/배포 Workflow를 구성할 수 있어야 하며, 자동화가 필수적이다.

SaaS (Software as a Service)


CI/CD 파이프라인 : 지속적 배포(Continuous Deployment)

모든 코드 변경이 배포로 이어진다.
지속적 배포 = 지속적 통합 + 지속적 전달

지속적 통합 (Continuous Integration/CI)

팀 구성원이 각자의 작업을 자주 통합하는 소프트웨어 개발 방식 - Martin Fowler

지속적 통합을 통해 버그를 일찍 발견할 수 있고, 테스트가 완료된 코드에 대해 빠른 전달이 가능하다. 또한 빌드 및 테스트와 같이 사람이 해야 할 일들을 자동화할 수 있다.

지속적 통합의 원칙

지속적 통합에서 테스트는 중요하다. 테스트를 통해 결함과 버그를 조기에 발견할 수 있고, 이는 개발자의 생산성을 향상할 수 있다. 또한 제품의 결함과 버그를 발견하고 수정하는 것은 소프트웨어의 품질을 보증하고, 더 안정적이고 사용하기 쉽게 만든다.

지속적 전달 (Continuous Delevery/CD)


테스트 주도 개발(Test Driven Development, TTD)

테스트가 기능의 디자인을 주도하는 반복적인 개발 방법론.

기존의 개발 방식
요구사항 분석 → 디자인 설계 → 개발 → 테스트

테스트 주도 개발 방식
요구사항 분석 → 디자인 설계 → 테스트 → 개발

기존 개발 방식과 다르게 테스트 주도 개발은 설계 후 테스트를 한 뒤 개발을 진행한다.

TDD의 테스트는 큰 단위의 문제를 작은 단위로 나누어, 지속적 피드백을 통해 개선해 나가는 방향으로 진행된다.

TDD의 장점


테스트 종류

단위 테스트

// 만일 sum(x, y) 와 같이 두 숫자를 더하는 함수를 테스트하려면,

it('sum에 두 수를 인자로 입력하면, 두 수의 합이 리턴됩니다', () => {
  expect(sum(1,1)).to.be.equal(2)    // sum(1,1)의 리턴값은 2가 될 것이라고 기대한다
  expect(sum(100, 200)).to.be.equal(300)
})

검증이 필요한 코드에 대해 테스트 케이스를 작성하는 절차 혹은 프로세스. 단위 테스트를 통해 즉각적 피드백이 나오지만, 그들이 결합하는 시점에서도 잘 작동하는 지에 대해서는 보장할 수 없기 때문에 염두에 두어야 한다.


통합 테스트

// 서버에 API 요청을 보냈을 때, 정확한 응답이 오리라고 기대하는 경우
// 아래의 코드가 백엔드 입장에서는 단순 유닛 테스트라고 볼 수도 있지만
// 서버와 클라이언트 코드가 별도로 작성되어 있고, 서버-클라이언트의 통합을 테스트해야 한다면, 이는 통합 테스트라고 할 수 있습니다.

it('서버에 POST /upper 요청에 body를 실어 보내면 응답은 대문자로 돌려줍니다', () => {
  return request(API서버)
    .post('/upper')
    .send('"coDeStaTes"')
    .set('Content-Type', 'application/json')
    .then(res => {
      expect(res.body).to.be.equal('CODESTATES')
    })
})

모듈을 통합하는 과정에서 모듈 간 호환성 문제를 찾아내기 위해 수행되는 테스트이다. 단위 테스트에서 찾지 못하는 통합 시 발생하는 버그 등을 찾을 수 있다.

단위 테스트 및 통합 테스트 시 사용하는 도구


E2E 테스트 (End To End Test)

전체 시스템이 제대로 동작하는지 확인하기 위한 테스트. 사용자의 입장에서 사용자가 사용하는 상황을 가정하고 시뮬레이션을 진행한다.

E2E 테스트를 통해 실제 상황에서 발생할 수 있는 에러를 사전에 발견할 수 있다.

하지만, 테스트 작성 시 들어가는 비용이 많으며, 수행 속도가 느리다. 또한 “실패했다”라는 결과만 있기 때문에 피드백의 질이 낮다.

E2E 테스트 시 사용하는 도구

통합 테스트와 E2E 테스트의 차이

통합 테스트 E2E 테스트
앱 구성 요소들이 잘 작동하는지 확인하는 테스팅 사용자가 경험하는 것처럼 제품을 테스트
대개 전체 스택을 포함하지 않고 여러 구성 요소에 걸쳐 있다. 범위가 더 넓고 전체 애플리케이션 기술 스택을 포함한다.
구성 요소들이 함께 작동할 때 연결성 문제를 발견하기 위해 수행된다. 사용자 경험을 느끼기 위해 수행된다.
구현 비용이 적다. 하드웨어 및 소프트웨어 측면에서 구현 비용이 더 많이 든다.
유닛 테스팅보다 높은 수준 통합 테스팅보다 높은 수준
수행 속도가 빠르다. 수행 속도가 느리다.


* 릴리즈 : 배포 가능한 소프트웨어 패키지 / 애자일 소프트웨어 개발에서의 의미로 한정
* 출시 : 상품이 시장에 나오거나 내보냄 / 비즈니스적 관점에서의 용어로서 사용
* 메인라인 : 시스템의 현재 상태를 의미한다. 회사마다 어떤 브랜치를 메인라인으로 두는지는 조금씩 다르다.