프로젝트 아이디어 선정 후 Naver Cloud Platform을 이용해 서버를 만든 이후 2가지 작업을 가장 먼저 수행 했습니다.
1) Swagger UI 설정 (API 문서 자동화 위해)
2) CI/CD 빌드
- 디자이너, 기획자, 프론트 개발자가 반영한 내용을 쉽고 빠르게 확인하기 위해
- 프로젝트에서 지속적으로 수행해야하는 반복 작업들은 매번 직접 하기엔 비효율적이고 실수할 위험이 있기 때문
그 중 CI/CD 빌드를 위해 도구를 선정하였는데 대표적으로 Github Actions와 Jenkins 2가지가 있었습니다.
1. Github Actions & Jenkins
1-1. Github Actions
GitHub Actions is a continuous integration and continuous delivery (CI/CD) platform that allows you to automate your build, test, and deployment pipeline. You can create workflows that build and test every pull request to your repository, or deploy merged pull requests to production.
- github 저장소를 기반으로 개발에 대한 workflow를 자동화할 수 있는 도구입니다.
- runners라는 github에서 호스팅하는 서버에서 실행되고, 개인이 빌드 서버를 가지고 있다면 직접 호스팅하는 환경에서도 실행 가능합니다.
1-2. Jenkins
Jenkins는 무료 오픈 소스 자동화 서버입니다. Jenkins는 빌드, 테스트, 배포와 관련된 소프트웨어 개발 부분을 자동화하고, 지속적인 통합과 지속적인 배포를 제공하는 데 도움을 줍니다. - Wikipedia
1-3. Github Actions vs Jenkins
| Github Actions | Jenkins |
| Github에 의해 클라우드로 제공되기 때문에 추가 작업이 없음 | 별도의 빌드 서버 구성 작업이 필요함 |
| Github과 관련된 이벤트로만 빌드 작업 | Github 이벤트가 아니더라도 별도 계정, 트리거로 빌드 진행 |
| Jenkins에 비해 문서화가 잘 되어 있지 않음 | 많은 곳에서 사용하므로 문서가 다양 |
| 모든 환경에서 호환 가능 | Docker 이미지를 이용하여 호환성 문제 해결 필요 |
1-4. 프로젝트에서의 CI/CD 툴 선정
- 이번 프로젝트에서는 Github Actions를 사용하기로 결정했습니다. 이유는 아래와 같습니다.
1) Public의 Github Repository에서 프로젝트를 진행할 예정입니다.
- Github Actions는 public의 경우 클라우드 형태로 무료로 제공됩니다.
- Jenkin도 마찬가지로 Open Source이기에 무료지만, 별도의 빌드 서버를 필요로 합니다.
2) 프로젝트의 규모가 크지 않고 시간과 인원이 제한적입니다.
- Jenkins는 별도의 빌드 서버를 필요로 하므로, 관리 대상이 추가됩니다.
- 상대적으로 Jenkins에 비해 리소스 관리를 줄일 수 있으므로, Backend 개발에 집중할 수 있습니다.
2. Github Actions 구성 요소 및 개념
1. Workflow - (여러 Job으로 구성되고, Event에 의해 트리거되는 자동화된 프로세스)
- Github Actions의 최상위 개념 ( .github/workflows 내에 yaml로 작성 )
- 특정 목적을 위한 일련의 실행 트리거, 기능들을 모두 포함합니다.
- 하나의 Repository에는 여러 개의 workflow 가 존재할 수 있습니다.
- on 키워드로 언제 workflow가 실행 되는지 정의할 수 있습니다.
# master, dev 브랜치에 push 될 때 workflow 실행
on:
push:
branches:
- master
- dev
2. Job - (독립된 컨테이너에서 돌아가는 하나의 작업 처리 단위)
- 독립된 환경에서 돌아가는 하나의 task 단위
- 하나의 workflow에는 여러 개의 Job이 존재하며, 기본적으로 동시에 실행되지만 순서를 정할 수도 있습니다.
- runs-on과 steps 키워드를 쓰며 각각 기능은 아래와 같습니다.
- runs-on : Job을 실행할 runner(환경)을 정의합니다.
- steps : runner 환경에서 작업할 일련의 작업들을 정의합니다.
- 이외 세부 설정은 Github Actions 매뉴얼 / Jobs 설정 를 참고 해주세요.
# ubuntu-lates 이미지에서 "Hello Rally Mate" 출력
jobs:
hello-rally-mate: # 첫 번째 job
runs-on: ubuntu-latest
name: Echo Hello Rally Mate
steps:
# ... 중략 ...
job2:
# ... 중략 ...
3. Steps - (Tasks의 집합)
- 하나의 Job에는 여러 개의 Step이 존재합니다.
- 작업은 단순 command, script가 될 수도 있고 action이라고 하는 여러 명령이 될 수도 있습니다.
- uses와 run 키워드를 쓰며 각각 기능은 아래와 같습니다.
- uses: 사용할 action을 지정합니다. {소유자}/{저장소명}@{참조자|버전} 으로 구성됩니다.
- run : 사용할 command 혹은 script을 지정합니다.
- 이외 세부 설정은 Github Actions 매뉴얼 / Steps 설정 을 참고해주세요.
jobs:
hello-rally-mate: # 첫 번째 job
runs-on: ubuntu-latest
name: Echo Hello Rally Mate
steps:
# uses에서 action 사용, run에서 command, script 실행
- uses: actions/checkout@v2
- run: echo "Hello Rally Mate"
4. Actions - (액션)
- 반복되는 단계가 있다면 이를 재사용할 수 있게 하는 기능
- workflow의 가장 작은 단위이며, 재사용하거나 Github Marketplace의 Actions을 사용할 수도 있다.
- Github MarketPlace / Github Actions Repository
5. Event
- workflow에 해당 event를 정의해 놓으면, 해당 event가 repository에서 트리거됐을 때 실행되도록 할 수 있습니다.
- 이벤트는 해당 URL 에서 확인할 수 있습니다.
6. Runner
- workflow를 실행하는 실제 서버를 말합니다.
- Github에서는 기본적으로 Ubuntu, Windows, Mac OS 등 다양한 환경의 runner가 제공됩니다.
- 자체 custom된 환경에서 실행하고 싶을 때에는 직접 runner를 지정할 수 있습니다. (self-hosted runner)
7. 병렬처리
- github actions는 workflow 내의 각 Job을 병렬로 실행할 수 있습니다.
- [카카오 엔터프라이즈 : Github Actions 사용기 - 순차 처리에서 병렬 처리로]
실제 workflow 작성은 다음 포스팅에서 다루겠습니다.
+ 참고
[1] 워크서버개발팀의 GitHub Actions 적용기 (카카오엔터프라이즈)
[2] Github Actions의 소개와 핵심 개념 (DaleSeo)
[3] Github Action 사용법 정리 (어쩐지 오늘은)
'CI & CD' 카테고리의 다른 글
| Github Actions로 workflow 생성 (Spring Boot) (0) | 2023.07.03 |
|---|
