프로젝트 CI/CD 적용 , 설명

 

CI/CD란  ? 

CI/CD는 테스트 (test) , 통합 (merge) , 배포 (Deploy) 의 과정을 자동화하는 것을 의미

 

CI/CD 그래서 왜 사용해 ?

새로운 기능 추가시 코드를 작성 후 Commit을 한다 , 그 뒤에 브런치에 Merge 를 하고 배포를한다
배포를 할 때 직접 컴퓨터 서버인 AWS EC2인스턴스에 접속해서 새로운 코드를 내려 받아 실행 시켜야한다

얼마전에도 배포 이후 DB 이중화를 하게되면서 push 후 , git pull 로 내려 받고 하는 과정들이 있었는데 너무나 귀찮다
이런 반복적인 과정을 자동화 시키는게 CI/CD를 배우는 이유다.

 

 

https://www.performetriks.com/post/load-test-in-a-cicd-environment

개발자가 코드를 작성 , 커밋을 하게되면 빌드가 되게 세팅 , 빌드가 완료되면 작성한 테스트코드를 실행
테스트를 통과하면 실제서버 컴퓨터에 최신코드가 배포

---

CI/CD 구축할 때 자주 사용하는 툴

• Jenkins
• Travis
• Github Actions

이정도 알고 있다
Travis는 이동욱님 스프링부트와 AWS를 혼자 구현하는 웹서비스 책에서 사용하는 것을 보았다
(책이 19년도 , 리눅스1 버전 사용하길래 따라하다가 다 삭제하고 블로그 보면서 ubuntu 사용)

Jenkins 유니폼 입은 F&B 아저씨 (호텔 생각나네)

실제로 사용할 것은 Github Actions를 사용하려고 한다

Jenkins는 서버를 구축을 해야하고 서버를 빌리는데 비용이 발생한다 , RDS 로 인해 현재 AWS에 10달러 청구당했는데 
더 이상은 그만 내고싶다.

Github Actions는 Github에 내장되어있고 , 비용적으로도 유리하다고 한다 

https://tech.kakao.com/posts/516

카카오엔터프라이즈가 GitHub Actions를 사용하는 이유 - tech.kakao.com

 

---

Github Actions

CI/CD 과정에서 Github Actions는 빌드, 테스트, 배포 에 대한 로직을 실행시키는 역할을 하게 된다

1. 개발자 , 코드작성 , Commit
2. Github에 Push
3. Push를 감지한 Github Actions에 작성한 로직이 실행
   1. 빌드 build
   2. 테스트 test
   3. 서버로 배포 Deploy
4. 서버에서 배포된 최신 코드로 서버를 재 실행

 

Github Actions를 실행시키기 위해서는 반드시 .github/workflows라는 디렉터리에 .yml 또는 .yaml의 확장자로 파일을 작성해야 한다. 그리고 .github/workflows는 프로젝트 폴더의 최상단에 만들어야 한다.

# Workflow의 이름
# Workflow : 하나의 yml 파일을 하나의 Workflow라고 부른다. 
name: Github Actions 실행시켜보기

# Event : 실행되는 시점을 설정
# main이라는 브랜치에 push 될 때 아래 Workflow를 실행
on:
  push:
    branches:
      - main

# 하나의 Workflow는 1개 이상의 Job으로 구성된다. 
# 여러 Job은 기본적으로 병렬적으로 수행된다.
jobs: 
  # Job을 식별하기 위한 id
  My-Deploy-Job: 
	  # Github Actions를 실행시킬 서버 종류 선택
		# ubuntu 환경 / 가장최신버전 latest
    runs-on: ubuntu-latest
    
    # Step : 특정 작업을 수행하는 가장 작은 단위
    # Job은 여러 Step들로 구성되어 있다.
    steps: 
      - name: Hello World 찍기 # Step에 이름 붙이는 기능
        run: echo "Hello World" # 실행시킬 명령어 작성 , 리눅스버전
        
      - name: 여러 명령어 문장 작성하기
        run: |
          echo "Good"
          echo "Morning"
          echo "Good"
          echo "Bye"
          

			# 참고: https://docs.github.com/en/actions/learn-github-actions/variables
      - name: Github Actions 자체에 저장되어 있는 변수 사용해보기
        run: |
          echo $GITHUB_SHA
          echo $GITHUB_REPOSITORY

			- name: Github Actions Secret 변수 사용해보기
				run: |
					echo ${{ secrets.MY_NAME }}
					echo ${{ secrets.MY_HOBBY }}

---

개인 프로젝트 CI/CD

• git pull을 활용해 변경된 부분의 프로젝트 코드에 대해서만 업데이트 하기 때문에 CI/CD속도가 빠르다
  • 대부분의 CI/CD 방식은 전체 프로젝트 통째로 갈아끼우는 방식
  • CI/CD 툴로 Github Actions 만 사용하기에 인프라 구조가 복잡하지 않다
• 빌드 작업을 EC2에서 진행 하기에 운영하고 있는 서버의 성능에 영할을 줄 수 있다
  • Github 계정 정보가 EC2에 저장되기에 믿을만한 사람들과 같이 진행하는 토이 프로젝트에서 사용해야한다고 한다.

https://gi-dor.tistory.com/262

Spring Boot 개인,토이 프로젝트에서 CI/CD

 

---

일반 프로젝트 CI/CD

• 빌드 작업을 Github Actions 에서 하기 때문에 운영하고 있는 서버의 성능에 영향을 거의주지 않는다
• CI/CD툴로 Github Actions만 사용하기에 인프라 구조가 간단하다

• 무중단 배포를 구현하거나 여러 EC2 인스턴스에 배포를 해야한다면
  직접 Github Actions에 스크립트를 작성해 구현해야한다 

🔹 현업에서 초기 서비스를 구축할 때 많이 활용한다

• 처음 서비스를 구현할 때는 대규모 서비스에 적합한 구조로 구현하지 않는다.
• 확장의 필요성이 있다고 느끼는 시점에 인프라를 고도화하기 시작한다.
• 복잡한 인프라 구조를 갖추고 관리하는 건 생각보다 여러 측면에서 신경쓸 게 많아지기 때문.
  • 인프라 구조를 변경할 때 시간이 많이 들어감
  • 에러가 발생했을 때 트러블 슈팅의 어려움
  • 팀원이 인프라 구조를 이해하기 어려워 함
  • 기능을 추가하거나 수정할 때 더 많은 시간이 들어감
  • 금전적인 비용이 더 많이 발생

 

---

확장성을 고려한 프로젝트 CI/CD Code Deploy

• CodeDeploy는 수많은 AWS EC2에 배포를 쉽게 할 수 있도록 도와준다.
• CodeDeploy에 무중단 배포 기능이 내재되어 있어 손쉽게 무중단 배포를 진행할 수 있다

• CodeDeploy를 사용함으로써 인프라 구조가 복잡해졌다. 구조가 복잡해짐에 따라 관리 비용, 유지보수 비용, 난이도, 트러블 슈팅 어려움, 복잡도가 증가했다.

서버를 여러대 이상 구동하거나 무중단 배포가 중요한 서비스에 주로 사용한다 

(결국 서비스하는 업체면 무조건이네)