[Spring Boot] Github Actions 를 활용한 CI/CD 파이프라인 구축(개념)

CI/CD 개념

개발자라면 한번쯤은 이런 생각을 했을 것이다 "서비스를 개발하고 배포하는 과정이 너무 귀찮은데?" 수시로 바뀌는 코드들과 버그 수정으로 반복되는 테스트, 빌드->배포 과정은 매우 비효율 적일 뿐더러 무엇보다 귀찮다. 반복되는 이 일련의 과정을 자동화 시킨다면 생산성과 효율 면에서 매우 긍정적인 효과를 가져다 줄 것이다!


CI/CD 란 이런 개발자들의 귀찮음을 해결해줄 수 있는 훌륭한 자동화 기술 이다!

• CI(Continuous Intergration)
  CI 란 Continuous Intergration [지속적 통합] 을 의미한다.
  한 프로젝트에 git을 사용하여 여러 개발자가 개발하고 있다고 가정해보자 만약 프로젝트를 오랜 기간 병합하지 않고 각자 개발했다면 후에 병합을 진행했을 때 수많은 충돌에 직면할 것이다 이렇게 되면 서비스 개발에 집중할 수 없고 코드 수정과 병합에 많은 시간을 소비하게 되니 서비스 출시 기간만 자꾸 미뤄지는 상황에 놓이게 될 것이다.
  이러한 상황을 방지하기 위해서는 작업단위를 잘게 쪼개어 지속적인 빌드 과정과 테스트를 거처 병합하는 것이 중요한데 이를 자동화 시키는 것이 CI 지속적 통합 이다.
  

  

• CD(Continuous Delivery / Continuous Deployment)
  CD 란 "지속적인 제공" 과 "지속적인 배포" 를 의미한다.
  Continuous Delivery 에 대해 알아보자면 CI를 통해 빌드와 테스트 단계를 거친 후 서비스 배포가 가능하다 판단되면 개발자가 수동으로 배포를 진행하는것을 의미한다.
  반면 Continuous Deployment 는 배포 과정 마저 자동화 시키는 것을 의미한다.
  

  

Github Actions 개념

Github Actions 란 깃허브에서 제공하는 CI/CD 도구 이다.
CI/CD 를 구축하려면 개발환경과 배포 환경 사이에서 이어줄 무언가가 필요한데 이를 Github Actions가 수행할 수 있다.
이해를 쉽게 하기 위해 간단한 상황을 하나 가정해보면, 만약 당신이 기능 개발을 완료한 프로젝트를 깃허브에 push 했을때 이 프로젝트가 자동으로 빌드되고 배포 되려면 어떤 과정을 거쳐야 하겠는가?

1. 먼저 프로젝트가 push되었다는 것을 감지한다.
2. 배포 환경에 접근한다.
3. 기능이 추가된 새로운 프로젝트를 가져온다.
4. 빌드 후 실행한다.

한마디로 개발환경과 배포환경 사이에서 이러한 과정들을 자동화시켜줄 무언가가 필요한데 이 역할을 Github Actions가 수행하는 것이다.

• Github Action Core
  Github Action을 상용하기 위해서는 알아야될 기본적인 개념들이 있다
  Workflow: 여러 job으로 구성되며 자동화하고자 하는 전체 프로세스를 의미한다.
  Event: 특정 브랜치에 push 하거나 pull request 하는 이벤트를 감지한다.
  Job: Workflow 내에서 독립적으로 실행되는 작업 단위로 여러 Step 들로 구성되며 여러 job들은 기본적으로 병렬로 실행된다.
  Step: Job내에 정의된 step들은 순서대로 실행되며 원하는 특정 명령을 실행시킬 수 있다.
  Action: Workflow 내에서 재사용 가능한 코드 단위를 의미한다. Github Action에서 사용 가능한 추가기능? 라이브러리? 정도로 생각하면 이해하기 편할 것이다.
  Runner: 명령을 실행시켜주는 가상의 컴퓨터 라고 볼 수 있다. runs-on 명령을 통해 명령이 실행될 환경을 직접 설정해줄 수 있다.(ex: runs-on: ubuntu-latest)

---

[Spring Boot] Github Actions 를 활용한 CI/CD 파이프라인 구축(환경구축) 편에서는 Github Actions 사용법과 기본적인 spring 프로젝트 세팅, 그리고 aws EC2 인스턴스를 생성해보겠다