CI/CD 전체적인 구조 (1. Build)

ashd89·2025년 4월 27일

CI/CD 구조

목록 보기

1/1

📌 CI/CD 구조 (1.Build)

시험 하나 남았는데 회로 공부하다가 잠깐 쉬어가는 겸 블로그 글 업로드 시작!

📖 무슨 내용인가? (요약)

앞으로 "CI/CD의 구조"라는 주제로 적을 내용은 서버 이전 프로젝트를 진행하기전에, 강의 형식으로 CI/CD의 과정이 어떻게 되는지 현업자 대! 준수님이 설명해준 내용을 내 맘대로 정리한 내용이다. 이전에는 기본적인 형태만 잡고 있었다면, 각 과정을 순차적으로 잘 설명해줘서, 해당 내용과 추가적인 공부 + 알고 있던 지식을 함께 정리해 보려한다.

일단 설명하기 전에, 준수님은 뭐든지 주체와 도구의 구분이 중요하다고 했기 때문에 이 부분을 중점으로 다뤄보겠다!

📖 1. Build

Build (도구 : gradle)

소프트웨어 빌드(software build)의 정의는 소스 코드 파일을 실행할 수 있는 독립(standalone) 소프트웨어 가공물로 변환하는 과정이다.

빌드는 코드를 ,패키징 해서, 어떠한 배포가능한 형태로 만드는 과정

자바 환경에서 설명해보면

먼저 코드는 .java형태로 작성
이후 컴파일러에서 .java를 바이트 코드인 .class로 변환하고 (문법 오류 체크 포함!)
JVM에서 .class파일을 메모리에 할당하고, 바이트코드를 해석 및 실행 (여기 부터를 Runtime이라고 부름!)
사실상 이 과정이 build의 끝

[.class] build의 문제점

여러 클래스의 상호작용을 위해 "java -cp"와 같은 명령어로 class-path를 지정해주어야 하고, 파일이 하나라도 없으면 실행 자체가 안되는 문제가 발생!

[.jar] 패키징

각 클래스 파일들
class-path연결
리소스 파일 (.yml, .xml)
메타데이터
fat jar를 통한 라이브러리 연결
등을 묶어서 zip 형식으로 묶어서 한번에 build가 되게!

이 과정을 진행해 주는 것이 바로 Gradle

Gradle

1) 기본 구조

plugins {
    id 'java'
}

group = 'com.example'
version = '1.0.0'

repositories {
    mavenCentral()
}

dependencies {
    testImplementation 'org.junit.jupiter:junit-jupiter:5.8.2'
}

test {
    useJUnitPlatform()
}

build.gradle
├── plugins: "나는 Java 프로젝트야!"
├── group / version: 프로젝트 식별자 설정
├── repositories: "라이브러리 어디서 받을까?"
├── dependencies: "어떤 라이브러리 쓸까?"
└── test: "JUnit5 기준으로 테스트할게!"

기본적으로 gradle은 plugin과 dependecy 그리고, dependency를 어디서 가져올지를 결정하는 repository로 결정된다. (mavenCentral은 세계 최대 오픈 소스 저장소!)

plugin과 dependecy의 차이가 무엇인가?

Plugin은 gradle에게 이 프로젝트에 대해서 설명하고, 해야할 작업을 알려주는 것!
Dependecy는 내 소스 코드를 실행할 때 필요한 라이브러리

Plugin : "빌드 툴을 업그레이드" (Gradle 자체 upgrade)
Dependency : "내 소스 코드를 업그레이드" (코드 자체에 기능 추가)

🔨 플러그인은 빌드 공장에서 일하는 로봇을 추가하는 거고,
📦 의존성은 내 제품(앱) 안에 들어가는 부품을 추가하는 것!

2) 각 과정

clean : 이전 빌드 결과물 초기화
compileJava : javac(컴파일러)를 호출 해서 .class로!
prcessResources : 리소스 파일을 .class와 함께 복사
jar : 복사한 .class와 resource를 묶어서 jar파일 만들기
test : Junit과 같은 테스트 프레임워크를 활용한 테스트 진행

- 1+2 : gradle classes
- 1+2+3 : gradle assemble
- 1+2+3+4 : gradle build (assemble + test)

결과 : .class 파일을 적당히 묶고 리소스 같은 것들도 추가해서 .jar파일로 만들어냄!

📖 0단계 : Build 이전 과정 (for 자동 배포)

결국 jar 파일을 서버 컴퓨터로 옮겨서 jvm으로 실행하는게 최종 목적인데, 이걸 내가

변경 사항이 있을 때 마다
직접 .jar로 만들고(build)
서버 컴퓨터로 파일을 옮겨서 실행하면,

CI/CD의 의미가 없다!

📖 자동화

보통은 github repository에 특정 조건(브랜치나, 태그) 등을 활용해서 push 했을 때, 원하는 주소로 webhook을 보내 변경사항을 감지한다!

이후에는 변경된 코드를 자동으로 build하고, 2번 과정인 도커 이미지로 만드는 과정까지 진행
=> 이전 프로젝트에서는 이 과정을 jenkins라는 툴의 pipeline을 이용!!!

ashd89