[TIL] CI / CD

송인선·2022년 10월 12일

TIL

목록 보기

15/16

Today I Learn...

개발 프로세스

💡 개발 프로세스의 발전

📌 개발 프로세스

소프트웨어 개발 프로세스 모델은 소프트웨어 개발 생명주기(SDLC, Software Develpment Life Cycle) 기반으로 만들어졌다.

요구분석 및 시스템 명세 작성 ➡️ 설계 ➡️ 구현 ➡️ 테스트 ➡️ 배포 및 유지보수

실제 개발에 착수하는 단계는 구현부터!

📌 전통적인 개발 프로세스

워터폴(Waterfall) 방식 :
폭포와 같이 한 방향으로만 프로세스가 진행되는 개발 과정

워터폴의 기본 모델 :
요구분석 ➡️ 설계 ➡️ 개발 ➡️ 테스트 ➡️ 유지보수
유지보수까지 끝나면 다시 처음의 단계로 돌아가 시작한다.

전통적인 개발 프로세스의 특징 :

출시 기한을 정해놓고 순차적으로 어플리케이션(소프트웨어)을 완성해 배포하기 때문에 유저에게 전달되는 시간이 오래 걸림...
실제 개발된 화면을 확인할 수 있을 때는 이미 많은 단계가 지나온 시점이라, 버그나 수정 사항이 생기면 다시 처음으로 돌아가 수정되기 때문에 일정과 비용 등 많은 부분에서 에로 사항이 생긴다.

➡️ 출시 시점에 소프트웨어의 신뢰성 및 안정성을 보장 받기가 힘들며, 배포 직후에도 수많은 버그를 마주하게 될 가능성 존재

소프트웨어의 안정성 개선을 위해 테스트 단계에 다양한 테스트들을 도입하기도 한다.
- 시스템 테스트 : 모든 모듈을 통합한 후 최종적으로 완성된 시스템이 요구사항을 만족하는지 확인. 요구사항을 만족하지 않는다면 다시 요구분석 단계로 돌아가 새로 개발을 하기도 한다.
- 알파 테스트 : 완전히 개발된 시스템을 개발 현장에서 비공개로 테스트하는 것으로, 주문형 제품의 경우 개발진과 클라이언트 사이에서 동의가 이루어질 때까지 수행. 대기업의 경우 이 업무를 주로 하는 전문 QA팀이 존재함.
- 베타 테스트 : 고객의 실제 사용 환경에서 수행되는 테스트로, 미리 선별된 유저들이 해당 제품을 사용해 봄. 이 과정에서 에러나 버그가 발견되면 수정하는 식으로 진행.
등등...

전통적인 개발 프로세스의 한계 :

다양한 테스트 방식을 도입했음에도 사용자가 항상 최신 상태로 업데이트를 해줘야 하고, 버그 수정(patch)된 버전을 유저에게 즉각적으로 전달하기가 어렵다.

📌 모던 개발 프로세스

애자일(Asile) 방식 :
스프린트(sprint) 라고 불리는 짧은 주기의 개발 사이클을 계속해서 반복

모던 개발 프로세스의 특징 :

요구사항이 변하는 것을 당연한 전제로 한다.
계획에 의존하여 형식적인 절차를 끝까지 따라야 하고 중간에 뒤로 회귀할 수 없는 전통적인 개발 프로세스보다는 훨씬 효율적으로 개발 가능
애자일 개발 프로세스를 잘 사용하면 빠르게 문제를 해결해 하루에도 여러 번의 릴리즈가 가능

➡️ 이러한 방식은 SaaS(Software as a Service, 서비스형 소프트웨어) 를 개발하는 데에 적합

SaaS란 ❓
SaaS는 클라우드 서비스의 한 방식으로, 브라우저에 접속하기만 해도 새 버전을 즉시 사용할 수 있다.
사용자 업데이트에 대한 걱정에서 벗어나며, 하루에 여러 번, 빠른 속도의 릴리즈(배포)가 가능하다!

💡 DevOps

📌 DevOps

DevOps는 소프트웨어 개발(Development)과 IT 운영(Operations)의 합성어

전통적인 IT 조직 구조
➡️ 개발팀(Dev)과 운영팀(Ops)이 소프트웨어의 개발과 관리 및 유지보수를 담당

개발팀 : 잦은 업데이트를 통해 제품에 변화를 만든다.
운영팀 : 서비스의 구성의 변경을 최소화해 안정성을 확보한다.
두 팀간의 갈등이 빚어지는 구조는 현대 IT 시장에는 맞지 않을 뿐더러, 제품의 릴리즈 주기를 길어지게 만들기도 한다.

그래서 나타난 것이 DevOps. 소프트웨어를 자주, 빨리 그리고 안전하게 배포하는 것을 목표로 하며, 그렇기 때문에 애자일 개발 프로세스를 기반으로 한 것이다!

