{intro}
<Spacing size="lg" />
## CI/CD란?
 
### CI (Continuous Integration)
 
CI는 지속적 통합을 의미하며 기능 추가, 버그 수정 등 코드가 수정된 후에 빌드, 테스트를 통해 운영 브랜치에 통합되는 것을 의미합니다. 이 때 빌드, 테스트와 같은 프로세스를 자동화하여 변경된 코드에 문제가 있는 경우 빠르게 파악하고 수정할 수 있습니다. 이로 인해 효율적이고 안정적인 환경 속에서 개발에 집중할 수 있게 됩니다.
 
### CD (Continuous Delivery or Continuous Deployment)
 
CD는 지속적 제공 혹은 지속적 배포를 의미합니다. 두 용어 모두 변경된 코드가 배포되는 것을 의미하며 지속적 제공은 수동 배포, 지속적 배포는 자동 배포를 뜻합니다.
 
그리고 CI/CD가 물 흐르듯 자동으로 진행될 수 있도록 하는 프로세스를 CI/CD 파이프라인이라고 합니다.
 
## 핵심은 자동화
 
CI/CD 파이프라인의 핵심 목적은 자동화입니다. 개발자가 수정한 코드가 배포되는 일련의 과정이 자동화되어 효율적인 개발 환경을 구축하는데 그 목적이 있습니다.
 
만약 코드가 변경될 때마다 수동으로 테스트하고 배포해야 한다면 어떻게 될까요?
 
<PostImage src="https://drive.google.com/uc?export=view&id=1uv2koS3sOj2suDAEhbb4Lnyn3A991ypH" alt="파일질라 화면" width={937/1.5} height={747/1.5} caption="파일질라 화면, 변경된 파일을 직접 옮겨 배포"/>
 
실제로 제가 처음 퍼블리싱을 배웠을 때와 회사에 아직 CI/CD 파이프라인이 구축되지 않았을 때는 파일질라를 사용하여 배포했습니다. 
(회사에서는 배포 권한이 없었습니다😅) 
 
개발자가 변경된 파일을 수동으로 배포하는 작업은 비효율적이며 휴먼 에러가 발생하기도 쉽습니다. CI/CD 파이프라인을 구축해 둔다면 개발 외의 불필요한 작업으로 시간이 소모되는 것을 막을 수 있고 안정적으로 프로젝트를 운영해 나갈 수 있게 됩니다.
 
## 무엇으로 CI/CD 파이프라인을 구축할까?
 
제가 CI/CD 파이프라인을 구축하기 위해 사용한 도구는 Github Actions입니다. Github을 사용하고 있다면 추가적인 설치 작업 없이 Github에서 발생하는 이벤트(PR, push, issue 등)를 기반으로 작업을 트리거 할 수 있으며 마켓 플레이스에서 공유되는 액션을 사용할 수 있다는 장점이 있습니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=18owx0IULSn6Ijo9Id9-Dwh-wUqB9mYSt" alt="jet brain 2024 가장 많이 사용하는 ci 도구 설문 조사 결과 1위는 jenkins, 새롭게 떠오르는 1위는 github actions" width="699" height="654" caption="Jet Brain 설문 결과, 전체적으로는 Jenkins가 1위이지만 Github Actions가 새로운 1위로 떠오르고 있음"/>
 
