[지속적 통합] 01. CI/CD 리뷰

# 학습 목표

• 지속적 통합의 필요성을 설명할 수 있다.
  • 지속적 통합 개념이 나오게 된 배경을 이해할 수 있다.
  • 지속적 통합의 장점을 설명할 수 있다.
  • 지속적 통합의 원칙을 이해할 수 있다.
• 빌드/테스트의 개념을 이해할 수 있다.
  • 테스트 주도 개발(TDD)에 대한 정의와 필요성을 설명할 수 있다.
  • 테스트 주도 개발(TDD) 사이클을 설명할 수 있다.
  • 테스트의 종류 (단위 테스트, 통합 테스트, E2E 테스트)를 설명할 수 있다.
• 릴리스의 개념을 이해할 수 있다.
• CI 도구(여기서는 GitHub Action)를 이용하여 지속적 통합이 이루어지는 과정을 직접 구현할 수 있다
• 다양한 CI 도구의 차이점을 이해할 수 있다.
• 코드와 환경 변수를 분리해야 하는 이유를 설명할 수 있다.

 

---

# 학습 내용

1.  CI/CD 파이프라인

서비스가 사용자에게 도달하기까지

- 전통적인 SW 전달 방식과 클라우드 서비스 전달 방식의 비교

 

전통적인 소프트웨어 전달 방식

- 폭포수 모델

- 출시 기한을 정해놓고 소프트웨어를 완성

 

문제점

- 출시 시점에 소프트웨어의 신뢰성, 안정성 보장할 수 없음

- 출시를 약속하고 확인했을 때 산더미처럼 쌓여있는 버그

 

소프트웨어 안정성 개선을 위한 노력

- 베타 버전 등을 통한 테스트

 

특징

- 사용자가 항상 최신 상태로 업데이트해야 함

- 버그 수정(patch)을 사용자에게 전달하기 매우 어려움

 > 몇몇 소프트웨어는 지속적 전달을 위해 자동 업데이트 도입

- 여전히 모바일 애플리케이션이 사용하는 전달 방식

 

클라우드 서비스의 전달 방식

- 애자일 모델

- 고객의 요구에 민첩하게 대응하여 지속적 전달

 

SaaS Softeware as a Service

- 서비스로서의 소프트웨어

- 브라우저에 접속하기만 해도, 새 버전을 즉시 사용할 수 있는 매일 매일 진화하는 SW

 

장점

- 베타 버전 등을 통한 테스트

- 사용자 업데이트에 대한 걱정에서 자유로움

- 하루에 여러 번 릴리즈가 가능 -> 빠른 문제 해결

- 다양한 배포 방식을 적용하거나 A/B 테스트가 가능

- 빠른 배포를 보장

∴ 이를 달성하기 위해 "전달 워크 플로"가 수립되어야 하며, "자동화"가 필수적

 

전달/배포 파이프라인 구성

출처 : 코드스테이츠 데브옵스 부트캠프 과정

 

서비스 전달 관점에서의 devOps의 역할

- 서비스 전달/배포 Workflow를 구성할 수 있어야 함

 

CI/CD 파이프라인과 Stage : 지속적 통합/지속적 전달

CI/CD 파이프라인: 지속적 배포(Continuous Deployment) = 지속적 통합 + 지속적 전달

 

지속적 통합 (Continuous Integration)

지속적 통합의 필요성

- 버그의 조기 발견 가능

- 테스트 완료 코드에 대해 빠른 전달 가능

- 지속적 배포를 가능하게 함

 

지속적 전달(Continuous Delivery)

클라우드 서비스의 지속적 전달

 

2. 유용한 CI 도구들

Jenkins

- Jenkins는 오픈소스 자동화 서버로 빌드, 테스트, 배포와 같은 소프트웨어 개발의 일부분을 자동화하는 데 도움을 주며, 지속적 통합과 지속적 배포 지원

- 서버 기반의 시스템이며 Git과 같은 버전 관리 시스템을 지원

- 또한 쉘 스크립트를 실행 가능

 

특징

- 설치형: 별도의 서버가 필요

- 다양한 플러그인을 활용 가능

- 쿠버네티스, Docker 등과 호환

- 다양한 운영체제에서 사용 가능

 

Travis CI

- Travis CI는 호스트형(hosted) 배포 자동화 서비스

- GitHub 및 Bitbucket 등에서 호스팅되는 소프트웨어 프로젝트를 빌드하고 테스트하는 데 사용

 

특징

- 클라우드 서비스(SasS) 형태로 사용 가능

- Travis 자체에서 호스팅을 해주기 때문에 관리적인 측면에서 편리

- Clojure, Erlang, Groovy Haskell, Java, JavaScirpt, Node.js, Perl PHP, Rython, Ruby 등의 다양한 언어를 지원

 

GitHub Action

특징

- GitHub 저장소를 기반으로 소프트웨어 개발 Workflow를 자동화할 수 있는 툴

- GitHub 마켓 플레이스를 통해 여러 사람이 공유한 Workflow를 찾을 수 있으며, 자신이 직접 만들어 공유 가능

- 공개 저장소를 무료로 사용할 수 있으며, 비공개 저장소 같은 경우 무료 사용량 이후에 요금이 부과됨

- 한 달에 500MB 스토리지와 실행 시간 2,000분(minute)까지 제공

 

레퍼런스

Learn GitHub Actions - GitHub Docs

 

GitHub Action이 다른 CI 도구에 비해 갖는 장점 (출처: 챗 GPT)

