[Deploy] CI/CD

이성은·2023년 2월 3일

1. 개발 프로세스

학습목표

개발 프로세스에 대해 이해합니다.

전통적인 개발 프로세스에 대해 이해합니다.

전통적인 개발 프로세스에 도입된 테스트들이 무엇인지 이해합니다.

모던 개발 프로세스에 대해 이해합니다.

SaaS에 대해 이해합니다.

DevOps가 무엇인지 이해합니다.

DevOps 문화가 무엇인지 이해합니다.

DevOps 특징과 사례에 대해 이해합니다.

1-1. 개발 프로세스의 발전

개발 프로세스

소프트웨어 개발 프로세스 모델은 소프트웨어 개발 생명주기(SDLC, Software Develpment Life Cycle)을 기반으로 만들어졌다.
그림 상으로는 이 단계들이 계속 꼬리를 물고 도는 순환 구조로 되어 있지만, 실제 개발 환경에서는 환경에 따라 각각의 단계가 또 세밀하게 나뉘어져 있기도 하며, 각 단계가 계속해서 반복되기도 한다.
요구분석 및 시스템 명세 작성
- 분석 단계
- 개발하고자 하는 소프트웨어의 성격을 정확히 이해하여 이를 토대로 개발 방법과 필요한 자원 및 예산 예측 후 요구명세를 작성
설계
- 앞서 정의한 기능을 실제로 수행하기 위한 방법을 논리적으로 결정
- 시스템 구조 설계
- 시스템을 구성하는 내부 프로그램이나 모듈 간의 관계와 구조를 설계
- 프로그램설계
  - 프로그램 내의 각 모듈에서의 처리 절차나 알고리즘을 설계
  - UI(User Interface) 설계
    - 사용자 인터페이스 설계로, 사용자가 시스템을 사용하기 위해 보이는 부분을 설계
- 구현
  - 실제 프로그램을 작성
  - 구조화 프로그래밍
    - 조건문, 반복문을 사용하여 프로그램을 작성하고, 순차구조, 선택구조, 반복구조의 세 가지 제어구조로 표현하며, 구조가 명확하여 정확성 검증과 테스트 및 유지보수가 쉬운 장점이 있다.
  - 모듈러 프로그래밍
    - 프로그램을 여러 개의 작은 모듈로 나누어 계층 관계로 구성하는 프로그래밍 기법으로, 모듈별로 개발과 테스트 및 유지보수 가능하며, 모듈의 재사용 가능하다는 장점이 있다.
- 테스트
  - 테스트 단계에서는 개발한 시스템이 요구사항을 만족하는지, 실행 결과가 예상한 결과와 정확하게 맞는지를 검사하고 평가하는 일련의 과정
- 배포 및 유지보수
  - 수정형 유지보수 : 사용 중에 발견한 프로그램의 오류 수정 작업을 진행
  - 적응형 유지보수 : 시스템과 관련한 환경적 변화에 적응하기 위한 재조정 작업
  - 완전형 유지보수 : 시스템의 성능을 향상하기 위한 개선 작업
  - 예방형 유지보수 : 앞으로 발생할지 모를 변경 사항을 수용하기 위한 대비 작업을 수행

전통적인 개발 프로세스

워터폴(Waterfall) 방식

유지보수까지 끝나면 다시 처음의 단계로 돌아가 시작하는 것이 가장 기본적인 모델
실제 출시 기한을 정해놓고 순차적으로 프로세스가 진행시켜 어플리케이션(소프트웨어)를 완성해 배포하기 때문에 실제로 배포되어 유저에게 전달되는 시간이 오래 걸린다.
실제 디자인 또는 개발된 화면을 시각적으로 확인할 수 있는 단계는 이미 많은 단계가 지나온 시점이기 때문에 어떤 버그나 수정 사항이 생기면 다시 처음으로 돌아가 수정되기 때문에 일정과 비용 등 많은 부분에서 에로 사항이 생기게 된다.

