서론

프로젝트에서 개발을 진행하며 사용자들에게 서비스를 배포하기까지는 개발, 테스트, 빌드, 배포 등의 많은 과정들이 필요하다.
서비스를 한 번만 배포를 하면 이러한 과정을 수행하는 것이 문제가 없지만, 실제 서비스들은 추가적인 기능 개발과 예상하지 못한 오류 수정 등의 많은 코드의 변경이 필요하고 이러한 코드의 변경이 있을 때마다 위의 수많은 과정들을 반복해서 진행해야 할 것이다. CI/CD는 이러한 과정들을 자동화하여 애플리케이션을 짧은 주기로 사용자들에게 제공하고 개발자들이 빌드, 배포와 같은 작업에 투자하는 시간을 단축시켜주고 더욱더 편리하게 프로젝트를 진행시켜주는 필수적인 기술이다.
CI/CD 영역은 그동안 프로젝트를 해오며 내가 주로 담당했던 업무는 아니었지만 이번에 조금더 공부하고 기록해보며 기본기를 다져보려고 한다.

CI/CD란?

CI/CD는 지속적 통합(Continuous Integration) 및 지속적 제공/배포(Continuous Delivery/Deployment)를 의미하며, 소프트웨어 개발 라이프사이클을 간소화하고 가속화하는 것을 목표로 한다.

CI (Continuous Integration)

• CI는 개발자를 위한 자동화 프로세스인 지속적인 통합을 의미한다.
• CI는 통합을 위한 빌드 단계(빌드, 테스트, 머지)의 자동화를 제공
• CI는 코드 버전을 관리하는 VCS시스템(Git, SVN)을 통하여 자동으로 테스트와 빌드가 수행되어 안정적인 개발 과정을 제공한다.

  간단히 설명하면 빌드, 테스트, 통합(Merge)의 자동화이다.

CD (Continuous Deployment or Continuous Delivery)

• CD는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미한다.

지속적인 제공 (Continuous Delivery)

• 지속적인 제공은 CI의 작업을 거친 후, 리포지토리에 자동으로 업로드 되는 것을 뜻한다.

• 리포지토리에 업로드된 Release를 검증을 한 후, 애플리케이션을 실시간으로 프로덕션 환경에 수동으로 배포할 수 있다.

• 개발팀과 비즈니스 팀 간에 가시성과 소통 부족의 문제를 해결해준다.

• 지속적인 제공은 최소한의 노력으로 새로운 코드를 배포하는 것을 목표로 하고 있다.

  간단히 설명하자면 배포의 자동화이다.
  지속적 제공 프로세스를 구축하기 위해서는 개발 파이프라인에 CI를 먼저 구축하여야 한다.

지속적인 배포 (Continuous Deployment)

• Delivery와 다르게 Release를 검증,확인하지 않고 배포까지 자동화 해두는 것을 Continuous Deployment라고 한다.
• Delivery와 비슷하지만 최종 단계가 자동화가 되었는지, 안 되었는지에 따라 다르게 부른다.

정리

• CI/CD는 지속적 통합 및 지속적 제공(CD, Continuous Delivery)의 구축 사례만을 지칭할 때도 있고, 지속적 통합, 지속적 제공, 지속적 배포라는 3가지 구축 사례 모두를 의미하는 것일 수도 있다.
• 해당 용어는 사례별로 CI/CD 파이프라인에 구현된 자동화 수준 정도에 따라 그 의미가 달라지게 된다.
• 회사마다 어느정도로 자동화를 하는지가 다르기 때문에 CI/CD라고 하여서 모든 회사가 똑같은 프로세스를 거치는게 아니고 회사, 팀마다 다른 방식을 적용할 수 있다.

CI/CD의 대표적인 툴

Jenkins, Buildkite, Github Actions, GitLab CI/CD, Bitbucket Pipelines, Circleci 등이 있다.

Git이란?