• 통합된 개발 플랫폼: GitHub Action은 GitHub의 통합된 개발 플랫폼에 내장되어 있으므로, 소스 코드 관리, 이슈 트래킹, 코드 리뷰 등 개발 프로세스 전반에 걸쳐 통합된 경험을 제공
• 사용이 간편하고 직관적: GitHub Action은 YAML 구문을 사용하여 구성하므로, 다른 CI 도구에 비해 구성이 더욱 쉽고 직관적
• 다양한 액션 라이브러리: GitHub Action에는 다양한 액션 라이브러리가 포함되어 있어서, 필요한 작업을 쉽게 구성 가능
• 커뮤니티 기반 지원: GitHub Action은 GitHub 커뮤니티에 기반하여 개발되고 유지보수 되므로 사용자는 커뮤니티의 다양한 지원 가능
• 다양한 통합: GitHub Action은 다양한 플랫폼과 도구들과의 통합을 지원(ex. AWS, Google Cloud, Docker, Slack, Jira 등 다양한 서비스와 연동하여 사용 가능)
• 무료로 사용 가능: GitHub Action은 무료로 사용할 수 있으며, 일부 유료 기능도 존재하지만 저렴

 

3. 빌드와 언어별 빌드 도구

빌드

- 프로그램의 소스 코드를 독립적인 아티팩트(artifact)로 변환하는 과정

- 아티팩트 그 자체로도 실행이 가능하며, 대체로 런타임(소프트웨어 실행 환경)이 필요한 경우가 많음

 

아티팩트

- 프로그램 아티팩트는 소프트웨어 개발 프로세스에서 생성되는 모든 산출물

- 요구 사항 명세, 설계 문서, 코드, 테스트 계획 및 결과, 문서 등을 포함

- 각 아티팩트는 프로젝트의 단계별 목표를 달성하는 데 도움이되며, 소프트웨어 개발 과정에서 필요한 모든 정보를 포함

- 소프트웨어 개발자, 테스터, 관리자, 고객 등 다양한 이해 관계자 간의 의사 소통을 지원하는 데 중요한 역할 수행

 

프레임워크

- 오로지 빌드만을 위한 도구도 많지만, 대부분의 경우 어떤 언어나 프레임워크를 선택하느냐에 따라 빌드 도구가 정해지기 마련

- 프레임워크는 소프트웨어 개발을 쉽게 만들어주기 위해 필요한 도구, 규약의 집합체

- 프레임워크 없이 모든 코드를 작성하는 것도 가능하지만, 프레임워크를 통해 만들고자 하는 소프트웨어의 기본 골격이 제공되기 때문에, 현대의 소프트웨어 개발에서는 많은 부분을 프레임워크에 의존

 

목적에 따른 프레임워크 종류

1. 백엔드 웹 애플리케이션 개발용 프레임워크

• Spring (Java, Kotlin)
• Django (Python)
• Express (JavaScript)

 

2. 프론트엔드 웹 애플리케이션 개발용 프레임워크

• React 및 관련 라이브러리 (JavaScript)
• Vue.js, Svelte (JavaScript)

 

3. 모바일 및 데스크톱 애플리케이션 개발용 프레임워크

• Flutter (Android, iOS 등)
• .NET Framework (Windows)
• Apple 운영체제 기본 Native 프레임워크 Cocoa (macOS), Cocoa Touch (iOS)
• 안드로이드 기본 Native 프레임워크 (Android)

 

대표적인 빌드 도구

JavaScript 기반의 React 생태계

- React 프레임워크를 사용하는 경우, create-react-app 또는 next.js 와 같은 프레임워크를 사용

 

프로덕션용 빌드 결과물(아티팩트) 생성 과정

1. node.js 개발 환경 준비
2. 프로젝트 폴더로 이동
   • package.json 파일이 있는지 확인
3. 의존성 (dependency) 설치
   • npm install 명령 입력
4. 빌드
   • npm run build 명령 입력
5. 빌드 결과물 확인
   • build 폴더 확인
   • React는 프론트엔드 웹 애플리케이션이므로 결과물로는 HTML, CSS, JS 파일을 포함
   • 이후 이 파일들을 nginx 등에서 정적 호스팅 가능.

- 의존성 설치 후 빌드하지 않고, 바로 애플리케이션을 실행하기 위해서는 npm run start 등의 명령어를 사용 가능

- 애플리케이션에 단위 테스트가 제공된다면, 애플리케이션의 테스트를 위해 npm run test 명령어를 사용

- 각 프로젝트에서 사용하는 package.json 파일이 어떻게 구성되어 있느냐에 따라 다를 수 있음

 

Java/Kotlin 기반의 Spring Boot 생태계 (Gradle)

- Java/Kotlin 애플리케이션을 빌드하면 JVM(자바 런타임) 위에서 실행되는 war 파일이 아티팩트로 생성

- 빌드 도구를 이용해 실행 가능

- Spring 및 Spring Boot 생태계에서는 대표적인 빌드 도구가 두 가지(maven, Gradle) 존재

 

Gradle을 이용한 프로덕션용 빌드 결과물(아티팩트) 생성 과정

1. 자바 개발 환경(JDK, OpenJDK가 대표적) 준비
2. gradle 설치
3. 프로젝트 폴더로 이동
4. 빌드
   • gradlew build 명령 입력

- 자바 애플리케이션은 실행을 위해서 빌드가 필수적

- 빌드 후에 실행을 위해서 gradlew bootRun 명령을 통해 애플리케이션의 실행

- 그밖에 gradle tasks를 이용해 gradle에서 사용할 수 있는 다양한 태스크 확인 가능

 

빌드가 필요 없는 경우

- node.js, python과 같이 소스 코드 그대로 런타임 실행할 수 있는 경우 빌드 생략 가능