Gitlab CI/CD

배지원·2022년 12월 20일
1

CI/CD

목록 보기
1/2

1. 정의

CI란?

  • Continuous Integration 즉, 지속적인 통합이라는 의미이다.
  • 지속적인 통합이란, 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트 되어 공유 레포지토리에 통합하는 것을 의미한다.
  • 다수의 개발자들이 형상관리 툴을 관리할때 사용한다.
  • 주요기능 : 새로운 코드의 빌드, 테스트, 병합

CD란?

  • 개발자의 변경 사항이 레포지토리를 넘어, 고객의 프로덕션 환경까지 릴리즈되는 것을 의미한다.
  • 주요기능 : 배포 자동화

CI/CD의 장점

  • 개발자가 매번 직접 빌드 / 테스트 / 배포하면 시간이 오래걸린다. 따라서 CI/CD 기능을 지원하는 프로그램을 실행하여 자동화된 자동화된 빌드 / 테스트 / 배포 과정으로 에러를 쉽게 찾아내고 시간을 단축할 수 있다.


2. 실습

  • CI/CD를 지원하는 여러 프로그램(Jenkins, CircleCI, Travis CI...)중 GitLab을 사용하도록 하겠다.

Gitlab 프로젝트 업무흐름

(1) PM은 프로젝트를 같이 진행하는 사람들끼리 팀을 이루기 위해 그룹을 생성한다.

(2) 그룹으로 팀원들을 초대한다.

(3) 같이 진행할 프로젝트를 생성한다.

(4) 마일스톤을 통해 프로젝트에서 주요한 이벤트를 표시하고 프로젝트의 진척을 관찰을 한다.

(5) PM은 각 팀원들에게 각자 담당할 기능(이슈)들을 구분하여 할당해준다.

(6) 각 조원들은 PM이 올린 Main Code를 Clone하여 받아와 Branch를 통해 자신의 담당 기능의 코드를 올릴 공간을 만든다(만약 Clone하여 받은 Main부분에 그대로 코드 작성을 하면 오류가 발생했을때 되돌리기가 힘들어짐, 또한 코드가 엉켜져서 나중에 전부 갈아 엎을 수 도 있음)

(7) 각 조원들은 실시간으로 기능(이슈)에 대한 진행결과를 표시하고, 최종 구현된 기능(이슈)들은 PM이 Close하여 완료 처리한다.


(1) 프로젝트 생성


(2) Pipeline 만들기

  • 파이프라인 : CI/CD의 최상위 구성 요소이다. 파이프라인은 다음을 구성된다.
    => 수행할 작업을 정의하는 Jobs(코드를 컴파일하거나 테스트하는 작업)
    => 작업을 실행할 시기를 정의하는 Stage(코드를 컴파일하는 단계 후에 테스트를 실행하는 단계)
  • Job은 runner에 의해 실행된다. 한 단계의 모든 작업이 성공하면, 파이프라인은 다음 단계로 넘어간다. 만약 실패하면, 다음 단계는 실행되지 않고 파이프라인이 종료된다.

- .gitlab-ci.yml 파일은 CI/CD Job을 정이하는 곳이다. 해앋 파일은 Repository의 루트에 있어야 하며 파일을 Repository에 Commit하면 Runner가 Job을 실행한다. - 해당 파일에서는 Runner가 실행해야 하는 작업(Job)의 구조와 순서, 특정 조건이 발생할 때 Runner가 내려야 하는 결정을 정의한다.

(3) Member 초대

- Owner : 그룹이나 프로젝트를 생성한 최고 책임자로 모든 권한을 가지고 있고 팀원들에게 직책과 할 일을 부여해준다. - Maintainer : 그룹, 프로젝트 수정/삭제, 그룹 회원 관리등 일부 기능을 제외한 나머지 기능들의 권한을 가지고 있다. - Developer : 개발이나 유지보수를 하는 개발자에게 부여함. 브랜치를 통해 Code를 작성하여 업로드할 수 있지만 Main 브랜치에는 Push할 권한이 없음. 따라서 요청(Pull Request)만 하고 Maintainer와 Owner가 코드 리뷰를 한 후 Merge(합침)를 함