전통적인 소프트웨어 개발 프로세스에서는 소프트웨어의 안정성 개선을 위해 테스트 단계에 다양한 테스트들을 도입
- 시스템 테스트 : 모든 모듈을 통합한 후 최종적으로 완성된 시스템이 요구사항을 만족하는지 확인
- 알파 테스트 : 완전히 개발된 시스템을 개발 현장에서 비공개로 테스트
- 베타 테스트 : 고객의 실제 사용 환경에서 수행되는 테스트,미리 선별된 유저들이 해당 제품을 사용해 봅니다. 이 과정에서 에러나 버그가 발견되면 수정하는 식으로 진행
전통적인 개발 프로세스의 전달이 가지는 한계
- 다양한 테스트 방식을 도입했음에도 사용자가 항상 최신 상태로 업데이트를 해줘야 하고, 버그 수정(patch)된 버전을 유저에게 즉각적으로 전달하기가 어렵다.

모던 개발 프로세스

애자일(Agile) 방식
- ‘스프린트(sprint)' 라고 불리는 짧은 주기의 개발 사이클을 계속해서 반복
- 이 방식은 요구사항이 변하는 것을 당연한 전제로 두고 있다.
- 애자일 개발 프로세스를 적절히 사용하면 빠르게 문제를 해결해 하루에도 여러 번의 배포가 가능
- 이러한 방식은 SaaS(Software as a
  Service, 서비스형 소프트웨어)를 개발하는 데에 적합
SaaS란?
- SaaS는 클라우드 서비스의 한 방식으로, 브라우저에 접속하기만 해도 새 버전을 즉시 사용할 수 있는 서비스 방식
- 애플리케이션부터 서버, 가상화, 스토리지, 네트워킹까지 전부 공급자 쪽에서 관리하기 때문에 고객이 제어하거나 관리할 부분이 거의 없게 된다.

전통적인 개발 프로세스 VS 모던 개발 프로세스

1-2. DevOps

DevOps는 소프트웨어 개발(Development)과 IT 운영(Operations)의 합성어, 일종의 개발 문화
만약 서비스가 중단된다면, 누구든지 문제점을 진단하고 시스템을 복구하여 운영할 수 있는 절차를 알고 있어야 한다.
소프트웨어를 자주, 빨리 그리고 안전하게 배포하는 것을 목표로 하며, 그렇기 때문에 애자일 개발 프로세스를 기반으로 한 것

DevOps 특징

DevOps는 개발에서 운영까지 하나의 통합된 프로세스로 묶어내고 사용하는 툴과 시스템을 표준화하여 의사소통의 효율성을 확보하고 일련의 작업들을 자동화
즉 코드 통합, 테스트, 배포 과정을 자동화 시키는 것
잘 구축된 CI/CD는 애플리케이션의 배포 시간을 크게 단축시킨다.

2. CI/CD

학습목표

CI/CD 용어의 의미를 이해합니다.

CI/CD를 꾀할 수 있는 각 단계에 대해 이해합니다.

CI/CD 파이프라인이 무엇인지 이해합니다.

CI/CD 파이프라인의 구성 요소와 장점에 대해 이해합니다.

2-1. CI/CD

CI/CD란?

CI
- 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미
- CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 통합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.
CD
- 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미

CI/CD의 단계

지속적 통합(Continuous Integration, CI)

개발자를 위한 자동화 프로세스라고 볼 수 있으며,
Code - Build - Test 단계에서 꾀할 수 있다.
- Code : 개발자가 코드를 원격 코드 저장소 (Ex. github repository)에 push하는 단계
- Build : 원격 코드 저장소로부터 코드를 가져와 유닛 테스트 후 빌드하는 단계
- Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는 지 확인하는 과정
지속적 통합은 모든 코드 변화를 하나의 리포지토리에서 관리하는 것 부터 시작
- 모든 개발팀이 코드의 변화를 확인할 수 있기 때문에, 투명하게 문제점을 파악할 수 있다.
- 잦은 풀 리퀘스트(pull request)와 머지(merge)로 코드를 자주 통합
- 이렇게 지속적 통합을 통해 개발팀은 각자 개발한 코드를 이른 시점에 자주 합치고 자주 테스트 해볼 수 있다.

지속적 배포(Continuous Delivery/Deployment, CD)

