GitHub Actions으로 배포 자동화해 보기(a.k.a CI/CD) – 1화

이 글은 [스프링 부트 3 백엔드 개발자 되기(자바 편)]에서 발췌했습니다.

골든래빗 출판사

CI/CD가 뭐냐고요? 쉽게 말해 개발자가 개발을 마치고, 애플리케이션을 빌드하고, 테스트를 하고, 원격 저장소에 코드를 업데이트하고, 이를 배포하는 등의 전 과정을 자동화하는 과정을 말합니다. 대부분의 실무 환경에서는 CI/CD를 진행하죠. 여기서는 깃허브 액션을 활용하여 CI/CD를 진행해봅니다.

본 글은 ‘GitHub Actions으로 배포 자동화해 보기’의 1편으로 CI/CD가 무엇인지 알아보고, 깃허브 리포지터리 생성 및 코드를 푸시하는 과정을 소개합니다.

1. CI/CD란?

앞서 CI/CD라는 표현을 써서 궁금한 독자가 많을 겁니다. 우선 CI/CD의 의미를 이야기하기 전에 CI/CD가 필요한 상황을 생각해봅시다. 만약 여러분의 서비스를 배포하고 운용하던 중에 코드를 변경할 일이 생기면 어떤 작업을 해야 할까요? 우선은 코드 수정을 하고, 로컬 환경에서 테스트를 진행할 겁니다. 그리고 빌드도 잘되는지 확인하겠죠. 그런 다음에는 jar 파일을 생성해 복사하고, AWS에 접속해서 복사한 jar 파일을 업로드해 새 배포 버전을 제공해야 합니다. 지금 이 과정을 기계적으로 계속 할 수 있을까요? 그리고 프로젝트 규모가 엄청나게 커지면 이 작업은 굉장히 힘들 겁니다. 그럴 때 도입하는 것이 CI/CD입니다. 이 용어는 어떤 도구를 의미하는 것이 아니라 방법을 말합니다.

이 방법을 도입하면 빌드부터 배포까지의 과정을 자동화할 수 있고, 또 잘 되는지 모니터링할 수 있습니다. 사실 CI는 지속적 통합, CD는 지속적 제공이라는 의미가 있습니다. 앞서 이 표현을 풀어 설명하지 않았던 이유는 설명해도, 이 과정의 필요성이나 불편함을 상상할 수 없는 단계였기 때문입니다. 이제 여러분은 수정, 빌드, 테스트, 배포 등을 직접했으므로 이 말이 이해가 될 겁니다. 그럼 CI부터 자세히 알아봅시다.

1.1 지속적 통합, CI

CI는 Continuous Integration을 줄인 표현입니다. 한글로 해석하면 지속적 통합이고, 풀어서 설명하면 개발자를 위해 빌드와 테스트를 자동화하는 과정이죠. CI는 변경 사항을 자동으로 테스트해 애플리케이션에 문제가 없다는 것을 보장합니다. 그리고 코드를 정기적으로 빌드하고, 테스트하므로 여러 명이 동시에 작업을 하는 경우 충돌을 방지하고 모니터링할 수 있습니다.

보통 코드 변경 사항이 코드 저장소에 업로드되면 CI를 시작하고, CI 도중 문제가 생기면 실패하므로 코드의 오류도 쉽게 파악할 수 있죠.

1.2 지속적 제공과 지속적 배포, CD

CD는 CI 작업을 끝낸 다음 실행하는 작업입니다. 배포 준비가 된 코드를 자동으로 서버에 배포하는 작업을 자동화하는 것이죠. CI가 통과되면 개발자가 수작업으로 코드를 배포하지 않아도 자동으로 배포하니 매우 편리합니다. 때문에 CD는 지속적 제공(continuous delivery)이라는 의미와 지속적배포(continuous deployment)라는 의미를 모두 가집니다.

1.3 지속적 제공에서의 CD 의미

애플리케이션에 적용한 코드의 빌드와 테스트를 성공적으로 진행했을 때 깃허브와 같은 코드 저장소에 자동으로 업로드하는 과정을 말합니다. 최소의 노력으로 코드 배포를 쉽게 하는 것을 목표로 합니다.

1.4 지속적 배포에서의 CD의미

지속적 제공을 통해 성공적으로 병합한 코드 내역을 AWS와 같은 배포 환경으로 보내는 것을 의미합니다. 이를 실무에서는 릴리스라고 하죠. 지속적인 배포는 지속적 제공의 다음 단계까지 자동화합 니다. 즉, 개발자가 애플리케이션에 변경 사항을 커밋한 후 몇 분 이내에 애플리케이션을 자동으로 배포되어 적용됩니다.

