안녕하세요, 오늘은 CI/CD 에 대해 정리해 보았습니다.
CI/CD 개요
💡 소프트웨어 개발 프로세스를 자동화하고 효율화하는 방법론.
지속적 통합(CI)은 코드 변경 사항이 빈번하게 통합되어 빌드 및 테스트되는 것을 의미하며,
지속적 배포(CD)는 검증된 코드 변경 사항을 자동으로 프로덕션 환경에 배포하는 것을 의미합니다.
CI/CD를 통해 개발자들은 빠른 속도로 안정적인 소프트웨어를 출시하고 업데이트할 수 있습니다.
OR
- CD(Continuous Deployment) - 지속적인 배포
CI/CD 는 왜 세상에 나오게 된걸까?
- 회사의 제품을 신속하게 출시하고 업데이트하는 것은 아주 중요한 과제입니다.
만약 내가 운영하는 서비스에 장애가 발생하거나 문제가 있는데 수정이 느리다면?
- 실제 실시간 서비스로 운영되는 온라인 게임의 경우 개발자들의 부담감이 상당했다고 합니다!
- 위와같은 사유만으로 정년퇴직자가 없었던것은 아니지만 어느정도 영향을 주었을것이라 생각합니다.
현재는 서비스의 빠른 업데이트와 다양한 고객의 요구사항을 대응하기 위해
전 세계적으로 수많은 기업이 CI/CD를 개발 프로세스에 포함하고 있습니다.
따라서, 개발자들은 이 개념에 대한 명확한 이해가 필요합니다.
💡 비지니스 세계에서 제품을 빠르게 시장에 반영하여 시장을 선점하고
고객 요구 사항을 충족시키기 위해 CI/CD 환경을 효과적으로 활용하는 것은
아주 중요한 사항중에 하나 입니다.
CI(Continuous Integration)란?
💡 Bug Fix나 새로 기능들이 매일 Git과 같은 Repository에
주기적으로 빌드(Build)되고 테스트(Test)가 되어서 병합(Merge) 되는것을 뜻한다.
문제점 1

- 동일한 브랜치 위에서 두명의 개발자가 서로 다른 코드를 작성하고 있다가 오랜기간 후 Merge 하려고하면?
- Conflict(충돌)이 발생하게 됩니다.
- 서로 다른 코드의 충돌을 해결하기 위해 엄청난 노력을 해야한다.
- 개발하는 시간보다 충돌 해결을 위해서 많은 시간을 사용하게 된다.
문제점 2

- 한명의 개발자가 테스트 코드 없이 그냥 배포를 한다면?
- 검증되지 않은 코드들을 만들어서 바로 배포한다면 운영 Level에 Error가 발생할 수 있다.
- 사용자 경험 측면에서 아주 좋지 않다.
- 완벽하지는 못해도 최선을 기해야한다.
- 함께 일하는 개발팀 또한 고통을 겪게된다.
- 최신 코드를 Pull 받았더니 정상적으로 동작하지 않는다.
요점정리
💡 CI에는 크게 두가지 핵심이 있다.
아래 내용에서 CI 핵심 두가지를 알아보자.
CI

- 개발자는 코드를 작은 단위로 나누어 commit 하고 빈번하게 Merge 한다.
- 위와같은 방식은 1991년 Grady Booch에 의해서 사용되어 지다가
이후 Extream Programming 개발 방법론에서 채택되어 졌습니다.
1. 코드 변경사항을 주기적으로 빈번하게 병합해야 한다.

- 버그를 수정하는 경우
- 작은 단위로 작업을 나누어서 Git 메인 저장소에 효과적으로 반영한다.
- ex) 버그에 대한 대처에 대한 수정 → method 하나 수정 후 commit push, Entity Field 하나 수정 후 commit push
- 새로운 기능을 추가하는 경우
- 사용자에게 배포할 수 있을 정도로 작은 단위(작은 기능 추가)로 나누어 개발하여 반영한다.
- ex) 엑셀 다운로드 기능(method와 같이 작은 단위로 나누어서 추가하자.)을 추가했다.
정리
작성한 코드를 작은 단위로 Commit 하여 자주 Merge 하기만 하여도 Git Conflict를 최소화할 수 있다.
2. 빌드, 테스트의 자동화