DevOps 문화

기능의 분리가 아닌 교차되어 어느 누구라도 해당 업무를 수행할 수 있는 것
DevOps는 일종의 개발 문화
만약 서비스가 중단된다면, 누구든지 문제점을 진단하고 시스템을 복구하여 운영할 수 있는 절차를 알고 있어야 한다.
이를 위한 기술과 지식이 제공되기 위해서 훈련과 효과적인 협업체계를 마련하는 것이 매우 중요하다.

DevOps 특징

DevOps는 개발에서 운영까지 하나의 통합된 프로세스로 묶어내고 사용하는 툴과 시스템을 표준화하여 의사소통의 효율성을 확보하고 일련의 작업들을 자동화한다.
코드 통합, 테스트, 릴리즈, 배포 과정을 자동화 시키는 것
지속적 통합 및 배포(CI/CD)는 DevOps의 핵심 원칙이라고 할 수 있다.

DevOps 사례

실제 인터넷 상에서 스트리밍이나 사진과 같은 엄청난 트래픽과 다양한 사용자 환경 및 요구에 빠르게 대응하기 위해 배포가 많은 기업 중에 Devops를 활용하여 성공한 기업이 여럿 있다.

➡️ Netflix, Flickr, Spotify 등...

CI/CD

💡 CI/CD

📌 CI/CD란

CI/CD의 단계

지속적 통합(Continuous Integration, CI)
개발자를 위한 자동화 프로세스. Code - Build - Test 단계

Code : 개발자가 코드를 원격 코드 저장소 (github 등)에 push하는 단계
Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계
Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는 지 확인하는 과정

지속적 통합은 모든 코드 변화를 하나의 리포지토리에서 관리하는 것 부터 시작.
➡️ 모든 개발팀이 코드의 변화를 확인할 수 있기 때문에, 투명하게 문제점을 파악할 수 있다.
➡️ 잦은 풀 리퀘스트(pull request)와 머지(merge)로 코드를 자주 통합. 이 때, 기본적인 테스트도 작동시킬 수 있다.
➡️ 이렇게 지속적 통합을 통해 개발팀은 각자 개발한 코드를 이른 시점에 자주 합치고 자주 테스트 해볼 수 있다.(보안 이슈, 에러 등을 쉽게 파악 가능)

지속적 배포(Continuous Delivery/Deployment, CD)
지속적인 서비스 제공 및 지속적인 배포를 의미. Release - Deploy - Operate 단계

Release : 배포 가능한 소프트웨어 패키지를 작성합니다.
Deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출합니다. 실질적인 배포 부분입니다.
Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지합니다.

➡️ 프로덕션 준비가 완료된 빌드를 코드 리포지토리에 자동으로 릴리스하는 지속적 제공의 확장된 형태인 지속적 배포는 애플리케이션을 프로덕션으로 릴리스하는 작업을 자동화한다.

➡️ 최근에는 클라우드 기술 발전과 맞물려 지속적 통합과 지속적 배포가 빠른 속도로 진행되면서 CI/CD를 하나로 묶어서 다루는 경우가 점차 증가하고 있다.

➡️ 지속적 배포의 가장 흔한 사례가 Github Page

CI/CD의 영역

CI/CD는 파이프라인으로 표현되는 실제 프로세스를 의미하고, 애플리케이션 개발에 지속적인 자동화 및 지속적인 모니터링을 추가하는 것을 의미
이 용어는 사례별로 CI/CD 파이프라인에 구현된 자동화 수준 정도에 따라 그 의미가 달라진다.

💡 CI/CD 파이프라인

📌 배포 자동화

배포 자동화 :
한 번의 클릭 혹은 명령어 입력을 통해 전체 배포 과정을 자동으로 진행하는 것

배포 자동화가 왜 필요할까 ❓

이유 1️⃣ 수동적이고 반복적인 배포 과정을 자동화함으로써 시간이 절약된다!
이유 2️⃣ 휴먼 에러(Human Error)를 방지할 수 있다!
(휴먼 에러: 사람이 수동적으로 배포 과정을 진행하는 중에 생기는 실수들)

📌 CI/CD 파이프라인

CI/CD 파이프라인 :
빌드-테스트-릴리즈-배포 과정을 자동화시키는 방법

➡️ 자동화를 하는 부분은 보통 코드가 빌드되면서 최종적으로 배포가 되는 단계까지임.
이 부분을 지속적인 통합 및 배포를 위하여 일련의 자동화 단계로 만드는데, 이것을 파이프라인을 구축한다고 표현한다.

📌 CI/CD 파이프라인을 구성하는 기본 단계와 수행 작업

배포에서 파이프라인(Pipeline) :
소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조.