또한 [Jet Brain에서 2024년 가장 많이 사용하는 CI 도구를 설문한 결과](https://blog.jetbrains.com/teamcity/2023/07/best-ci-tools/). Github Actions가 새로운 1위로 떠오르고 있으며 개인 프로젝트에서 가장 인기 있는 도구라고 합니다. (~~1위는 못 참지~~)
 
위와 같은 이유로 저는 Github Actions를 선택하게 되었습니다. 추후에 Github Actions에서 사용하는 워크플로우 파일 구성에 대해서도 포스트를 작성해 보겠습니다.
 
## CI/CD 시나리오
 
<PostImage src="https://drive.google.com/uc?export=view&id=1zjeU7_hBsAIpXb9zu76f_GaNRyMOih6E" alt="CI/CD 시나리오" width="1072" height="830"/>
 
Github Actions를 도입하며 구성한 CI/CD 시나리오는 위와 같습니다. 
(참고로 저는 브랜치 관리 전략으로 GitLab Flow를 사용하고 있습니다. [브랜치 전략 포스트 보러 가기](/posts/Process/브랜치-전략-바꾸기))
 
**1. PR 생성 및 업데이트**

feature 브랜치에서 코드 변경이 마무리되어 PR이 생성되고 업데이트 될 때 자동으로 테스트가 실행됩니다.
사실 혼자 작업하고 있기에 PR의 필요성에 대해 고민하기도 했지만 코드 변경 사항을 기록하고 테스트를 통과한 커밋한 배포 브랜치에 통합 될 수 있도록 PR 생성 및 업데이트 상황을 시나리오에 추가하였습니다.
 
**2. main, production 브랜치에 push**

main, production 브랜치에 커밋이 push되면 테스트 ➡️ 배포 ➡️ 슬랙 알림 작업이 일어납니다. main 브랜치에서는 Vercel에서 제공하는 preview 환경에 배포하여 QA를 진행할 수 있게 하였고 QA가 완료된 후 production 브랜치에 merge되면 production 환경으로 배포됩니다. 이 때 각 환경에서는 배포 성공, 실패 유무에 관계 없이 슬랙 알림이 오도록 시나리오를 구성했습니다. 

이미 테스트를 통과한 커밋만 배포 브랜치에 merge되는데 또 다시 테스트를 실행하는 것이 중복 작업이라는 생각이 들었지만 혹여나 배포 브랜치에 바로 커밋을 push하여 테스트를 통과하지 않은 코드가 배포되는 상황을 방지하기 위해 테스트 단계를 추가하였습니다.
 
## 포스팅을 마무리하며
 
사실 CI/CD에 대한 이야기를 많이 들어왔지만 막연한 개념으로 느껴졌습니다. 하지만 코드 변경, 테스트, 배포까지의 시나리오를 구성하고 Github Actions로 자동화 해보며 "아, 이런 게 CI/CD구나" 라고 감을 잡을 수 있었습니다. 업무의 효율을 높이는 방법을 이야기 할 때 항상 빠지지 않는 것이 바로 자동화인데요. 불필요한 수동 작업에서 벗어나 집중해야 할 부분에 더 집중할 수 있도록 CI/CD 파이프라인을 구축해 보면 좋을 것 같습니다👍

CI/CD 시나리오 구성하기

{intro}
<Spacing size="lg" />
## 브랜치 전략이란?
 
브랜치 전략이란 Git을 사용할 때 브랜치의 역할에 따라 코드를 관리하는 방법론입니다. 프로젝트의 요구사항에 따라 브랜치를 사용하는 규칙과 구조를 정의하여 일관성 있게 코드를 관리합니다.
 
그렇다면 브랜치 전략을 사용하는 이유는 무엇일까요? 하나의 브랜치에서 여러 명의 개발자가 개발한다고 가정해 보겠습니다. 각각의 개발자가 작업을 한 후에 하나의 브랜치에 커밋하게 되면 같은 파일을 수정한 경우 머지 충돌이 발생할 것입니다. 이를 해결하느라 불필요한 시간을 소모하게 되며 작업의 효율성이 떨어지게 됩니다. 또한 어느 커밋을 기준으로 QA, 배포할지 혼란스러우며 프로젝트 히스토리 관리도 어려울 것입니다. 따라서 기능 개발, 버그 수정, QA, 배포 등 브랜치의 역할을 나누어 코드를 관리하는 브랜치 전략을 도입하여 프로젝트의 운영의 효율성과 안정성을 높이는 것이 중요합니다.
 
## 혼자 작업 하는데도 브랜치 전략이 필요할까?
 
사실 배포 전에는 따로 브랜치를 생성하지 않고 main 브랜치에 push를 하곤 했습니다. 하지만 배포를 한 이후에는 Vervel을 통해 push가 발생하면 자동으로 배포되도록 세팅해두었기 때문에 브랜치 전략이 필요해졌습니다. tag가 push 되었을 때 배포하는 방법도 있지만 저는 배포 브랜치를 정해두고 해당 브랜치에 push가 발생할 때 배포되는 것이 직관적이라 생각되어 개인 프로젝트에도 브랜치 전략을 도입하였습니다. 각자의 필요에 따라 다르겠지만 프로젝트가 배포되고 있다면 브랜치를 나누어 작업하는 것이 안정적이라고 생각됩니다.
 
## 어떤 브랜치 전략을 도입할까
 
결론부터 말하자면 저는 GitLab flow를 선택했습니다. 
이유는 Git flow보다는 단순하고 Github flow보다는 브랜치의 역할 분담이 잘 되어 있기 때문입니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1G-r8Hs7QcS6rTYj1zrZW5YlyJ78-9nWA" alt="질문 : 왜 6점이에요? 대답 : 7점은 너무 많은 것 같고 5점은 좀 적은 것 같아서요." width="800" height="491" caption="🤔 : 왜 GitLab flow 쓰세요? 🤓 :Git flow는 너무 복잡하고 Github flow는 좀 단순한 것 같아서요..."/>
 
사실 처음에는 원래 알고 있던 Git flow 방식을 관성적으로 사용했습니다. 그러나 작업을 하다 보니 개인 프로젝트에서는 Git flow 전략이 다소 복잡하다는 생각이 들었고 대안을 찾기 위해 다른 브랜치 전략을 조사하게 되었습니다. 그럼 많이 사용되는 3가지 브랜치 전략을 살펴보겠습니다.
 
### Git flow
Git flow는 main, develop, feature, release, hotfix와 같은 5가지 브랜치를 사용합니다. 소개하는 3가지 전략 중 가장 복잡하지만 브랜치의 역할을 명확히 나누어서 안정적으로 코드 관리를 해나갈 수 있습니다. 다수의 인원이 모인 팀에서 사용하기 적절합니다. 저도 회사에 다니며 사용하였던 브랜치 전략이지만 개인 프로젝트에 적용하기에는 다소 번거롭다는 단점이 있습니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1_kZ7zkC3_JWAeD_LVp7G4yAB6PIlguJ3" alt="git flow" width="720" height="462" caption="이미지 출처 : https://medium.com/@sreekanth.thummala/choosing-the-right-git-branching-strategy-a-comparative-analysis-f5e635443423"/>
 
브랜치 역할
 
- main (master) : 테스트, QA 등 모든 검증이 완료된 프로덕션 배포용 브랜치. release, hotfix 등 배포 후 develop 브랜치와 동기화 필요.
- develop : 개발용 브랜치. develop 브랜치를 기준으로 기능 개발.
- feature : 기능 개발용 브랜치로 develop 브랜치에서 분기 후 병합.
- release : 배포 준비를 위한 브랜치로 QA 및 수정 작업이 진행. 배포 준비가 완료되면 main 브랜치에 병합.
- hotfix : 긴급한 에러를 수정하기 위한 브랜치로 main 브랜치에서 분기 후 병합.
 
### GitLab flow
 
GitLab flow는 GitLab에서 제안하는 브랜치 전략입니다. 항상 유지되는 main 브랜치가 있으며 필요에 따라 환경 브랜치(production, pre-production 등)를 추가할 수 있습니다. 배포할 준비가 코드가 포함된 main 브랜치가 있으나 해당 브랜치에서 배포를 진행하지 않습니다. 배포를 위해 production 브랜치를 생성하며 배포 전 QA 과정이 필요하다면 pre-production 브랜치를 생성할 수도 있습니다.
[GitLab에서 제안하는 GitLab flow의 모범 사례](https://about.gitlab.com/topics/version-control/what-are-gitlab-flow-best-practices/)를 보면 기능 개발 시에 main 브랜치를 기준으로 feature 브랜치를 생성할 것을 권장하고 있습니다.
 
<PostImage src="https://drive.google.com/uc?export=view&id=1slnud3rMJmuUEC71M6YpoF_Tbbr216vV" alt="gitlab flow" width="720" height="410" caption="이미지 출처 : https://medium.com/@sreekanth.thummala/choosing-the-right-git-branching-strategy-a-comparative-analysis-f5e635443423"/>
 
브랜치 역할
 
- main : 배포할 준비가 된 브랜치.
- production : 프로덕션 배포용 브랜치.
- pre-production : 배포 전 QA를 진행하는 브랜치
- feature : 기능 개발용 브랜치. main에서 분기 후 병합
 
### Github flow
 
main 브랜치와 feature 브랜치를 사용하는 브랜치 전략입니다. 소개하는 3가지 전략 중 가장 단순한 구조입니다. feature 브랜치에서 작업을 완료하고 바로 main 브랜치에 병합하는 방식으로 빠르게 기능을 개발하고 배포할 수 있다는 장점이 있습니다. 
 
<PostImage src="https://drive.google.com/uc?export=view&id=1NSigwt741nKEsFXxq8VVx0rFj4FiQzI3" alt="github flow" width="720" height="357" caption="이미지 출처 : https://medium.com/@sreekanth.thummala/choosing-the-right-git-branching-strategy-a-comparative-analysis-f5e635443423"/>
 
브랜치 역할
 
- main : 프로덕션 배포용 브랜치.
- feature : 기능 개발을 위한 브랜치, main 브랜치에서 분기 후 병합.
 
 
앞서 언급했듯이 저는 GitLab flow 방식의 브랜치 전략을 사용하고 있습니다. 개인 프로젝트이다 보니 Git flow의 main과 develop 브랜치를 동기화하는 작업이 번거롭게 느껴졌고 간단한 QA는 Vercel에서 제공하는 preview 배포 기능을 통해 develop 브랜치에서 진행하고 있었기에 release 브랜치의 필요성을 느끼지 못했습니다. 하지만 Github flow처럼 feature 브랜치에서 바로 main 브랜치로 merge하는 것은 안정성이 떨어진다고 생각하였기에 GitLab flow 방식을 최종적으로 선택하였습니다. 환경에 따라 브랜치를 유연하게 추가할 수 있다는 점도 큰 매력 포인트였습니다.
 
## 포스팅을 마무리하며
 
오늘은 프로젝트에 맞게 브랜치 전략을 바꾸기 위해 3가지 브랜치 전략의 특징에 대해 알아보았습니다. 해당 포스트에서 소개한 3가지 외에도 다양한 브랜치 전략이 존재합니다. 각자 프로젝트의 성격에 따라 적합한 브랜치 전략을 도입해보면 좋을 것 같습니다 👍

.css-y59011{position:relative;}.css-y59011::after{content:"";position:absolute;right:0;bottom:0;width:0;height:2px;background-color:var(--color-secondary);-webkit-transition:width 200ms ease-in-out;transition:width 200ms ease-in-out;} CI/CD 시나리오 구성하기

브랜치 전략 바꾸기

CI/CD 시나리오 구성하기