1. 빌드란 - 컴파일과 빌드

컴파일 : 작성한 소스 코드를 바이너리 코드로 변환하는 과정 링크 : 여러개 로 분리된 소스 코드들을 컴파일한 결과물들에서 최종 실행 가능한 파일을 만들기 위해 필요한 부분을 찾아서 연결해 주는 작업!

빌드 : 소스 코드를 실행 가능한 소프트웨어 산출물로 만드는 일련의 과정 (Jar, war)

💡

IntelliJ의 경우 망치 버튼이 빌드 버튼이라고 생각하면 된다!

2. 빌드 도구

소스 코드를 컴파일, 테스트, 정적 분석 등을 실하여 실행 가능한 애플리케이션으로 자동 생성하는 프로그램

계속해서 늘어나는 라이브러리의 자동 추가 및 관리

라이브러리 버전을 자동으로 동기화

💡

알다 시피 자바에서 빌드도구 로는 ANT, Maven, Gradle 등이 있다!

💡

ANT - XML 기반 빌드 스크립트를 개발 - 규칙이 없다. - 절차적이다. (명확한 빌드 절차 정의가 필요하다.) - 생명주기를 갖지 않아 각각의 Target에 대한 의존관계와 작업을 정의해 주어야 한다.! 단점 - 유연성이 높으나 프로젝트가 복잡해지는 경우 Build 과정의 이해가 어렵다. - XML, Remote Repository 를 가져올 수 없다. - 스크립트 재사용이 어렵다.

💡

Maven - >자동 관리~~!! 특징 - 프로젝트에 필요한 모든 종속성을 리스트 형태로 Maven에게 알려주어서 종속성을 관리한다. - XML, Repository를 가져올 수 있다. - POM.xml이라는 Maven 파일에, 필요한 Jar, Class Path를 선언만 하면 직접 다운로드 할 필요가 없어 Repository에서 자동으로 필요한 라이브러리 파일을 불러와준다. 단점 - 라이르버리가 서로 종속할 경우 XML 이 복잡해진다. - 계층적인 데이터를 표현하기에는 좋지만, 플로우나 조건부 상황을 표현하기 어렵다. - 편리하나 맞춤화된 로직 실행이 어렵다.

💡

Gradle 특징 - JVM 기반의 빌드 도구 - ANT와 Maven의 단점을 보완 - 오픈소스 기반의 Build 자동화 도구 - Groovy(JVM 위에서 작동하는 스크립트 코드) 기반 DSL로 작성한다. - Build-by-convention을 바탕으로 한다. → 스크립트 규모가 작고 읽기 쉽다. - 설정 주입 방식(configuration injection) → 종속성을 주입시키면 알아서 관리를 해준다! 버전이 바뀌더라도 코드 한줄만 수정해주면 된다!

가장 중요한 성능?

- Gradle이 Maven 보다 빌드에 소요되는 시간, 유연성, 종속성 관리 등 다양한 측면에서 뛰어나다는 평가!

얼마나 간편하게 설정할 수 있는가?

라이브러리가 종속될 경우, 특정 조건을 표현할 경우에 Maven이 이름 처리하기 복잡하다고 한다. 반면 Gradle은 스크립트가 더 짧고 읽기 쉽게 되어있다.

라이브러리 의존성 관리?

Gradle이 Mavne 보다 더 효율적이고 강력한 기능을 제공하고 있다.

Gradle은 버전 충돌 또한 관리해준다.

3. 배포란(deploy-병사 배치)

작성한 코드를 빌드하고, 빌드가 완성된 실행 가능한 파일(jar war)을 사용자가 접근할 수 있는 환경에 배치하면 배포가 완료된 것!

빌드를 하고 생성된 jar 또는 war 파일을 WAS에 올리는 것이 배포!!

git(소스 형상 관리)에 올려두고

코드가 제대로 동작하는지 테스트 코드를 작성하고

이를 수행 및 검증하는 작업까지라고 나눌 수 있다.

→ 이를 사용자가 직접 반복해서 해야한다!! 이를 자동화시키는 빌드 자동화/배포 자동화를 해야한다. (이는CI / CD)

4. CI/CD에 대하여

CI : Continuous Integration(지속적 통합)

개발자를 위한 자동화 프로세스인 지속적 통합으로 모든 개발이 끝난 이후에 코드 품질을 관리하는 고전적 방식의 단점을 해소하기 위해 나타난 개념

코드를 통합한다.

통합한 코드가 제대로 동작하는지 테스트한다.

제대로 빌드가 되는지도 테스트한다.

