CI/CD

CI/CD

• CI/CD 기본 개념은 지속적인 통합(Continuous Integration), 지속적인 서비스 제공(Continuous Delivery), 지속적이 배포(Continous Deployment)의 합성어이다.
• CI/CD는 애플리케이션 개발 단계를 자동화하여 애플리케이션을 보다 짧은 주기로 고객에게 제공하는 것이 목적이다.
• 새로운 코드 통합으로 인해 개발 및 운영 팀에 발생하는 문제(Integration Hell)를 해결하기 위한 방법

지속적인 통합

• 개발 팀이 작은 변경 사항을 구현하고 코드를 버전 제어 레포지토리에 자주 체크인 하도록 하는 코딩 철학이자 일련의 관행
• 대부분의 최신 애플리케이션은 다양한 플랫폼과 도구에서 코드를 개발해야 하기 때문에 팀은 변경 사항을 통합하고 검증하기 위한 매커니즘이 필요하다.
• 기술 목표는 애플리케이션을 빌드, 패키지 및 테스트하는 일관되고 자동화된 방법을 설정하는 것
• 통합 프로세스의 일관성을 유지하면 팀이 코드 변경을 더 자주 커밋할 가능성이 높아서 공동 작업과 소프트웨어 품질이 향상된다.
• 소프트웨어 공학에서 지속적 통합은 지속적으로 품질 관리를 적용하는 프로세스를 실행하는 것이다.
• 작은 단위의 작업, 빈번한 적용, 지속적인 통합을 이용해서 소프트웨어 질적 향상과 소프트웨어 배포하는데 걸리는 시간을 줄이는 것에 초점을 맞춘다.
• 지속적인 통합 과정
  • Coding → Merge → Build → Test → Report → Release

Continous Delivery & Continuous Deploy

• 지속적인 제공
  • 개발자들이 애플리케이션에 ㅈ거용한 변경 사항이 버그 테스트를 거쳐 레포지토리에 자동으로 업로드 되는 것
  • 운영팀은 이 레포지토리에서 애플리케이션을 실시간 프로덕션 환경으로 배포한다.
  • 개발팀과 비즈니스팀 간의 가시성과 커뮤니케이션 부족 문제를 해결한다.
  • 최소한의 노력으로 새로운 코드를 배포하는 것이 목적이다.
• 지속적인 배포
  • 개발자의 변경 사항을 레포지토리에서 고객이 사용 가능한 프로덕션 환경까지 자동으로 릴리스하는 과정
  • 정적 분석: 된다 안 된다가 아니라 이 코드의 품질을 평가해주는 것
  • 소스 코드 올려 놓는 것: scm (형상 관리 툴)

버전 관리 시스템 (형상 관리 시스템)

• 파일의 변화를 시간에 따라 기록한 후 과거 특정 시점의 버전을 다시 불러올 수 있는 시스템
• 형상 관리는 모든 변경 사항을 관리하는 것
• 모든 컴퓨터 파일이 버전 관리의 대상
• 이미지나 레이아웃을 수정할 때마다 각각의 형태를 모두 보존하고 싶은 그래픽 디자이너나 웹 디자이너라면 버전 관리 시스템을 사용하는 것이 현명한 선택이 될 수 있다.
• 버전 관리 시스템을 사용하면 개별 파일 혹은 프로젝트 전체를 이전 상태로 되돌리거나 시간에 따른 변경 사항을 검토할 수 있으며 문제가 되는 부분을 누가 마지막으로 수정했는지 누가 언제 이슈를 만들어 냈는지 등을 알 수 있다.
• 복구 가능

종류

• 로컬 버전 관리 시스템
  • 간단한 DB에 변경 사항을 기록하는 방식인데 DB의 위치가 현재 로컬 컴퓨터이다.
  • Max OS X 에서 사용되는 RCS라고 불리우는 시스템이 대표적인데 개발 도구를 설치하면 자동으로 설치되고 기본적인 동작 방식은 각 리비전들 간의 patch set이라고 하는 데이터의 차이점들을 특별한 형식의 파일에 저장하고 특정 시점의 파일을 사용하고자 하는 경우 해당 시점까지의 패치들을 모두 더하여 파일을 만들어내는 방식이다.
• 중앙 집중식 버전 관리 시스템(클라이언트 서버 모델)
  • 외부에 있는 개발자와 협업 문제를 해결하기 위해서 개발한다.
  • CVS, Subversion, Perforce와 같은 시스템들이 대표적이다.
  • 모든 파일을 저장하는 하나의 서버와 이 중앙 서버에서 파일을 가져오는 (checkout) 다수의 클라이언트가 존재한다.
  • 오랫동안 사용된 이 방식은 지금도 버전 관리의 대표적인 방식이다.
  • 서버가 잘못되면 모든 것이 잘못된다.