지속적인 서비스 제공(Continuous Delivery) 및 지속적인 배포(Continuous Deployment)를 의미,
Release - Deploy - Operate 단계에서 꾀할 수 있다.
- Release : 배포 가능한 소프트웨어 패키지를 작성
- Deploy : 프로비저닝을 실행하고 서비스를 사용자에게 노출, 실질적인 배포 부분
- Operate : 서비스 현황을 파악하고 생길 수 있는 문제를 감지
요즘은 고객의 피드백을 빨리 받기 위해서라도, 서비스를 중단하지 않기 위해서라도 릴리즈만 잘 기록해두고 바로바로 배포하는 사례가 증가
지속적 배포의 가장 흔한 사례가 Github Page
=> 지정해둔 디렉터리에 정해진 방식에 따라 잘 커밋하기만 하면, Github Page가 알아서 해당 index.html 파일과 해당 디렉터리에 있는 파일을 잘 번들링해서 Github Page 서버에 업로드, 이렇게 자동으로 인터넷에 배포

2-2. CI/CD 파이프라인

배포 자동화

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

CI/CD 파이프라인

CI/CD 파이프라인: 진행되는 배포 과정을 자동화시키는 방법을 구축
- 자동화를 꾀하는 부분은 보통 코드가 빌드되면서 최종적으로 배포가 되는 단계까지

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

Source 단계: Source 단계에서는 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행
Build 단계: Build 단계에서는 Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공. 또한 Build 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행.
Deploy 단계: Deploy 단계에서는 Build 단계로부터 전달받은 결과물을 실제 서비스에 반영하는 작업을 수행

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

빌드 (소프트웨어 컴파일)
테스트 (호환성 및 오류 검사)
릴리스 (버전 제어 저장소의 애플리케이션 업데이트)
배포 (개발에서 프로덕션 환경으로의 변환)
규정 준수 및 유효성 검사

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

3. Github Action

Github Actions이란?

GitHub Actions는 Github가 공식적으로 제공하는 빌드, 테스트 및 배포 파이프라인을 자동화할 수 있는 CI/CD 플랫폼
레포지토리에서 Pull Request 나 push 같은 이벤트를 트리거로 GitHub 작업 워크플로(Workflow)를 구성
워크플로는 하나 이상의 작업이 실행되는 자동화 프로세스로, 각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행
워크플로는 .yml (혹은 .yaml ) 파일에 의해 구성되며, 테스트, 배포 등 기능에 따라 여러개의 워크플로도 만들 수 있다. => 생성된 워크플로는 .github/workflows 디렉토리 이하에 위치

YAML

YAML(Yet Another Markup Language) 이란?

사람이 읽을 수 있는 데이터 직렬화 언어
확장자는 .yaml 혹은 .yml 확장자

JSON vs YAML

YAML은 JSON의 상위 호환 격
JSON 파일과 YAML 파일은 key-value 형태로 작성된 파일이며, 계층 구조를 가지는 것에는 동일
YAML 파일은 "" (큰따옴표, double quotation marks) 없이 문자열 작성이 가능해, 설정을 위한 스펙이나 프로퍼티 값 등이 JSON 파일에 비해 한 눈에 들어온다는 점이 있다.
또한 JSON 파일처럼 {} 형태로 감싸줄 필요도 없기 때문에 스코프의 압박(잘못 쓰면 일일이 어디가 처음이고 끝인지 찾아야 하는 등)에서 벗어날 수도 있다.
YAML 파일은 JSON 파일과 다르게 주석을 작성할 수 있다는 점도 굉장한 이점으로 작용

YAML 문법

주석, 문서의 시작과 끝
- # : 주석
- --- : 문서의 시작 (선택사항)
- ... : 문서의 끝 (선택사항)
- 들여쓰기 : 들여쓰기는 기본적으로 2칸 또는 4칸을 지원, 탭 키가 아닌 스페이스 키로 들여써야 한다.
기본 표현
- key: value 이며, : 다음에는 무조건 공백 문자가 와야한다.
자료형
- int, string, boolean, 리스트, 매핑을 지원
  -int와 string 타입은 스칼라(Scalar)라 부르고, 배열 혹은 리스트는 시퀀스(Sequence)라 부른다. 매핑에는 기본 표현인 key-value쌍 및 hash, dictionary가 포함

객체
- key 작성 후 두 칸을 들여써서 key-value 형태로 작성을 해주거나, key를 작성 후 중괄호({})로 한 번 묶고 key-value 형태로 작성

Text
- 줄바꿈 표현(|)과 줄바꿈 무시 표현(>)

문자열 따옴표
- key-value 쌍에서 value에 :가 들어간 경우는 반드시 따옴표가 필요

과제 - Github Action 실습

Github Action 튜토리얼