Merge : 브랜치들의 코드를 하나로 합치는것
Build : 합쳐진 코드를 Jar 파일로 만드는것
배포 : Jar 파일을 배포하는것
- 주기적으로 코드의 변경 사항 Merge 된다면?
- 배포를 위해 다시 새로운 Version 으로 Build가 되어야한다.
- Merge 후에도 빌드가 성공적으로 되는지 확인이 되어야 한다.
- 새로 추가된 코드의 변경사항은 문제가 없는지 Test 해야한다.
- 새로 추가된 코드가 기존 코드에 문제를 발생시키지는 않는지 Test 해야한다.
- 위 사진에는 Version 이 Up되는 자연 스러운 예시도 함께 녹아 있습니다.
- Bug Fix 혹은 아주 작은 단위의 Update가 발생하면 버전이 뒷부분부터 변동합니다.
- 새로운 기능 추가나 많은 변화가 발생한 Version이라면 가장 앞 Version이 변동합니다.
- ex) 버그수정 혹은 작은 수정시 : 기존 1.0.0 → 1.0.1 혹은 → 1.1.0
- ex) 새로운 기능 혹은 큰 수정시 : 기존 1.0.0 → 1.1.0 혹은 2.0.0
💡 **CI의 핵심**적인 부분은 바로 이 **Build와 Test의 자동화**이다.

실제 개발팀에서는 Merge가 되기 이전 PR이 오면 코드 리뷰 과정을 거친다.

-
코드리뷰가 정상적으로 통과되면 자동으로 만들어놓은 CI Script가 실행된다.
- 추가된 코드와 함께 새롭게 Build 된다.
- 동작에 이상이 없는지 작성한 Test 코드가 실행되게 된다.
- 1번 예시 : Build 성공, Test 성공 ⇒ 성공!
- 2번 예시 : Build 성공, Test 실패 ⇒ 실패!
- 3번 예시 : Build 실패 ⇒ 실패!
-
Build 후 모든 Test까지 정상적으로 통과되면 Green Sign 이 나오며 배포에 반영이된다.
-
하나라도 실패한다면 Red Sign이 나오며 배포에 반영되지 못하고 문제가 발생했다고 알림을 준다.
-
Test 코드가 없으면 Merge가 안되도록 설정할 수 있다.
CI의 장점
- 주기적인 Merge로 Conflict(충돌)을 피할 수 있다.
- 시간 낭비가 없기 때문에 개발 생산성이 높게 향상된다.
- Merge 되는 모든 코드들은 자동으로 Build 되고 Test 된다.
- 코드의 결함이나 문제점을 빠르게 찾을 수 있다.
- 코드의 변경사항이 작기 때문에 버그 수정 또한 용이하다.
- 코드의 퀄리티가 향상된다.
- CI를 잘 운영하려면 새로운 코드의 Unit Test를 항상 포함한다.
- 배포 이전에 항상 Test 과정을 거치기 때문에 안정성 있는 서비스를 운영할 수 있다.
CD(Continuous Delivery, Continuous Deployment)
💡 **Continuous Delivery**와 **Continuous Deployment**는 서로 연관이 있다.
어떻게하면 배포를 자동화할 수 있을지 고민하는 단계이다.
함께 사용하는 경우가 많고, 거의 비슷하다고 보면된다.
실제로 **CD**는 통용적으로 두가지 의미 모두 포함하여 사용하는 단어이다.
Continuous Delivery(지속적 제공)

💡 CI를 통해서 주기적으로 Merge된 코드의 변경사항들이 자동으로 빌드, 테스트가 되었다면
**배포(Release)**할 준비과정을 거치고 준비된 Release가 아무런 문제가 없는지
직접 개발자 또는 검증팀(QA)이 검증한 다음 최종적으로 배포가 되어도 괜찮다고 판단되면
**수동적으로 배포하는 단계**를 Continuous Delivery 라고 한다.
Continuous Deploy(지속적 배포)

