CI/CD

💡 CI/CD는 무엇인가!?

• 말로만 들었던 CI/CD에 대한 개념을 확실하게 잡고 넘어가봅시다.
• CI/CD 를 구축하고 사용하는 방법보다는 왜 사용하는지에 초점

CI/CD 개요

💡 소프트웨어 개발 프로세스를 자동화하고 효율화하는 방법론. **지속적 통합(CI)**은 코드 변경 사항이 빈번하게 통합되어 빌드 및 테스트되는 것을 의미하며, **지속적 배포(CD)**는 검증된 코드 변경 사항을 자동으로 프로덕션 환경에 배포하는 것을 의미합니다. CI/CD를 통해 개발자들은 빠른 속도로 안정적인 소프트웨어를 출시하고 업데이트할 수 있습니다.

• CI(Continuous Integration) - 지속적인 통합
• CD(Continuous Delivery) - 지속적인 제공

OR

• CD(Continuous Deployment) - 지속적인 배포

CI/CD 는 왜 세상에 나오게 된걸까?

• 회사의 제품을 신속하게 출시하고 업데이트하는 것은 아주 중요한 과제입니다. 만약 내가 운영하는 서비스에 장애가 발생하거나 문제가 있는데 수정이 느리다면?

• 실제 실시간 서비스로 운영되는 온라인 게임의 경우 개발자들의 부담감이 상당했다고 합니다!
  • 위와같은 사유만으로 정년퇴직자가 없었던것은 아니지만 어느정도 영향을 주었을것이라 생각합니다.

현재는 서비스의 빠른 업데이트와 다양한 고객의 요구사항을 대응하기 위해 전 세계적으로 수많은 기업이 CI/CD를 개발 프로세스에 포함하고 있습니다. 따라서, 개발자들은 이 개념에 대한 명확한 이해가 필요합니다.

💡 비지니스 세계에서 제품을 빠르게 시장에 반영하여 시장을 선점하고 고객 요구 사항을 충족시키기 위해 CI/CD 환경을 효과적으로 활용하는 것은 아주 중요한 사항중에 하나 입니다.

CI(Continuous Integration)란?

---

💡 Bug Fix나 새로 기능들이 매일 Git과 같은 Repository에 주기적으로 빌드(Build)되고 테스트(Test)가 되어서 병합(Merge) 되는것을 뜻한다.

 

문제점 1

• 동일한 브랜치 위에서 두명의 개발자가 서로 다른 코드를 작성하고 있다가 오랜기간 후 Merge 하려고하면?
  • Conflict(충돌)이 발생하게 됩니다.
  • 서로 다른 코드의 충돌을 해결하기 위해 엄청난 노력을 해야한다.
  • 개발하는 시간보다 충돌 해결을 위해서 많은 시간을 사용하게 된다.
  • Git Conflict는 이미 겪은분들도 많이 계실거라 생각합니다.

문제점 2

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

참고

• Wikipedia - Continuous integration

Continuous integration - Wikipedia

 

• Red Hat - CI/CD Pipeline What is a CI/CD pipeline?

What is a CI/CD pipeline?

 

참고

• 위키피디아 - Extream Programming 익스트림 프로그래밍

익스트림 프로그래밍 - 위키백과, 우리 모두의 백과사전

 

• Grady Booch - Object Oriented Analysis and Design With Applications Grady Booch

Grady Booch - Wikipedia

 

1. 코드 변경사항을 주기적으로 빈번하게 병합해야 한다.

 

1. 버그를 수정하는 경우
   • 작은 단위로 작업을 나누어서 Git 메인 저장소에 효과적으로 반영한다.
   • ex) 버그에 대한 대처에 대한 수정 → method 하나 수정 후 commit push, Entity Field 하나 수정 후 commit push
2. 새로운 기능을 추가하는 경우
   • 사용자에게 배포할 수 있을 정도로 작은 단위(작은 기능 추가)로 나누어 개발하여 반영한다.
   • ex) 엑셀 다운로드 기능(method와 같이 작은 단위로 나누어서 추가하자.)을 추가했다.

정리

작성한 코드를 작은 단위로 Commit 하여 자주 Merge 하기만 하여도 Git Conflict를 최소화할 수 있다.

 

2. 빌드, 테스트의 자동화

Merge : 브랜치들의 코드를 하나로 합치는것

Build : 합쳐진 코드를 Jar 파일로 만드는것

배포 : Jar 파일을 배포하는것

• 주기적으로 코드의 변경 사항 Merge 된다면?
  1. 배포를 위해 다시 새로운 Version 으로 Build가 되어야한다.
  2. Merge 후에도 빌드가 성공적으로 되는지 확인이 되어야 한다.
  3. 새로 추가된 코드의 변경사항은 문제가 없는지 Test 해야한다.
  4. 새로 추가된 코드가 기존 코드에 문제를 발생시키지는 않는지 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가 안되도록 설정할 수 있다.
  • 물론 시간 단축을 위해 Test 코드가 없어도 Merge가 되도록 만들수는 있다.
  • 기억!

테스트 코드의 중요성을 이제 조금 더 아시겠나요 여러분..??

 

CI의 장점

1. 주기적인 Merge로 Conflict(충돌)을 피할 수 있다.
   1. 시간 낭비가 없기 때문에 개발 생산성이 높게 향상된다.
2. Merge 되는 모든 코드들은 자동으로 Build 되고 Test 된다.
   1. 코드의 결함이나 문제점을 빠르게 찾을 수 있다.
   2. 코드의 변경사항이 작기 때문에 버그 수정 또한 용이하다.
3. 코드의 퀄리티가 향상된다.
   1. CI를 잘 운영하려면 새로운 코드의 Unit Test를 항상 포함한다.
   2. 배포 이전에 항상 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와 조금 차이가 있다.

정리

1. 회사별로 최종 배포단계는 수동적으로 Release 할지 자동으로 할지 여부는 다르다.
2. CI/CD를 구축하였다고 해서 세부적인 단계들이 모두 똑같지는 않다.
3. 즉, 어느정도 범위까지 자동화 할지의 범위는 회사마다, 개발팀마다 다르다.

 

CI/CD

---

💡 CI/CD는 분리된 개념이 아니다. 대부분의 회사에서 CI/CD 를 거쳐서 배포(Release)하기 때문에 통상적으로 CI/CD를 하나로 묶어서 말한다. 개발 프로세스(CI/CD)를 자동화하여 구축해놓은 시스템을 CI/CD Pipeline이라고 한다.

요약

1. 개발자가 작은단위로 기능을 나누어서 주기적으로 Main Branch에 Merge 한다.
2. 자동으로 빌드를하고 테스트 과정을 거쳐서 Release(배포) 준비를 한다.
3. 수동 혹은 자동으로 최종 배포를 한다.
4. 이러한 전체 과정을 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. 자동으로 배포한다.

• 실제 사용하는 방법 : 수동으로 체크해서 자동으로 배포되도록 만든다.