[Wanted]_CI/CD with GitHub Actions

hanseungjune·2023년 6월 30일
0

Wanted

목록 보기
3/21
post-thumbnail

CI/CD

  • Continuous Integration (CI, 지속적 통합): CI는 개발자들이 작성한 코드를 자동으로 통합하는 과정을 의미합니다. 여러 개발자가 동시에 작업한 코드가 하나로 통합되어 빌드 및 테스트되며, 코드 품질을 유지하고 충돌을 방지하는 데 도움을 줍니다.

  • Continuous Delivery (CD, 지속적 제공): CD는 CI를 통해 통합된 코드를 자동으로 테스트, 빌드하여 언제든지 배포할 수 있는 상태로 유지하는 과정입니다. 애플리케이션을 언제든지 제품 환경에 출시할 수 있도록 준비되어 있으며, 수동으로 배포하는 번거로움을 줄여줍니다.

  • Continuous Deployment (CD, 지속적 배포): CD는 CD의 한 단계로, 테스트 및 빌드된 코드를 자동으로 제품 환경에 배포하는 과정을 의미합니다. 애플리케이션의 변경사항이 자동으로 실시간으로 고객에게 제공되며, 배포 주기를 짧게 유지하여 빠른 피드백과 혁신을 가능하게 합니다.

CI/CD 자동화를 통해 개발자들은 코드의 품질을 유지하고 더욱 효율적인 작업을 수행할 수 있으며, 빠르고 안정적인 배포를 실현할 수 있습니다.

1. CI

Continuous Integration (CI)은 코드를 지속적으로 통합하는 과정을 의미합니다. 이 과정에서 코드를 단순히 합치는 것뿐만 아니라 코드의 유효성을 검사하고 테스트하는 작업이 포함됩니다. CI의 주요 내용을 정리하면 다음과 같습니다:

  • 코드 통합: CI는 개발자들이 작성한 코드를 주기적으로 통합하는 작업을 수행합니다. 이는 보통 코드 변경 사항을 관리하는 버전 관리 시스템(GitHub의 PR 등)을 통해 이루어집니다.

  • 자동화된 테스트: CI 과정에서는 코드의 품질을 검증하기 위해 자동화된 테스트를 실행합니다. 단위 테스트, 통합 테스트, 기능 테스트 등 다양한 수준의 테스트가 포함될 수 있습니다.

  • 유효성 검사: CI는 코드의 구문 오류, 정적 분석 결과, 의존성 충돌 등의 유효성을 검사합니다. 이를 통해 머지 후 코드가 제대로 동작할지에 대한 의문을 최소화하고 안정성을 확보합니다.

  • 즉각적인 피드백: CI는 테스트 결과 및 유효성 검사를 실시간으로 피드백해줍니다. 문제가 발견되면 해당 정보를 개발자에게 전달하여 빠르게 문제를 파악하고 수정할 수 있도록 도움을 줍니다.

CI를 통해 코드의 지속적인 통합과 테스트를 자동화함으로써 개발자는 코드 변경의 안정성을 확보하고 효율적으로 작업할 수 있습니다. 또한, 즉각적인 피드백을 통해 문제를 신속하게 대응하고 품질을 개선할 수 있습니다.

2. CD

Continuous Deployment (CD)는 Continuous Integration (CI) 과정을 통해 성공적으로 통합된 코드를 실제 사용자가 사용하는 프로덕션 환경에 자동으로 배포하는 것을 의미합니다. CD는 종종 Continuous Delivery (CD)와 혼용되어 사용되는데, 이 둘은 다음과 같은 의미를 갖습니다:

  • Continuous Delivery (CD): Continuous Delivery는 CI 과정을 통해 개발된 코드를 개발환경에서 프로덕션 환경으로 자동으로 전달(배포)하는 것을 의미합니다. 이 단계에서는 배포를 위한 마지막 검증 및 테스트가 진행되며, 배포 준비가 완료된 코드는 언제든지 배포될 수 있는 상태를 유지합니다.

  • Continuous Deployment (CD): Continuous Deployment는 Continuous Delivery의 확장된 개념으로, 자동화된 배포 프로세스를 통해 개발된 코드가 실제 사용자가 접근하는 프로덕션 환경까지 자동으로 배포되는 것을 의미합니다. CI/CD 파이프라인을 통해 테스트를 통과한 코드는 자동으로 프로덕션 환경에 배포되어 사용자에게 즉시 제공됩니다.

CD를 통해 개발자는 코드 변경 사항을 빠르게 사용자에게 전달하고, 소프트웨어의 지속적인 개선과 배포를 실현할 수 있습니다. 자동화된 배포 프로세스를 통해 개발자는 배포 과정에서 발생할 수 있는 인간의 실수를 최소화하고, 빠른 피드백을 통해 안정적인 서비스를 제공할 수 있습니다.