💡 Release가 준비가 되자마자 자동으로 사용자에게 배포되도록 만들 수 있다.
**모든 과정을 자동화 하는것을 Continuous Deployment** 라고 한다.
최종 배포 단계의 자동화 여부에 따라서 Continuous Delivery와 조금 차이가 있다.
정리
- 회사별로 최종 배포단계는 수동적으로 Release 할지 자동으로 할지 여부는 다르다.
- CI/CD를 구축하였다고 해서 세부적인 단계들이 모두 똑같지는 않다.
- 즉, 어느정도 범위까지 자동화 할지의 범위는 회사마다, 개발팀마다 다르다.
CI/CD
💡 CI/CD는 분리된 개념이 아니다.
대부분의 회사에서 CI/CD 를 거쳐서 배포(Release)하기 때문에
통상적으로 CI/CD를 하나로 묶어서 말한다.
개발 프로세스(CI/CD)를 자동화하여 구축해놓은 시스템을 CI/CD Pipeline이라고 한다.
요약
- 개발자가 작은단위로 기능을 나누어서 주기적으로 Main Branch에 Merge 한다.
- 자동으로 빌드를하고 테스트 과정을 거쳐서 Release(배포) 준비를 한다.
- 수동 혹은 자동으로 최종 배포를 한다.
- 이러한 전체 과정을 CI/CD 라고 말한다.
CI/CD를 위한 다양한 툴
회사마다 다른 툴을 사용하기 때문에 어떤 툴을 사용하는지 알아보고
해당 툴에 대해서 정확하게 공부하고 사용해야 합니다.
(프로젝트 진행시 적절한 사유를 선택하여 사용하면 됩니다.)
각각의 도구들은 특정한 환경 또는 요구사항에 잘 맞을 수 있다.
아래 예시들의 장,단점은 짧게 정리한것이고 깊게 찾아보셔야 합니다.
1. Github Actions

- 장점
- Github과의 통합이 잘 되어있다.
- 무료 플랜에서 사용할 수 있다.
- 요즘 꽤 뜨고있는 방법이다. 비교적 최신 기술이다.
- 단점
- 제한된 Build Time이 존재할 수 있다.
2. Jenkins

- 장점
- 유연하고 확장성이 뛰어나다
- 다양한 플러그인이 지원된다.
- 사용자가 많음으로 커뮤니티가 활발하다.
- 단점
- 다양한 플러그인이 지원되는만큼 설정이 복잡하다.
3. Buildkite

- 장점
- 분산 빌드 시스템을 제공하여 확장성이 높다.
- 대규모 프로젝트에서도 효율적으로 적용할 수 있다.
- 자체 호스팅할 수 있다. 설정을 자유롭게 조절할 수 있다.
- CI/CD 파이프라인을 YAML로 설정하며 간단하고 유연하다.
- 단점
- 자유도가 높은만큼 설정이 복잡하다.
- 러닝커브가 큰 편이다.
- 프로젝트가 클수록 비용이 상승한다.
4. Bitbucket

- 장점
- Buitbucket Pipelines를 가지고 있다. 통합이 잘되어 CI/CD 파이프라인이 함께 제공되어 설정이 간단
- 작은 프로젝트라면 무료로 사용이 가능하다.
- Docker를 지원한다.
- 단점
- 더 복잡하거나 커스텀된 요구사항에 대한 유연성이 부족할 수 있다.
5. Circleci

- 장점
- 분산 환경에서 빠른 빌드 속도를 제공한다.
- YAML 파일을 사용하여 쉽게 빌드하여 Pipeline을 구축할 수 있다.
- Docker Native 도커에 최적화 되어있어 빌드와 배포를 위한 컨테이너 관리가 편하다.
- 단점
- 무료 요금제를 사용하면 리소스의 제한이 있다.
- 무료 요금제 사용시 병렬 빌드가 제한적이다.
6. GitLab CI/CD

- 장점
- GitLab과 통합되어 Repository, Issue, Code Review, CI/CD 가 한곳에서 관리된다.
- 무료 오픈소스이다.
- GitLab CE를 사용하면 자체 호스팅이 가능하다.
- 자유로운 환경설정이 가능하다.
- 단점
정리
CI
코드 단위를 잘게 나누어 ( 의미있는 Git 사용 , Git Convention, Git Branch 관리전략)
빈번하게 Merge한다.
Build, Test(테스트 코드)를 자동화한다. → Release를 위한 준비
CD
Build된 파일을 실제 운영환경에 배포한다.
1. 수동으로 배포한다.
2. 자동으로 배포한다.
실제 사용하는 방법 : 수동으로 체크해서 자동으로 배포되도록 만든다.
오늘의 코드 카타
class Solution {
public int solution(int[] box, int n) {
int a = box[0] / n;
int b = box[1] / n;
int c = box[2] / n;
int answer = a * b * c;
return answer;
}
}
public class Main {
public static void main(String[] args) {
Solution solution = new Solution();
int[] a1 = {1, 1, 1};
int[] a2 = {10, 8, 6};
System.out.println(solution.solution(a1, 1));
System.out.println(solution.solution(a2, 3));
}
}
주사위의 개수