10분 테코톡 - 빌드와 배포
https://www.youtube.com/watch?v=6SvUZqbU37E
| 빌드, 컴파일, 링크
컴파일 : 작성한 소스코드를 바이너리 코드(2진법)로 변환하는 과정
빌드 : 소스 코드를 실행 가능한 소프트웨어 산출물로 만드는 일련의 과정
링크 : 여러개로 분리된 소스 코드들을 컴파일한 결과물들에서 실행 가능한 파일을 만들기 위해
필요한 부분을 찾아서 연결 해주는 작업
| 빌드 도구
1) 소스 코드를 컴파일, 테스트, 정적 분석 등을 실시하여 실행 가능한 애플리케이션으로 자동 생성하는 프로그램
2) 계속해서 늘어나는 라이브러리의 자동 추가 및 관리
3) 라이브러리의 버전을 자동으로 동기화
ANT
특징
1) XML 기반 빌드 스크립트 개발
2) 규칙이 없음
3) 절차적(명확한 빌드 절차 정의가 필요)
4) 생명주기를 갖지 않아 각각의 타겟에 대한 의존관계와 작업을 정의해 주어야 함.
단점
1) 유연성이 높으나 프로젝트가 복잡해지는 경우 빌드 과정의 이해가 어려움
2) XML, Remote Repository를 가져올 수 없음
3) 스크립트 재사용에 어려움
Maven
특징
1) 프로젝트에 필요한 모든 종속어(Dependency)을 리스트 형태로 Maven에게 알려주어 종속성을 관리
2) XML, Repository를 가져올 수 있음
POM.xml 이라는 Maven 파일에 필요한 Jar, Class Path를 선언만 하면 직접 다운로드할 필요 없이 Repository에서 자동으로 필요한 라이브러리 파일을 불러옴
단점
1) 라이브러리가 서로 종속할 경우 XML이 복잡해짐
2) 계층적인 데이터를 표현하기에는 좋지만, 플로우나 조건부 상황을 표현하기 어려움
3) 편리하나 맞춤화된 로직 실행이 어려움
Gradle
특징
1) JVM 기반의 빌드도구
2) Ant와 Maven의 단점을 보완
3) 오픈소스 기반의 빌드 자동화 도구
4) Groovy 기반 DSL로 작성
5) Build-by-convention을 바탕으로 함 >> 스크립트 규모가 작고 읽기 쉬움
6) 설정 주입 방식(configuration injection)
Maven VS Gradle
1) 성능
Gradle이 Maven보다 빌드에 소요되는 시간, 유연성, 종속성 관리 등 다양한 측면에서 유리함
2) 간편성
라이브러리가 종속될 경우, 특정 조건을 표현할 경우에 Maven이 이를 처리하기 복잡함. 이에 반해 Gradle은 스크립트가 더 짧고 읽기 쉽게 되어있음.
3) 라이브러리 의존성 관리
Gradle이 Maven 보다 더 효율적이고 강력한 기능을 제공하고 있음
Gradle은 버전 충돌을 관리해줌
| 배포란
작성한 코드를 빌드하고, 빌드가 완성된 실행 가능한 파일을 사용자가 접근할 수 있는 환경에 배치하는 것
빌드 후 생성된 jar 또는 war파일을 WAS(Web Application Server)에 올리는 것이 배포
1) git(소스 형상 관리)에 올려두고
코드가 제대로 동작하는지 테스트 코드를 작성하고
이를 수행 및 검증하는 작업
| CI / CD
CI(Continuous Integration) : 지속적 통합
개발자를 위한 자동화 프로세스인 지속적 통합으로 모든 개발이 끝난 이후에 코드 품질을 관리하는 고전적 방식의 단점을 해소하기 위해 나타난 개념
CI의 프로세스
1) 코드를 통합한다
2) 통합한 코드가 제대로 동작하는지 테스트
3) 제대로 빌드가 되는지 테스트
4) 결과를 정리하고 버그가 존재한다면 정리함
CD(Continuous Deploy) : 지속적 배포
소프트웨어가 항상 신뢰 가능한 수준에서 배포될 수 있도록 관리하자는 개념
| 무중단 배포
기존에 동작하고 있는 서버(배포가 완료된)가 존재
그 상태에서 새롭게 업데이트한 코드를 배포한다면? >> 충돌 발생
>> 기존에 서비스 중인 서버를 잠시 내리고 코드를 배포한 후 다시 서버를 동작 시켜야함
다운타임
띄웠던 기존의 서버를 다운시킨 후 다시 배포할 서버를 띄우는 동안 소요되는 시간(유저에게 서비스가 불가능한 시간)
필요조건
1) 두 대 이상의 서버를 서비스해야 함
2) 다운 타임이 발생하지 않으려면 실제 서비스 중인 서버와 새롭게 배포한 서버가 동시에 존재해야 함
3) 비용을 줄이기 위해 배포할 때만 새롭게 서버를 띄우고 배포가 완료된 후에 기존 서버를 죽인다.
1. Rolling 배포
1) 서버 1을 로드 밸런서에서 뺀다
2) 서버 1에 배포한다
3) 서버 1을 다시 로드 밸런서에 넣는다
4) 서버 2를 로드 밸런서에서 뺀다
5) 서버 2에 배포한다
6) 서버 2를 다시 로드 밸런서에 넣는다
**로드 밸런서 : 서버로부터 들어오는 요청을 최대한 잘 분배해주는 것
단점
1) 배포할 서버가 너무 많다면 n대 단위로 배포하기도 하는데 배포가 모두 끝나기 전까지는 누구는 이전 서비스를 받고 누구는 신규 서비스를 받을 수 있다는 문제가 존재
2) 1대에 배포하는 것보다 최소 2배 이상 느리다
2. Canary 배포
소수의 유저만 사용하는 환경(Canary 환경)에 신규 버전을 배포하고 문제가 없다고 판단됐을 때 다른 모든 서버에 배포
3. Blue/Green 배포
실제로 서비스 중인 환경(Blue)과 새롭게 배포할 환경(Green)을 세트로 준비해서 배포하는 방식
장점
1) 새롭게 배포할 환경에만 배포하면 되기 때문에 배포 속도가 매우 빠르다.
2) 언제나 Green 환경이 떠있기 때문에 만약 잘못된 버전으로 배포를 했을 경우에 신속하게 롤백이 가능함.
단점
Green 환경이 항상 떠있어야 하기 때문에 비용이 2배로 든다.