파이프라인은 전체 배포 과정을 여러 단계(Stages)로 분리한다.
각 단계는 파이프라인 안에서 순차적으로 실행되며, 각 단계마다 주어진 작업(Actions)들을 수행하게 된다.
파이프라인을 여러 단계로 분리할 때, 대표적으로 쓰이는 세 가지 단계가 존재한다.
- Source 단계: 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행
- Build 단계: Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공한다. 또한 Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행
- Deploy 단계: Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행

📌 CI/CD 파이프라인 구성 요소 및 장점

빌드 (소프트웨어 컴파일)
테스트 (호환성 및 오류 검사)
릴리스 (버전 제어 저장소의 애플리케이션 업데이트)
배포 (개발에서 프로덕션 환경으로의 변환)
규정 준수 및 유효성 검사
로 이루어져 있으며, 이 과정이 실무에서는 반복적인 프로세스이기 때문에 이 부분을 일련의 자동화 단계로 만든다고 볼 수 있다.

➡️ 이렇게 구축된 파이프라인은 최신 버전의 소프트웨어 애플리케이션을 업데이트하고 제공하려는 일련의 처리 단계에 걸리는 시간을 안정적이며 효과적으로 줄여주고 CI/CD 인프라와의 호환성과 효율성을 높여준다.

Github Action

📌 Github Actions란?

GitHub Actions는 Github가 공식적으로 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼

레포지토리에서 Pull Request 나 push 같은 이벤트를 트리거로 GitHub 작업 워크플로(Workflow) 를 구성할 수 있다. 워크플로는 하나 이상의 작업이 실행되는 자동화 프로세스로, 각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행된다.
워크플로는 .yml (혹은 .yaml ) 파일에 의해 구성되며, 테스트, 배포 등 기능에 따라 여러개의 워크플로도 만들 수 있다.
(생성된 워크플로는 .github/workflows 디렉토리 이하에 위치)
비공개 레포지토리의 경우 Github Actions가 작동할 때의 용량과 시간이 제한되어있으며 공개 레포지토리는 무료로 사용 가능하다.

💡 YAML

📌 YAML 이란?

Yet Another Markup Language의 약자로, 사람이 읽을 수 있는 데이터 직렬화 언어를 의미

(여기서 YAML을 YAML ain’t markup language(재귀 약어)로 생각하는 사람도 있다. 후자는 YAML이 문서가 아닌 데이터용임을 강조하는 말이라고 생각하자 ㅎㅎ)

파일로 작성시 확장자는 .yaml 혹은 .yml 확장자를 가진다.
YAML은 사람이 읽을 수 있고 이해하기 쉬워 프로그래밍 언어 중에서도 인기가 높다.
YAML은 다른 프로그래밍 언어와 함께 사용할 수 있고, 그 유연성과 접근성으로 인해 자동화 프로세스를 생성하는 데에도 사용된다.

📌 JSON vs YAML

name: Bare Minimum Requirements
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Bare Minimum Requirements
        uses: actions/setup-node@v1
        with:
          node-version: '16'
      - run: npm install
      - run: npm test

[Github actions 설정을 위해 작성된 YAML 파일]

{
  "squadName": "Super hero squad",
  "homeTown": "Metro City",
  "formed": 2016,
  "secretBase": "Super tower",
  "active": true,
  "members": [
    {
      "name": "Molecule Man",
      "age": 29,
      "secretIdentity": "Dan Jukes",
      "powers": [
        "Radiation resistance",
        "Turning tiny",
        "Radiation blast"
      ]
    }
  ]
}

[MDN의 JSON 파일]

JSON 파일과 YAML 파일의 같은 점 ❗️

key-value 형태로 작성된 파일이며, 계층 구조를 가지는 것은 동일

JSON 파일과 YAML 파일의 다른 점 ❗️

1️⃣ YAML 파일은 "" (큰따옴표, double quotation marks) 없이 문자열 작성이 가능해, 설정을 위한 스펙이나 프로퍼티 값 등이 JSON 파일에 비해 보기 쉽다.

2️⃣ JSON 파일처럼 {} 형태로 감싸줄 필요도 없기 때문에 스코프의 압박(잘못 쓰면 일일이 어디가 처음이고 끝인지 찾아야 하는 등)에서 벗어날 수도 있다.

3️⃣ YAML 파일은 JSON 파일과 다르게 주석을 작성할 수 있기에 커뮤니케이션 하기가 훨씬 수월하다.

4️⃣ YAML은 JSON의 상위 호환 격이므로, 기존 json문서를 그대로 yaml파일로 사용하거나 원하는 부분만 손볼 수 있다. 반대로 yaml을 json으로 변환해 사용할 수도 있다는 점이 장점으로 작용한다.

송인선

캣닙같은 마성의 개발자

이전 포스트

[TIL] 최적화 Optimization

다음 포스트