이번 튜토리얼에서는 나만의 아고라 스테이츠 서버 레퍼런스와 Github Action을 이용하여 진행
자신의 깃허브 계정에 새로운 리포지토리를 만든다.
=> public으로 만들어야 Github Action을 무료
새로운 리포지토리에 나만의 아고라 스테이츠 서버 레퍼런스 코드를 git clone해서 새로운 리포지토리를 원격 리포지토리로 등록하고, 코드를 push
=> 나만의 아고라 스테이츠 서버 레퍼런스 코드가 remote --v이 코드스테이츠이기때문에 나의 원격 리포지토리로 등록

4. action탭으로 이동해서 Github Action이 활성화되었는지 확인

5. 리포지토리를 push하기만 했는데, 왜 작동했을까?

=> npm install은 빌드를 위한 준비과정,
Node.js로 만든 서버 애플리케이션은 npm으로 관련 오픈소스를 모두 깔끔하게 설치해야 작동하기 때문
=> npm test는 유닛 테스트 과정. 작성한 코드가 요구사항 충족을 위한 최소한의 조건을 만족했는지 확인

Github Action 실습( 나만의 아고라 스테이츠 서버의 클라이언트 부분을 S3로 배포 )

나만의 아고라 스테이츠 서버파일이 있는 내 깃허브 새로운 리파지토리에 setting => Secrets and variables => Action 들어가서
New repository secret를 선택하여 AWS KEY를 등록한다.

AWS KEY를 등록시에 Name을 작성할 yml파일에 env에 설정한 변수대로 적어줘야 한다.
여기서는 AWS KEY가 두개이고, 두개의 Name은 AWS_ACCESS_KEY_ID과 AWS_SECRET_ACCESS_KEY으로 등록해야 한다.
새로운 리파지토리에 push한 나만의 아고라 스테이츠 서버를 git clone후 vs실행후 .github/workflows/client.yml 작성

# .github/workflows/client.yml
name: client
on:
  push:
    branches:
      - reference
jobs:
  build:
    runs-on: ubuntu-20.04
    steps:
      - name: Checkout source code.
        uses: actions/checkout@v2
      - name: Install dependencies
        run: npm install
        working-directory: ./my-agora-states-client
      - name: Build
        run: npm run build
        working-directory: ./my-agora-states-client
      - name: SHOW AWS CLI VERSION
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_EC2_METADATA_DISABLED: true
        run: |
          aws --version
      - name: Sync Bucket
        env:
          AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
          AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          AWS_EC2_METADATA_DISABLED: true
        run: |
          aws s3 sync \
            --region ap-northeast-2 \
            build s3://fe-69-tjddmssl-s3 \
            --delete
        working-directory: ./my-agora-states-client

workflow 설정시 제일 중요한건 actions/checkout 을 꼭 지정해야한다. => 하지 않는다면 해당 working-directory를 읽지 못하고 그냥 종료

aws --version
$ aws --version
command not found: aws
=>'aws --version' 명령이 설치한 버전과 다른 버전을 반환함
=> AWS CLI를 처음 설치하거나 업데이트한 후 aws 명령을 찾을 수 없는 경우 PATH 업데이트를 인식하도록 터미널을 다시 시작해야 할 수 있다.
=> AWS CLI를 처음 설치하거나 업데이트한 후 aws 명령을 찾을 수 없다면 완전히 설치되지 않았을 수 있다.
=> 설치하는 동안 운영 체제 PATH가 업데이트되지 않음

AWS CLI 오류 문제 해결
https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/cli-chap-troubleshooting.html

aws s3 sync

객체 동기화

s3 sync 명령은 버킷과 디렉터리의 콘텐츠 또는 두 버킷의 콘텐츠를 동기화

--delete 옵션을 제공하여 원본에 없는 파일이나 객체를 대상에서 제거할 수도 있다.
aws s3 sync <source> <target> [--options]
AWS CLI에서 Amazon S3 사용
https://docs.aws.amazon.com/ko_kr/cli/latest/userguide/cli-services-s3.html

깃헙 액션 시크릿 정하기로 깃헙 액션에서 AWS 시크릿을 넣기
https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-a-repository

내 리파지토리에 add ., commit후 push

client파일만 빌드후 배포할꺼지만 전체 파일을 add ., commit후 push해야 한다.
전체파일을 해도 yml파일에 working-directory: ./my-agora-states-client을 적어줬기 때문에 client만 빌드 배포됀다.