빌드와 배포

빌드

• 컴파일
  • 작성한 소스 코드를 바이너리 코드로 변환하는 과정
• 링크
  • 여러개로 분리된 소스 코드들을 컴파일한 결과물들에서 최종 실행 가능한 파일을 만들기 위해
    필요한 부분을 찾아서 연결해주는 작업
• 빌드
  • 소스 코드를 실행한 가능한 소프트웨어 산출물로 만드는 일련의 과정
  • jar, war, exe, bat, dmg, ...

CI / CD

CI Continuous Integration ( 지속적 통합 )

• 개발자를 위한 자동화 프로세스
• 모든 개발이 끝난 이후에 코드 품질을 관리
• 고전적 방식의 단점을 해소하기 위해 도입
• 프로세스
  • 코드를 통합한다.
  • 통합한 코드가 제대로 동작하는지 테스트한다.
  • 제대로 빌드가 되는지 테스트한다
  • 결과를 정리하고 버그가 존재한다면 적어둔다.
• 대표적 Tools
  • Jenkins, Travis

CD Continuous Deploy ( 지속적 배포 )

• 소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 관리

무중단 배포

문제상황

기존에 동작하고 있는 서버가 존재 그 상태에서 새롭게 업데이트한 코드를 배포한다면?

→ 충돌이 발생 ( 대표적으로 Port 충돌 )

→ 서버를 내리고 업데이트 후 배포

→ 다운 타임( 유저에게 서비스가 불가능한 시간 )이 발생한다.

필요조건

• 두 대 이상의 서버가 필요
• 실제 서비스 중인 서버와 새롭게 배포한 서버가 동시에 존재해야 함.

Rolling 배포

과정

• [ 서버 1 ] 로드 밸런서에서 제거 → 배포 → 로드 밸런서에 넣음
• [ 서버 2 ] 로드 밸런서에서 제거 → 배포 → 로드 밸런서에 넣음
• [ 서버 N ] 로드 밸런서에서 제거 → 배포 → 로드 밸런서에 넣음

단점

• 배포가 끝나기 전까지 유저별로 다른 서비스를 받을 가능성이 생긴다.

Canary 배포

소수의 유저만 사용하는 환경에 신규 버전을 배포하고 문제가 없다고 판단되면 다른 모든 서버에 배포한다.

Blue / Green 배포

Blue: 실제로 서비스 중인 환경, Green: 새롭게 배포할 환경 을 세트로 준비해서 배포

장점

• 새롭게 배포할 환경에만 배포하면 되기 때문에 배포 속도가 매우 빠르다
• 언제나 Green 환경이 떠있기 때문에 만약 잘못된 버전으로 배포했을 경우 신속하게 롤백이 가능

단점

• 언제나 Green 환경이 떠있기 때문에 비용이 두 배로 든다

참고자료

https://www.youtube.com/watch?v=6SvUZqbU37E