1. CI/CD의 개념,기본 문법

1. CI/CD, 개발자의 반복 작업을 자동화하는 필수 스킬

프로젝트에 새로운 기능을 추가하거나 버그를 수정할 때마다 이런 과정을 반복하고 계신가요?

1. 수정된 코드를 git push 한다.
2. 실제 서비스가 운영되는 서버에 직접 접속한다.
3. 최신 코드를 git pull 받는다.
4. 필요하다면 프로젝트를 다시 빌드한다.
5. 서버를 재시작한다.

코드 수정이 잦을수록 이 과정은 점점 더 귀찮고 번거로운 작업이 됩니다. 바로 이런 반복적인 배포 과정을 자동화하기 위해 우리는 CI/CD를 배웁니다.

CI/CD를 도입하면, 개발자가 특정 브랜치에 코드를 push하는 것만으로 빌드, 테스트, 배포의 모든 과정이 자동으로 실행되도록 파이프라인을 구축할 수 있습니다. 이를 통해 개발자는 코드에만 집중할 수 있고, 수동 배포 과정에서 발생할 수 있는 실수를 줄여 서비스의 안정성을 높일 수 있습니다. 🚀

CI (Continuous Integration, 지속적 통합): 코드 변경사항을 주기적으로 메인 브랜치에 통합하고, 자동으로 빌드 및 테스트하는 과정

CD (Continuous Delivery/Deployment, 지속적 제공/배포): 테스트를 통과한 코드를 실제 운영 환경에 자동으로 배포하는 과정

---

2. CI/CD 구축 도구: 왜 Jenkins가 아닌 GitHub Actions를 선택할까?

CI/CD를 구축할 수 있는 도구는 GitHub Actions, Jenkins, CircleCI 등 매우 다양합니다. 이 중에서 어떤 것을 선택해야 할까요? 물론 각 도구마다 장단점이 있지만, Jenkins와 GitHub Actions는 가장 널리 사용되는 선택지입니다.

두 도구 모두 CI/CD 파이프라인을 구축하는 데 필요한 모든 기능을 제공하지만, 결정적인 차이점이 있습니다.

• Jenkins:
  • 장점: 역사가 깊고, 플러그인이 매우 다양하여 자유도가 높습니다.
  • 단점: CI/CD를 실행하기 위한 별도의 서버를 직접 구축하고 운영해야 합니다. 이는 서버 임대 비용이 발생하고, 초기 설정과 유지보수에 노력이 필요하다는 것을 의미합니다.
• GitHub Actions:
  • 장점: GitHub 저장소(Repository)에 내장되어 있어 별도의 서버 구축이 필요 없습니다. 설정이 비교적 간단하고, GitHub 생태계와 완벽하게 연동됩니다. (Public 저장소는 무료 제공량도 넉넉합니다!)
  • 단점: Jenkins만큼 플러그인이 다양하지는 않을 수 있습니다.

결론적으로, 개인 프로젝트나 소규모 팀에서는 비용 부담과 설정의 번거로움이 없는 GitHub Actions가 훨씬 효율적인 선택이 될 수 있습니다.

---

3. GitHub Actions 핵심 개념과 동작 흐름 ⚙️

GitHub Actions는 CI/CD 파이프라인을 실행하는 **'작업 공간' 또는 '로봇'**이라고 생각하면 이해하기 쉽습니다. 우리가 미리 작성해 둔 각본(.yml 파일)에 따라 정해진 작업을 순서대로 실행해주는 역할을 하죠.

CI/CD 파이프라인에서 GitHub Actions는 주로 "빌드, 테스트, 배포" 로직을 실행하게 됩니다. 전체적인 흐름은 다음과 같습니다.

1. 트리거 (Trigger): 개발자가 코드를 작성하고 git push를 통해 GitHub 저장소에 변경사항을 올립니다.
2. 이벤트 감지: GitHub는 이 push 이벤트를 감지하고, 해당 저장소에 설정된 GitHub Actions 워크플로우(Workflow)를 실행시킵니다.
3. 워크플로우 실행:
   • 빌드(Build): GitHub Actions 가상 환경에서 소스 코드를 가져와 실행 가능한 파일로 만듭니다.
   • 테스트(Test): 빌드된 코드를 대상으로 미리 작성된 테스트 코드를 실행하여 기능의 정상 동작 여부를 확인합니다. (테스트 코드가 없는 프로젝트는 이 단계를 생략하기도 합니다.)
   • 배포(Deploy): 모든 테스트를 통과하면, 실제 서비스 서버에 접속하여 최신 버전의 코드를 전달합니다.
4. 서버 재시작: 실제 서버는 배포된 최신 코드를 적용하여 서버를 재시작하고, 사용자에게 새로운 기능을 제공합니다.

 

4. 깃허브 액션 기본 문법

일단 이렇게 .github 폴더 생성후 그 안에 workflows 폴더 생성후 그안에 yml 파일을 생성한다.

# Workflow의 이름
name: Github Actions 실행시켜보니

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

# 하나의 Workflow는 1개 이상의 Job으로 구성된다
# 여러 Job은 기본적으로 병렬적으로 수행된다
jobs:
  # Job을 식별하기 위한 id (내 맘대로 id 이름 정한다)
  My-Deploy-Job:
    # 깃허브 액션은 컴퓨터라 했는데(윈도우,맥,우분투등등 많은것중 무엇인가)
    # 우분투 환경 / 가장 최신 버전(latest)
    runs-on: ubuntu-latest

    # Step: 특정 작업을 수행하는 가장 작은 단위
    # Job은 여러 Step들로 구성되어 있다.
    steps:
      - name: Hello World 찍기
        # echo는 리눅스의 명령어 이고 리눅스의 프린트문 명령어다.
        run: echo "Hello World"

        # 4-1 ========================================
      - name: 여러 명령어 문장 작성하기
        run: |
          echo "Good"
          echo "Morning"
          
      # $GITHUB_SHA는 지금 해당하는 커밋의 아이디값을 뜻
      # $GITHUB_REPOSITORY 지금 해당하는 깃허브의 레포지토리명을 뜻
      - name: Github Actions 자체에 저장되어 있는 변수 사용해보기
        run: |
          echo $GITHUB_SHA
          echo $GITHUB_REPOSITORY

      - name: 아무한테나 노출이 되면 안 되는 값
        run: |
          echo ${{ secrets.PassWord }}

설정파일의 name 필드에 적은게 저렇게 나온다.

 

깃허브 액션에 만약 비밀번호등 민감한 정보를 넣어야하는데, 명시하거나  깃허브 액션 어떤 명령어로 볼수 있으면 안되므로 setting-Secrets and variables - Actions 로 들어간뒤 New repository secret 누르고 저렇게 한다. 이후 커밋 푸쉬후 다시 확인해보면 안전하게 가려진다.

 

 

5. 깃허브 액션 전체 구조