• 여러 명의 개발자가 하나의 소프트웨어 개발 프로젝트에 참여할 때, 소스 코드를 관리하는데 주로 사용 된다.
• 소스 코드 버전 관리 시스템으로 로컬에서 변경 사항을 추적하고 원격 리소스에서 변경 사항을 푸시하거나 가져올 수 있다.

GitHub란?

• 깃(Git)을 사용하는 프로젝트를 지원하는 웹 호스팅 서비스.
• Github는 공개적으로 사용 가능한 무료 서비스로 모든 코드를 공개해야 한다.
• 다른 사람의 푸시한 코드를 보고 개선을 위한 제안을 제공할 수 있다. 오픈소스 역할
• Github는 현재 수만 개의 오픈 소스 프로젝트를 위한 소스 코드를 호스팅 한다.

GitLab이란?

• Gitlab은 개인 또는 조직이 Git repository 의 내부 관리를 제공하는데 상용할 수 있는 Github 으로 즉 비공개된 Github라고 할 수 있다.
• GitLab은 중앙 서버에서 Git 저장소를 관리하는 방법이다.
• GitLab은 리포지토리 또는 프로젝트를 완벽하게 제어 할 수 있으며, 공개 또는 비공개 여부를 무료로 결정할 수 있다.

GitLab과 GitHub 차이?

아래사진은 실무에서의 점유율이다.

데브옵스 요소

• GitLab은 지속적 통합/지속적 전달(CI/CD)와 데브옵스 워크플로우를 내장했다
• GitHub를 사용하면 사용자가 원하는 CI/CD 도구를 직접 통합해야 한다.
• GitHub가 속도를 우선시 한다면, GitLab은 안정성에 중점을 둔다.

브랜치

• GitHub에서는 브랜치 전략이라는 것이 있을 정도로 브랜치를 생성하고 합치는 것을 강조한다.
• GitHub는 새로운 브랜치를 마스터 브랜치와 병합하는 것이 용이하다.
• 그 덕에 신속한 배포가 가능하고, 문제 발생 시 이전 버전으로 신속하게 복원할 수 있는 장점도 있다.
• GitLab의 워크플로우는 변경한 각 세트를 마스터 브랜치와 별도의 안정적인 브랜치로 생성한다.
• 프로덕션과 스테이징의 분기가 최소한으로 있고 이런 다중 분기 접근방식은 여러 단계의 테스트 프로세스를 필요로 한다.
• 따라서 병합 요청 시 코드 검토가 까다로워진다.

소프트웨어 서비스

• GitHub는 자체적으로 깃랩보다 적은 수의 소프트웨어 서비스를 제공한다.
• 대신 외부 프로그램 및 서비스와 통합하는 쉬운 방법을 제공한다.
• GitHub 마켓플레이스에서 다양한 외부 서비스와 프로그램, GitHub와 통합을 위한 소프트웨어를 이용할 수 있다.
• GitLab은 완전한 소프트웨어 개발 솔루션을 제공하며, 올인원의 데브옵스 플랫폼이라고 강조한다.
• GitLab은 지라(Jira), 마이크로소프트 팀즈, 슬랙, G메일 같은 애프리케이션 및 플랫폼과 통합을 제공한다.

정리

• GitLab은 기업용으로 설계돼 기업이 미션 크리티컬 솔루션을 구축하는 데 최적화됐다
• GitLab은 SaaS(Software as a service)와 자체 관리형(Self-managed)으로 서비스를 유연하게 제공한다.
• GitLab은 단일 인터페이스를 지원해 엔지니어, 운영, 보안 담당자는 코드 품질, 배포 문제, 보안 취약점 데이터를 편리하게 분석할 수 있다.
• 이는 각 팀이 원활하게 협업하고, 소프트웨어를 더 안전하게, 더 많이, 더 빨리 릴리즈하는 데 도움이 됩니다.
• GitLab은 GitHub보다 AI 기능이 약 3배 더 많다.