2. 깃허브 액션 사용하기

깃허브 액션(Github Actions)은 깃허브에서 제공하는 서비스입니다. 리포지토리, 즉, 코드 원격 저장소에 특정 이벤트가 발생하면 특정 작업을 하거나, 주기적으로 특정 작업을 반복할 수 있게 합니다. 예를 들어 누군가 코드를 작성해 깃허브에 업데이트하면 해당 코드에 문제가 없는지 자동으로 코드를 빌드, 테스트한 이후 배포까지 할 수 있습니다. 지금까지 수작업으로 이 일을 한 여러분이라 면 이 서비스가 얼마나 편리할지 상상할 수 있을 겁니다.

2.1 깃허브 리포지터리 생성하고 코드 푸시하기

깃허브 액션을 사용하려면 깃허브 리포지터리에 지금까지 작업한 코드*를 업로드해야 합니다. 깃허브에 코드를 업로드하는 행위를 푸시(Push)라고 부르므로 앞으로 푸시라고 이야기하겠습니다. 깃허브 리포지터리를 생성하겠습니다.

* 이전 작업에 대한 예제코드 저장소 위치는 다음과 같습니다. – https://github.com/shinsunyoung/springboot-developer/tree/main/chapter11

1단계

깃허브 홈페이지에서 [New repository] 버튼을 눌러 새 리포지터리 생성 화면 로 넘어가서 프로젝트 이름을 적은 뒤, 공개 범위를 설정한 후 리포지터리를 생성합니다. 이때 실습에서 사용할 리포지터리 이름은 springboot-developer로 합니다. 다른 이름을 입력해도 됩니다.

2단계

리포지터리가 생성되면 SSH로 접근할 수 있는 리포지터리 주소도 알려줍니다. 주소를 복사하세요.

오른쪽에 보이는 사각형 2개가 겹쳐진 모양의 버튼을 눌러도 주소를 복사할 수 있습니다.

3단계

인텔리제이로 지금까지 작업한 프로젝트를 엽니다. 그런 다음 아래에 있는 [Terminal]을 눌러 터미널 창을 열고 git init 명령어를 입력합니다.

git init

git init 명령어는 특정 폴더를 깃 저장소로 만들 때 사용하는 명령어입니다. ‘빈 깃 저장소를 다 시 초기화했습니다’라는 안내 문구가 나타나면 제대로 실행된 겁니다.

$ git init힌트: Using 'master' as the name for the initial branch. This default branch name힌트: is subject to change. To configure the initial branch name to use in all힌트: of your new repositories, which will suppress this warning, call:힌트: git config --global init.defaultBranch 힌트: 힌트: Names commonly chosen instead of 'master' are 'main', 'trunk' and힌트:힌트: 'development'. The just-created branch can be renamed via this command:힌트:힌트: git branch -m ${경로}/.git/ 안의 빈 깃 저장소를 다시 초기화했습니다

그리고 숨김 폴더로 .git 폴더가 생깁니다. 바로 이 폴더에 코드의 변경 내역(버전) 관리를 위한 정보를 저장합니다. 이 폴더를 실수로 지우면 여러분의 버전 관리 내역이 모두 사라지므로 주의해야 합니다. 깃, 깃허브를 구분해서 지금까지 진행한 작업을 정리해봅시다. 깃허브에서는 리포지토리를 만들었고, 로컬에서는 스프링 프로젝트를 깃 저장소로 생성했습니다. 그림으로 보면 다음과 같습니다.

4단계

이번에는 깃허브의 리포지토리와 로컬의 깃 저장소를 연결하기 위해 remote 명령어를 사용합니다. 쉽게 말해 로컬의 깃 저장소 이력과 파일을 모두 깃허브에 업로드하기 위해 이 둘을 연결한다고 생각하면 됩니다. 깃허브의 리포지터리 주소는 아까 복사했습니다. 이 값을 다음 명령어에 잘 넣어 입력하면 됩니다.

▼ remote로깃, 깃허브연결하기

$ git remote add origin git@github.com:${사용자계정명}/springboot-developer.git

명령어 입력을 완료하고 나면 origin이라는 단축 이름에 git@github.com:${사용자계정명}/ springboot-developer.git이라는 리포지토리를 추가합니다.

5단계