결과를 정리하고 버그가 존재한다면 적어둔다.

→ 이를 해결하기 위해서 자동화 도구가 필요해짐

Jenkins / Travis CI는 자동화하는 툴로서 작동한다! CD : Continous Deploy (지속적 배포)

소프트웨어가 항상 신뢰간으한 수준에서 배포될수 있도록 관리하자는 개념(테스트도 다 통과하고 빌드도 다 되고)

💡

지속적으로 통합하면서 테스트와 빌드를 진행하고 이를 통과한 코드에 대해서 신뢰할 수 있고 바로 배포할 수 있다는 내용!

5. 무중단 배포

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

충돌이 발생한다

- > 기존에 서비스 중인 서버를 잠시 내리고 코드를 배포한 후 다시 서버를 동작시켜야 한다.

8080 포트에 서버를 띄운다.

새롭게 배포할 내용이 있다면 포트 충돌을 막기 위해서 서버를 다운 시킨다.

8080 포트에 새롭게 배포할 서버를 띄운다.

→ 서버가 다시 뜨는데 30초의 시간이 걸린다고 한다면 그 시간만큼 다운 타임(유저에게 서비스가 불가능한 시간)이 발생한다!!!

필요 조건

두 대 이상의 서버를 서비스해야 하낟.

다운 타임이 발생하지 않으려면 실제 서비스 중인 서버와 새롭게 배포한 서버가 동시에 존재해야 한다.

비용을 줄이려면 배포할 떄만 새롭게 서버를 띄우고 배포가 완료된 후에 기존 서버는 죽이면 된다.

Rolling 배포

서버 1을 로드 밸런서에서 뺀다.

서버 1을 배포한다.

서버 1을 다시 로드 밸런서에 넣는다.

서버 2를 로드 밸런서에서 뺀다.

서버 2에 배포한다.

서버 2를 다시 로드 밸런서에 넣는다.

→ 이경우 서버 마다 서비스가 달라질 수 가있다는 문제점이 있다.

단점

배포할 서버가 너무 많다면 n대 단위로 배포하기도 하는데 배포가 모두 끝나기 전까지는 누구는 이전 서비스를 받고 누구는 신규 서비스를 받을 수 있다는 문제가 존재한다.

1대에 배포하는 것 보다 최소 2배 이상 느리다.

Canary 배포

광부들이 광산에 유독가스가 나오는 것을 알아내기 위해서 가스에 민감한 카나리아를 광산 안에서 키웠다고 해서 유래된 배포 소수의 유저만 사용하는 환경에 신규 버전을 배포하고 문제가 없다고 판단됐을 때 다른 모든 서버에 배포한다.

Blue/Green 배포

실제로 서비스 중인 환경(Blue)와 새롭게 배포할 환경(Green)을 세트로 준비해서 배포하는 방식을 말한다.

장점

새롭게 배포할 환경에만 배포하면 되기 때문에 배포 속도가 매우 빠르다.

언제나 Green 환경이 떠있기 떄문에 만약 잘못된 버전으로 배포를 했을 경우에 신속하게 롤백이 가능하다.

단점

Green 환경이 항상 떠있어야 하기 때문에 비용이 2 배로 든다.

출처

우아한 테크코스 : 스티치의 빌드와 배포

배포 전략의 종류

컴파일? 빌드 ? 배포? 개념과 차이는 무엇일까?

[QA] 컴파일? 빌드? 배포? 개념과 차이는 무엇일까?

본인이 번역가라고 생각해보자. 이번에 출판사로부터 일을 하나 받았는데, 영문으로된 글을 한글로 번역하는 일이다. 번역된 글은 출판사에서 적절히 페이지를 나누어 책으로 엮을 것이며, 완성된 책은 출판이 되어 서점에 진열될 것이다. 우리는 방금 컴파일, 빌드, 배포의 모든 과정을 훑어보았다. 1. 영문으로된 글을 한글로 번역하는 것은 컴파일이다. 2. 번역한 글을 책으로 엮는 것은 빌드이다.

https://itholic.github.io/qa-compile-build-deploy/

주니어 개발자의 CI/CD 도입기

라이더스 개발팀 모바일에서 CI/CD 도입기

무중단 배포란...?

Uploaded by Notion2Tistory v1.1.0

'Project > Tech_review' 카테고리의 다른 글

캐시 그리고 세션 (0)	2021.02.26
스프링 배치 (0)	2021.02.26

찬란한 기대가 비추는 물결을 걸어가다.

빌드와 배포

1. 빌드란 - 컴파일과 빌드