(4) Issue 등록

  • Issue란 프로젝트 책임자가 멤버별로 해야하는 업무(기능)를 부여하는 것으로 미리 기능들에 대한 내용을 작성하고 멤버를 지정하여 해당 멤버에게 지정한 Issue를 구현할 수 있도록 한다.

- 부여 받은 멤버는 Label을 통해 실시간 진행현황을 알려준다.

(5) Pull Request

- PM에게 할당받은 기능을 처리하기 위해서는 Main Code를 Clone하여 새 Branch를 만들고 그곳에 코드를 작성해야 한다.
  • 코드를 모두 작성하고 나면 REVIEW AND APPROVE를 하고 난 후 정말 고칠것이 없는 완성된 코드라 생각이 될때 PM에게 Pull Request를 보내고 PM은 한번 더 Master Branch에 합쳐도 되는 완성된 코드인지 확인한 후 괜찮다면 Merge를 통해 Branch에 있는 코드와 Master Branch를 합친다.
Pull Request란?
  • 작업을 할당 받은 팀원이 Branch를 따서 개발한 것을 Master Branch에 병합(Merge) 해달라고 PM에게 요청하는 것

(5.1) Master Branch Clone 하기

- PM이 Gitlab에 올린 Master Branch를 Clone버튼을 눌러 Code를 복사한다.

(5.2) Branch 생성

- 코드를 Clone했으면 꼭 New Branch 를 통해 자신만의 Branch를 생성한다.

- 현재 PM에게 로그인 기능을 할당 받았으니 Login으로 Branch를 생성하고 CheckOut-Branch를 선택하여 #2-Create-Join Branch에서 작업할 수 있도록 한다.

(5.3) Branch에 Push하기

- 할당된 기능(이슈)의 Code를 작성을 다 했다면 Commit 후 Push를 진행하면 되는데 이때, 현재 브랜츠가 자신이 생성한 브랜치인지 확인을 꼭 해야 한다.

- 개인 브랜치로 Push를 하고 나면 자동으로 Gitlab에 해당 브랜치가 추가된 것을 알 수 있다.

(5.4) Merge Request(Pull Request)하기

- 모든 기능을 구현하여 Main Code로 자신의 코드를 합치고 싶을때는 자신이 설계한 코드의 내용을 작성해주고 Merge Request(Pull Request)를 해준다. - 이때, 바로 PM에게 합쳐달라고 요청하는 것보단 관리자와 리뷰어에게 검사를 한번 맡고 합치는 것이 좋은 방법이기 때문에 관리자와 리뷰어, 진행상태를 설정해 코드리뷰를 받는다.

- Merge Request(Pull Request)를 하게 되면 관리자와 리뷰어에게는 요청알림이 가게 된다.

(5.5) Code Review

- 관리자와 리뷰어들은 요청된 코드를 보고 코드 리뷰를 할 수가 있다. 원하는 코드 옆에 말풍선을 클릭해 메세지를 작성할 수 있다.

- 또한 관리자와 리뷰어, 코드 작성자끼리 질문을 하고 답변을 해주며 첨삭을 해준다.

(6) Merge

  • Code Review후 Main Branch에 해당 Branch를 반영하는 것

- PM은 팀원이 Pull Request를 하면 해당 내용을 다른 팀원들과 코드리뷰 후 더 이상 오류가 없다고 판단되면 Merge버튼을 눌러 Main Code와 Branch Code를 합칠 수 있다.

- 이후 Intellij에서 Git Log를 통해 확인하면 성공적으로 Branch작업을 통해 Merge가 된것을 확인할 수 있다.
profile
Web Developer

0개의 댓글