3. CI / CD 플랫폼의 종류

CI/CD는 자동화된 파이프라인을 통해 일련의 과정을 처리하며, CI/CD 플랫폼을 사용하여 이를 구축하고 관리합니다. CI/CD 플랫폼은 설치형과 클라우드형으로 구분됩니다.

  • 설치형 CI/CD 플랫폼:

    • 개발자가 특정 컴퓨터에 직접 CI/CD 플랫폼을 설치하고 사용합니다.
    • 대표적인 설치형 CI/CD 플랫폼으로는 Jenkins가 있습니다.
    • 개발자가 컴퓨터 관리에 대한 책임을 직접 져야 하지만, 세부적인 조정과 커스터마이징이 가능합니다.
  • 클라우드형 CI/CD 플랫폼:

    • 서비스 제공자가 클라우드에서 CI/CD 플랫폼을 운영하고 제공합니다.
    • 개발자는 컴퓨터 관리에 대한 부담 없이 클라우드형 플랫폼을 활용할 수 있습니다.
    • 대표적인 클라우드형 CI/CD 플랫폼으로는 Travis CI, GitHub Actions 등이 있습니다.
    • 클라우드에서 제공되는 수준까지만 조정이 가능하며, 컴퓨터에 직접 접근할 수 없는 제약이 있습니다.

CI/CD 플랫폼을 선택할 때는 설치형과 클라우드형의 장단점을 고려하여 개발자의 요구사항과 프로젝트의 특성에 맞게 선택해야 합니다.

4. CI/CD가 각광받는 이유

어느 정도 규모가 있는 개발팀은 CI/CD를 구축하는 이유는 효율성 때문입니다. CI/CD 구축에는 노력과 비용이 필요하지만, 이를 통해 개발자들은 배포 과정에 대한 수동 작업을 줄이고 프로덕트의 개발과 개선에 더 많은 리소스를 투입할 수 있습니다.

다음은 CI/CD 구축의 효율성에 대한 이유입니다:

  • 빠른 배포와 빠른 피드백:

    • CI/CD를 통해 자동화된 배포와 테스트 과정을 거침으로써 빠르게 프로덕트를 배포할 수 있습니다.
    • 사용자 피드백을 신속하게 받아들이고 개선사항을 빠르게 반영할 수 있습니다.
  • 자동화된 품질 보증:

    • CI/CD 파이프라인을 통해 코드의 자동 빌드, 테스트, 검증을 수행하여 개발자가 코드 품질을 확보할 수 있습니다.
    • 버그와 결함을 조기에 발견하고 수정함으로써 소프트웨어의 안정성을 향상시킬 수 있습니다.
  • 효율적인 리소스 활용:

    • CI/CD를 통해 개발자들이 수동적인 배포 작업에서 해방되므로, 개발자들은 핵심 가치를 창출하는 개발과 개선에 집중할 수 있습니다.
    • 비싼 인력인 개발자의 리소스를 효율적으로 활용할 수 있습니다.
  • 지속적인 개선과 혁신:

    • CI/CD를 통해 지속적인 개발과 배포를 실현함으로써 프로덕트의 지속적인 개선과 혁신을 추구할 수 있습니다.
    • 빠른 배포 주기를 통해 새로운 기능과 개선사항을 빠르게 사용자에게 제공할 수 있습니다.

이러한 이유로 개발팀은 CI/CD를 구축하여 개발과 배포 과정을 자동화하고, 개발자들의 업무 효율성과 소프트웨어 품질 향상을 이루고자 합니다.

GitHub Actions

GitHub Actions는 GitHub에서 제공하는 클라우드형 CI/CD 툴입니다. GitHub에서 자체적으로 제공하기에 GitHub 레파지토리와의 연동이 쉽고, 레파지토리 안에서 CI/CD까지 함께 구축하고 관리할 수 있다는 이점으로 인해 현재 많은 인기를 얻고 있습니다.

1. GitHub Actions의 구성요소들