• 분산 버전 관리 시스템
  • Git, Merqurial, Bazzar, Darcs 등이 대표적인데 클라이언트가 파일들의 마지막 스냅샵을 가져오는 대신 저장소를 통째로 복제해서 서버에 문제가 생겨도 어느 클라이언트든 복제된 저장소를 다시 서버로 복사하면 서버가 복구되는 형태로 checkout을 할 때마다 전체 백업이 일어나는 형태이다.
  • 다수의 원격 저장소를 갖는 것이 가능하기 때문에 동시에 여러 그룹과 여러 방법으로 함께 작업할 수 있어서 계층 모델 등 중앙 집중 시스템에서는 할 수 없는 다양한 작업 방식을 사용해 볼 수 있다.

Git

• 2005년에 리눅스 커널 개발을 위해 초기 개발에 기여한 다른 커널 개발자들과 함께 개발
• 가장 많이 사용하기 때문에 많은 숫자의 Tutorial과 Project가 존재한다.
• 컴퓨터 파일의 변경 사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 버전 관리 시스템 중 하나
• 장점
  • 이력 기록 및 추적
  • 서버 역할을 수행하는 원격 저장소와 개발자의 로컬 저장소에 소스 코드와 변경 이력을 분산 저장하기 때문에 원격 저장소에 문제가 생겨도 로컬 저장소를 이용해서 복원이 가능하다.

Git Hub

• Ruby on Rails로 작성된 분산 버전 관리 툴인 git의 원격 저장소 호스팅 서비스
• 영리적인 목적의 서비스와 오픈 소스를 위한 무상 서비스를 모두 제공
• 가장 많이 사용되는 git 저장소 호스팅 서비스
• git은 텍스트 명령어 입력 방식인데 git hub은 GUI를 제공한다.
• git hub는 깃 프로젝트 저장소 역할 외에도 다양한 기능을 제공하는데 git hub action과 git hub deployment API를 이용해서 빌드 및 배포 자동화를 구성할 수 있고 Project Boards를 이용해서 프로젝트 협업도 가능하다.

Git Lab

• Ruby on Rails로 만들어진 오픈소스 저장소 솔루션
• 비공개 저장소를 참여 인원 수에 관계 없이 무제한으로 생성할 수 있어서 최근에 기업들이 많이 사용한다.
• 저장소의 최대 용량이 5GB
• git hub 보다 훨씬 체계적인 이슈 트래커 기능과 CI 서비스를 제공한다.
• Git Lab CE나 Git Lab EE라는 설치형 소프트웨어가 있고 Git Lab CE는 무료이고 EE는 유료이다.
• 비용 대비 저장 용량이 크다.
• 로컬 서버 시스템으로 전환이 가능하다.

원격 저장소와 로컬 저장소

• 로컬 저장소
  • 내 PC에 파일이 저장되는 개인 전용 저장소
  • 직접 만들거나 원격 저장소를 로컬 저장소로 복사해서 사용한다.
• 원격 저장소
  • 파일이 원격 저장소 전용 서버에서 관리되며 여러 사람이 공유하기 위한 저장소

Git 설치

• Git을 GUI 환경에서 사용하기 위한 sourcetree 설치
• 설치 확인 git --version
• 기본 브랜치 이름 설정
  • branch: 저장소 안의 구분을 위한 논리적인 단위
  • 초창기 git의 기본 브랜치 이름이 main이었는데 지금은 master로 변경되었고 아직 git hub 등은 main을 기본 브랜치로 사용한다.
  • git config --global init.defaultBranch main
• 사용자 설정: 이 설정을 하지 않으면 commit이 안 된다.
  • 현재 프로젝트에 등록
    • git config user.name 사용자이름
    • git config user.email 사용자이메일
  • 모든 프로젝트에 적용
    • git config --global user.name 사용자이름
    • git config --global user.email 사용자이메일
  • 설정 값 확인
    • git config --list
• 3가지 작업 영역
  • Working Directory
    • 이력 관리 대상(tracked) 파일들이 위치하는 영역
    • 저장소 디렉토리에서 .git 디렉토리를 제외한 공간
    • 작업 중인 파일이나 코드가 저장되는 공간
    • Work Tree 라고도 한다.
  • Staging Area
    • 이력을 기록할(Commit) 대상 파일들이 위치하는 영역
    • .git 디렉토리 하위의 파일 형태로 존재한다.
  • Local Repository
    • 이력이 기록된(Commited) 파일들이 위치하는 영역
    • .git 디렉토리에 이력 관리를 위한 모든 정보가 저장되고 관리된다.
