TIL) 효율적인 개발 프로세스 CI/CD, CI/CD를 위한 다양한 Tools

 

►배포 자동화 파이프라인 : 소스 코드의 관리부터 실제 서비스로의 배포 과정을 연결하는 구조.

 

1. Source 단계 : 원격 저장소에 관리되고 있는 소스 코드에 변경 사항이 일어날 경우, 이를 감지하고 다음 단계로 전달하는 작업을 수행

2. Build 단계 : Source 단계에서 전달받은 코드를 컴파일, 빌드, 테스트하여 가공한다. 이 단계를 거쳐 생성된 결과물을 다음 단계로 전달하는 작업을 수행한다. 

3. Deploy 단계 : Build 단계로부터 전달받은 결과물을  실제 서비스에 반영하는 작업을 수행한다. 

 

---

►CI/CD 파이프라인

✔️ 지속적 통합 (CI : continuous integration)

팀 구성원이 각자의 작업을 자주 통합하는 소프트웨어 개발 방식.

Code : 개발자가 코드를 코드 저장소에 push & merge / 모든 개발팀이 코드 변화 확인가능(투명함)

Build : 코드 저장소로부터 코드를 가져와서 (유닛 테스트 후) build

Test : 코드 빌드의 결과물이 다른 컴포넌트와 잘 통합되는지 확인

 

** 빌드는 개발자만 읽을 수 있는 소스 코드를 실행가능한 코드 및 프로그램으로 변환하는 과정이다. 

번들링도 브라우저가 소스코드를 더 잘 읽을 수 있게 도와주기 때문에, 빌드 과정 중 하나로 볼 수 있다. (빌드라고 통용되기도 함.)

 

장점

1. 개발 생산성 향상 = 주기적으로 merge를 하기 때문에 merge 충돌을 피할 수 있다. 

2. 문제점을 빠르게 발견 = merge되는 모든 코드들은 자동으로 build되고, test 되기 때문에 코드의 결함이나 문제점을 빠르게 알 수 있다. 

3. 2에서 발견된 문제점 빠르게 수정 가능 = 주기적으로 merge를 하기 때문에, 코드의 변경 사항이 작기 때문에 문제를 수정할 때도 작은 단위의 문제점을 확인 가능해서 버그를 빠르게 수정할 수 있다. 

4. 코드의 퀄리티 향상 = CI를 잘 운영하기 위해서 unit test를 포함해야 하기 때문이다. 

 

✔️ 지속적 배포 (CD : continuous delivery / deployment)

지속적 통합 과정이 원활하게 끝나면 바로 고객에게 배포하는 것.

Release : 빌드까지 모두 준비되었고, 어떤 기능이 개발되었는지 비즈니스 관계자들과 이야기를 나누는 단계.

어떤 기능을 넣을지, 해당 릴리즈는 배포를 할지 말지 결정하는 단계로 여러 의사결정이 이루어진다. 

Deploy : 배포

Operation : 배포된 소프트웨어를 실제 운용하는 과정. 고객의 피드백을 충분히 받아 기획에 반영한다. 

 

요즘에는 버전 릴리즈를 잘 기록해두고 바로바로 배포하는 사례가 증가하고 있다. 

---

►결론

더 자주 코드를 합치고, 더 자주 결과물을 확인하자, 더 자주 고객에게 보여주자!

=> 위의 프로세스를 자동화해야한다. 

hello world라도 있으면 main branch에 pull request에 merge 할 때마다 배포하는걸 추천함.

---

►CI/CD를 위한 다양한 Tools!

 

Buildkite

GitHub Actions

GitLab CI/CD

Bitbucket Pipelines

circleci

Vercel

Netlify

 

 

😃 잘못된 개념 전달이 있다면 댓글 부탁드립니다. 저의 성장에 큰 도움이 됩니다🤓