출처: GitHub Actions 공식문서(https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions)

  1. Workflow
    • GitHun Actions상에서 실행될 자동화된 일련의 작업 흐름을 의미합니다. YAML 형식의 파일을 통해서 Workflow를 설정할 수 있습니다.
    • 레파지토리 안에서 발생하는 이벤트나 예약된 스케줄에 의해서 실행될 수 있으며, 직접 수동으로 실행하는 것 또한 허용됩니다.
  2. Event
    • 레파지토리에서 발생하는 push, pull request open, issue open등의 특정한 활동을 의미합니다.
    • GitHub Actions에서는 특정한 Event가 발생했을 시 그에 맞는 CI/CD 파이프라인을 구동하도록 설정할 수 있습니다.
  3. Jobs
    • 하나의 runner에서 실행될 여러 step의 모음을 의미합니다.
    • step은 실행가능한 하나의 shell script 또는 action을 의미합니다.
    • job안의 step들은 순차적으로 실행됩니다.
    • 하나의 workflow안에 여러 job들을 설정할 수 있습니다.
    • workflow의 job들은 기본적으로 병렬로 실행됩니다.
    • 일부 job의 경우에는 다른 job에 의존성을 설정해서 다른 job이 완료되고 난 뒤 실행하도록 할 수 있습니다.
  4. Actions
    • GitHub Workflow에서 자주 사용되는 기능들을 모아둔 일종의 커스텀 애플리케이션입니다.
    • 설정파일에서 use 키워드와 함께 사용할 수 있으며 브랜치로 체크아웃하고, 환경을 설정하는 등 복잡하지만 자주 사용되는 과정들을 미리 정의해두고 편리하게 활용할 수 있습니다.
    • GitHub Marketplace에서 Action들을 검색하고 활용할 수 있습니다.
  5. Runner

2. CI/CD로 구축할 목표

정적 웹사이트들은 S3를 통해서 호스팅 할 수 있습니다. 하지만 매번 CRA의 dependencies를 설치하고, build script를 실행하고, AWS에 로그인해서 S3 버킷에 들어간뒤에, 기존의 자료들을 삭제하고 새로운 파일들을 업로드하는 것은 꽤나 번거로운 일입니다. 이제 GitHub Actions를 통해서 아래의 과정을 자동화 시켜보겠습니다.

  1. 마스터 브랜치에 push or Pull Request Merge가 발생하면 workflow를 실행한다.
  2. 필요한 dependencies들을 설치한다.
  3. build script를 실행합니다.
  4. aws에 접속한 후 s3 bucket에 build한 결과물을 업로드합니다.
  • 예시파일
name: CI/CD

on:
  push:
    branches:
    - master
  workflow_dispatch:

jobs:
  cicd:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3
			with:
				ref: "master"
    - run: npm ci
    - run: npm run test
    - run: npm run build
    - name: deploy to s3
      uses: jakejarvis/s3-sync-action@master
      with:
        args: --delete
      env:
        AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}
        AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
        AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
        AWS_REGION: 'ap-northeast-2'
        SOURCE_DIR: 'build'

프론트엔드가 배포까지 알아야 할까요?

개발자가 처음 개발을 시작할 때는 주로 "프론트엔드 개발"이라고 하면 UI와 기능을 코드로 개발하는 것이 전체 업무로 오해할 수 있습니다. 하지만 실제로 개발자의 역할은 기능 개발에만 한정되지 않습니다.

현대의 IT 팀에서 개발자는 다음과 같은 역할을 맡고 있습니다:

  • 기획과 분석:

    • 제품의 기획과 분석 단계에 개발자가 참여하여 요구사항을 이해하고 기술적으로 해결책을 제시할 수 있습니다.
  • 기능 개발:

    • 프론트엔드 개발자의 주요 업무로, UI와 기능을 코드로 개발하여 제품을 구현합니다.
  • 배포 및 운영:

    • 개발자는 개발한 제품을 배포하고 운영하는 단계에서도 책임을 집니다.
      배포 과정을 이해하고, 문제 발생 시 적절한 대응을 할 수 있어야 합니다.
  • 사용자 피드백과 개선:

    • 개발자는 사용자의 피드백을 수용하고, 개선을 위한 작업을 진행합니다.
      기획 단계에서부터 개발적인 관점으로 요구사항을 풀어가는 능력이 요구됩니다.

기능 개발만을 담당하는 것이 아니라 배포 및 운영에 대한 이해와 책임을 가지는 이유는 다음과 같습니다:

  • 전체 개발 과정을 이해할 수 있는 시야 확보:

    • 배포와 운영에 대한 이해는 개발자가 전체 개발 과정을 이해하고 프로젝트를 종합적으로 관리할 수 있는 시야를 갖게 합니다.
  • 문제 대응 및 트러블 슈팅:

    • 개발자가 배포 과정에서 문제가 발생했을 때, 어느 부분에서 문제가 발생했는지 확인하고 대응할 수 있어야 합니다.

프론트엔드 개발자도 배포에 대한 기본적인 지식과 이해를 가져야 합니다. 이를 통해 소프트웨어 개발 프로세스의 전체 과정을 이해하고, 개발한 제품이 배포 과정에서 문제가 발생했을 때 적절한 대응을 할 수 있습니다.

profile
필요하다면 공부하는 개발자, 한승준

0개의 댓글