이제는 로컬 저장소의 이력, 파일을 리포지토리에 푸시하기 위한 add, commit 작업을 해봅시다. add . 명령어는 현재 프로젝트 폴더의 모든 파일을 대상으로 변경 사항 등을 추적하고 그 파일들을 스테이지라는 곳에 올립니다. 스테이지는 쉽게 말해서 리포지토리에 올리기 전에 파 일들의 변경 사항을 미리 모아놓는 곳입니다. 커밋은 로컬 저장소에 올리기 위한 겁니다. 즉, 커밋 을 해야만 로컬 저장소에 변경 이력, 변경한 파일들이 업데이트됩니다.

$ git add .$ git commit -m "project init"[master (최상위-커밋) 19a8278] "project init" 31 files changed, 361 insertions(+) create mode 100644 .gitignore create mode 100644 README.md create mode 100644 build.gradle create mode 100644 gradle/wrapper/gradle-wrapper.jar create mode 100644 gradle/wrapper/gradle-wrapper.properties create mode 100755 gradlew

6단계

브랜치명을 main으로 바꾼 후 원격 저장소에 저장하기 위해 push 명령어를 입력해 푸 시를 마무리합니다. 이제 깃허브 리포지토리에 코드가 업데이트되었습니다.

$ git branch -M main$ git push origin main

7단계

깃허브에 접속해서 리포지토리를 확인하면 커밋할 때 적었던 메시지와 함께 코드들이 업로드된 것을 확인할 수 있습니다. 필자의 경우 커밋을 여러 번 하였으므로 다른 메시지도 섞여 있습니다.

3. 1부 마무리

1부에서는 CI/CD가 무엇인지 알아보고, 깃허브 리포지터리 생성 및 코드를 푸시해보았습니다. 2부에서는 깃허브 액션 스크립트를 작성하여 CI/CD를 구현하고, 정상적으로 작동하는 것을 확인해보겠습니다.

핵심 요약

1. CI는 개발자를 위해 빌드와 테스트를 자동화하는 과정이고, CD는 CI 작업을 끝낸 다음 실행 하는 작업으로, 배포 준비가 된 코드를 자동으로 서버에 배포하는 작업을 자동화하는 겁니다.

2. 깃은 여러 명이 한 프로젝트를 동시에 작업을 할 수 있게 코드를 저장하고 관리할 수 있는 시스템입니다. 깃허브는 깃과 연동해 작업한 코드를 저장할 수 있는 서비스입니다.

신선영

리멤버 백엔드 개발자. 하드 스킬과 소프트 스킬 역량을 강화하고자 부단히 공부하고 글로 남기는 백엔드 개발자입니다. 평일 기준 하루 평균 600뷰의 기술 블로그를 운영하고, 모교 학생을 대상으로 정기 세미나와 멘토링을 진행합니다. 구독자가 1,000명 정도 되는 사이드 프로젝트를 기획하고 개발하고 운영한 경험이 있습니다.

저자 블로그 shinsunyoung.tistory.com

저자 깃허브 github.com/shinsunyoung

AOP AWS BACKEND CI/CD CRUD DBMS DI GOOGLEAUTHGUARD GOOGLESTRATEGY HTTP 메서드 HTTP 헤더 IAM IOC JAVA JPA JWT OAUTH ORM PSA RDB RDS REST API RESTFUL API SPRINGBOOT3 VSCODE YAML 개발자 구글 로그인 깃허브 깃허브 액션 놉엔드 롬복 리포지토리 리프레시 토큰 백엔드 백엔드개발 비동기 처리 비주얼 스튜디오 코드 서버사이드 세션 스레드 스프링 스프링 데이터 JPA 스프링 부트 스프링 시큐리티 스프링부트3 스프링테스트 습엔드 엔티티 웹 개발 웹 프로그래밍 웹사이트 의존성 주입 인가 인증 일렉스틱 빈스토크 자바 자바11 자바8 컴공 코딩 콜백 쿠키 타임리프 테스트 템플릿 엔진 토큰 토큰 기반 인증 폴링 하이버네이트 홈페이지

Related News

[Agent] AI 에이전트 프로토콜, 구글 A2A 개념부터 원리 실습하기

[Python] 파이썬으로 엑셀 다루기 | ❷ 엑셀 데이터 사용하기

[Python] 파이썬으로 엑셀 다루기 | ❶ 엑셀 데이터 사용하기

[Python] 아나콘다 설치하기 | Anaconda, 파이썬, 주피터 노트북, 단축키

골든래빗 2023-07-05