CI / CD

개발 프로세스

개발 프로세스,

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

요구사항분석 -> 설계 -> 구현 -> 테스트 -> 배포 및 유지보수

전통적인 개발 프로세스 → 워터폴(Waterfall) 방식 (“폭포수 개발 방식”)

전통적인 소프트웨어 개발 프로세스에서는 소프트웨어의 안정성 개선을 위해 테스트 단계에 다양한 테스트들을 도입하기도 합니다.

• 시스템 테스트 : 모든 모듈을 통합한 후 최종적으로 완성된 시스템이 요구사항을 만족하는지 확인합니다. 요구사항을 만족하지 않는다면 다시 요구분석 단계로 돌아가 새로 개발을 하기도 합니다.
• 알파 테스트 : 완전히 개발된 시스템을 개발 현장에서 비공개로 테스트하는 것으로, 주문형 제품의 경우 개발진과 클라이언트 사이에서 동의가 이루어질 때까지 수행됩니다. 
• 베타 테스트 : 고객의 실제 사용 환경에서 수행되는 테스트로, 미리 선별된 유저들이 해당 제품을 사용해 봅니다.

 

전통적인 개발 방식의 한계를 극복하고자 나타난 것 애자일(Agile) 방식

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

이러한 방식은 SaaS(Software as a Service, 서비스형 소프트웨어)를 개발하는 데에 적합[브라우저에 접속하기만 해도 새 버전을 즉시 사용할 수 있는 서비스 방식]

 

 

DevOps

Dev(개발팀) Ops(운영팀)

	Dev(개발팀)	Ops(운영팀)
특징	- 잦은 배포 및 업데이트 - 애플리케이션을 통해 새로운 기능(리소스)제공	- 프로덕션 앱의 안정성 확보 - 인프라 관리 - 모니터링 및 제어

• 애플리케이션을 통해 새로운 기능(리소스)제공 | - 프로덕션 앱의 안정성 확보
• 인프라 관리
• 모니터링 및 제어 |

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

소프트웨어를 자주, 빨리 그리고 안전하게 배포하는 것을 목표로 하며, 그렇기 때문에 애자일 개발 프로세스를 기반으로 한 것이라고 볼 수 있습니다.

 

DevOps 특징

DevOps는 개발에서 운영까지 하나의 통합된 프로세스로 묶어냄.

사용하는 툴과 시스템을 표준화하여 의사소통의 효율성을 확보하고 일련의 작업들을 자동화.

즉 코드 통합, 테스트, 배포 과정을 자동화 시키는 것.

지속적으로 유지되어야 할 필요가 있는데,

**지속적 통합 및 배포(CI/CD)**라고 하며 DevOps의 핵심 원칙.

잘 구축된 CI/CD는 애플리케이션의 배포 시간을 크게 단축.

 

 

CI/CD

💡 "CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미

💡 "CD"는 지속적인 서비스 제공(Continuous Delivery) 또는 지속적인 배포(Continuous Deployment)의미

 

지속적 통합(Continuous Integration, CI)

개발자를 위한 자동화 프로세스라고 볼 수 있으며, Code - Build - Test 단계에서 꾀할 수 있습니다.

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

 

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

지속적인 서비스 제공(Continuous Delivery) 및 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용됩니다. 이 부분은 Release - Deploy - Operate 단계에서 꾀할 수 있습니다.

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

 

CI/CD 파이프라인

수없이 진행되는 배포 과정을 자동화시키는 방법을 구축하게 되는데, 그것을 CI/CD 파이프라인

 

[배포 과정]

개발자가 코드를 원격 저장소에 올리면, 그 코드가 빌드 및 테스트와 릴리즈를 거쳐 배포 서버로 전달 된다.

배포 서버에 도달한 빌드된 코드는 애플리케이션 서버로 최종 배포가 완료.

그 결과물을 유저가 직접 확인하게 되는 것 이다.

여기서 자동화를 꾀하는 부분은 보통 코드가 빌드되면서 최종적으로 배포가 되는 단계까지입니다.

이 부분을 지속적인 통합 및 배포를 위하여 일련의 자동화 단계로 만드는데, 이것을 파이프라인을 구축한다고 표현합니다.

 

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

 

Github Actions이란?

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

 

레포지토리에서 Pull Request 나 push 같은 이벤트를 트리거로 GitHub 작업 워크플로(Workflow)를 구성할 수 있다.

워크플로는 하나 이상의 작업이 실행되는 자동화 프로세스로, 각 작업은 자체 가상 머신 또는 컨테이너 내부에서 실행됩니다.

워크플로는 .yml (혹은 .yaml ) 파일에 의해 구성되며, 테스트, 배포 등 기능에 따라 여러개의 워크플로도 만들 수 있습니다.

생성된 워크플로는 .github/workflows 디렉토리 이하에 위치.

비공개 레포지토리의 경우 Github Actions가 작동할 때의 용량과 시간이 제한되어있으며

공개 레포지토리는 무료로 사용 가능.

 

 

YAML 이란?

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

JSON 파일과 YAML 파일은 key-value 형태로 작성된 파일

계층 구조를 가지는 것에는 동일

그러나 YAML 파일은 "" (큰따옴표, double quotation marks) 없이 문자열 작성이 가능해,

설정을 위한 스펙이나 프로퍼티 값 등이 JSON 파일에 비해 한 눈에 들어온다는 점

또한 JSON 파일처럼 {} 형태로 감싸줄 필요도 없기 때문에 스코프의 압박에서 벗어날 수도 있다.

게다가 YAML 파일은 JSON 파일과 다르게

주석(#)을 작성할 수 있다는 점도 굉장한 이점으로 작용

YAML은 JSON의 상위 호환 격이므로,

기존 json문서를 그대로 yaml파일로 사용하거나 원하는 부분만 손볼 수 있다.

반대로 yaml을 json으로 변환해 사용할 수도 있다는 점이 장점으로 작용한다.

 

 

Github Actions를 통한 클라이언트 배포

Github Action Key

Github Action에 민감한 정보를(ex. AWS CLI KEY) 저장할 때, Secrets을 이용해 암호화해서 저장

GitHub Actions - 환경변수 등록 방법

깃허브 > 선택한 레포지토리에서

Setting > Secrets and variables > action 탭을 클릭

1시방향 new repository secret 클릭!

아래와 같이 AWS_ACCESS_KEY_ID와 AWS_SECRET_ACCESS_KEY를 설정한다.

 

VSC

레포지토리 폴더의 최상단 위치의 .env 파일 생성

[secrets.AWS_ACCESS_KEY_ID 로 받아와서 secrets 객체에 키-값 형태로]

const secrets = {
  AWS_ACCESS_KEY_ID : ???,
  AWS_SECRET_ACCESS_KEY : ???
}

.github/workflows/client.yml 파일 생성 후 작성

name: client
on:
  push:
    branches:
      - '현재 브랜치 네임' #과제에서의 브랜치 네임은 reference 라고 나오지만 보편적으로 main
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://당신의 버킷이름으로~ \\
            --delete
        working-directory: ./my-agora-states-client

my-agora-states-client 에서 npm install 후 npm run build

→

client 폴더에서 나와서, 지장없는 파일 수정(주석 등등) 후

→

git add .

commit -m “~~”

git push origin reference (설정한 거에 다름, git remote -v 로 확인)

→

aws s3 설정한 버킷에서 자동으로 업로드 된 것을 확인 가능!

 

배포 링크 : aws 만료시 404

http://fe-17-min-hh-k-s3.s3-website.ap-northeast-2.amazonaws.com/login