• commit
  • 파일 및 디렉토리의 추가 변경 사항을 로컬 저장소에 기록하는 것
  • Commit을 수행하면 이전 Commit 부터 현재 상태까지의 변경 이력이 기록된 Revision이 생성된다.
  • Commit은 순서대로 저장되기 때문에 최근 Commit부터 거슬러 올라가면 과거 변경 이력과 내용을 알 수 있다.
  • 각 리비전에는 영문과 숫자 조합으로 이루어진 40자리 고유 이름이 붙는데 저장소에서 이 40자리 이름을 보고 각 Revision을 구분하고 선택한다.
  • Commit은 이력을 남기는 중요한 작업이라서 Commit을 수행할 땐 필수로 commit message를 작성해야 하는데 메시지가 없으면 commit이 실행되지 않는다.
  • 권장하는 메시지 형식
    • 첫 번째 줄: Commit 내의 변경 내용을 요약
    • 두 번째 줄: 빈 칸
    • 세 번째 줄: 변경한 이유
• 작업 흐름
  • git init → 작업 디렉토리 생성 → git add → 작업 디렉토리에서 staging 영역으로 이동 → git commit → 로컬 저장소에 기록 → git push → 원격 저장소에 저장
    • 이때 git push 대신에 pit pull을 하게 되면 원격 저장소의 내용이 로컬 저장소에 저장되고 git clone은 원격 저장소의 내용을 다운로드 받는 것이다.
• Working 디렉토리에서 관리되는 파일의 상태
  • Modified: 관리 중인 파일에 수정 사항이 감지되었지만 커밋이 되지 않은 상태
  • Staged: 감지된 파일의 수정 사항이 Staging Area로 이동된 상태
  • Commited: 파일의 수정 사항에 대한 이력 저장이 완료된 상태
  • Untracked: 저장소에서 관리되지 않는 파일
• Source Tree를 이용한 작업
  • 로컬 저장소 생성
    • 저장소로 사용할 디렉토리를 결정
    • 소스트리에서 로컬을 선택하고 Create를 눌러서 디렉토리를 연결 → 저장소가 생긴다.
      • 저장소로 만들어지면 .git 이라는 디렉토리가 생성되고 모든 정보를 .git에 저장한다.
      • 로컬 저장소 해제는 .git 디렉토리를 삭제하면 된다.
  • 버전을 관리할 텍스트 파일 생성 (텍스트 파일을 만들 때 주의할 점은 마지막에 줄 바꿈을 안 하면 스테이지에 올릴 때 경고 메시지가 출력된다.)
    • a.txt
    • b.txt
    • c.txt
  • 파일을 선택하고 스테이지 올리기를 선택하면 변경 사항을 기록할 파일로 변경이 되고 스테이지 영역에 변경 내역을 기록한다.
  • 스테이지에 올라가 있는 파일을 선택하면 변경 내역을 확인할 수 있다.
  • 커밋 메시지를 작성하고 commit 버튼을 누르면 로컬 저장소에 반영된다.
  • 커밋 내역은 History 버튼을 누르면 알 수 있다.
  • 새로운 커밋을 만들기 위해서 a.txt를 수정하고 c.txt를 삭제
  • 파일을 하나 추가하고 commit
  • tracked와 untracked 상태 파일
    • tracked 파일은 변경 사항을 추적하는 파일(스테이지에 올라간 파일)
    • untracked 파일은 변경 사항을 추적하지 않는 파일
• .gitignore
  • 버전 관리 대상에서 제외하고 싶은 파일이나 디렉토리 즉 변경 사항이 생기더라도 버전에 포함하고 싶지 않은 파일이나 디렉토리가 있다.
  • 변경 사항을 추적하고 싶지 않은 파일이나 디렉토리를 .gitignore에 작성을 해서 무시할 수 있다.
  • git add 명령을 이용해서 stage area에 올라갈 파일이나 디렉토리를 결정하는데 일일이 작성하는 것은 번거로운 일이라서 보통은 git add . 으로 현재 디렉토리에 모든 내용을 staging area에 올려 놓는 형태로 하고 이때 제외하고자 하는 파일이나 디렉토리를 .gitignore에 작성한다.
  • 라이브러리나 외부 모듈 등을 보통 제외한다.
  • e.txt 파일을 생성하고 .gitignore에 e.txt 를 작성하면 파일 상태에 e.txt가 없다.
  • ignore 디렉토리를 생성하고 .gitignore에 추가해도 똑같음
• 커밋 자세히 보기
  • 커밋 해시: 커밋을 구분하기 위해서 부여하는 ID
  • 상위 항목: 어떤 커밋으로부터 생성되었는지 알려주는 값
  • 커밋에는 태그라고 항목을 추가해서 이 커밋이 어떤 작업을 수행했는지 또는 버전 같은 것을 표시하기도 한다.
  • 태그를 만들 때는 vX.Y.Z (X가 메이저 버전이고 두 번째는 마이너 버전, 세 번째 숫자는 Patch)