CI/CD와 Gitflow 그리고 QA

SSunny 23.11.22

4,007 30 6

facebook twitter kakao link

30 6

facebook twitter kakao link

DEVOTEE 요약: 지속적 통합(CI)은 개발자들이 자동화된 빌드 및 테스트를 통해 코드를 공유 저장소에 계속 병합해나가는 방식으로, 소프트웨어 품질 개선과 업데이트 속도를 향상시키는데 중점을 둡니다. 반면 지속적 전달(CD)은 개발된 서비스가 사용자에게 배포되는 과정으로, 자동화된 테스트를 이용해 업데이트를 검증하고 문제를 때때로 검출해냅니다. 이 두 과정은 GitHub에서 Vincent Driessen이 제안한 GitFlow 모델에 기반하며, 이는 여러 가지 브랜치(feature, develop, release, hotfix, master)를 사용해 저장소를 관리하도록 돕습니다.

DEVOTEE 추천 블로그

지속적 테스트에 빈번하게 등장하는 단어는 CI와 CD가 있습니다.

CI 는 이름 그대로 지속적 통합 (Continuous Integratioin)으로 지속적으로 개발자의 작업물(코드)이 완성된 상태의 서비스가 되도록 merge되는 프로세스를 의미합니다.

지속적 통합은 자동화된 빌드 및 테스트가 수행된 후, 개발자가 코드 변경 사항을 중앙 리포지토리에 정기적으로 병합하는 데브옵스 소프트웨어 개발 방식입니다.

지속적 통합은 소프트웨어 릴리스 프로세스 중 빌드 또는 통합 단계를 주로 가리키며,

자동화 구성 요소(예: CI 또는 빌드 서비스)와 문화적 구성 요소(예: 빈번하게 통합하도록 학습) 모두를 포함합니다.

지속적 통합의 핵심 목표는 버그를 신속하게 찾아 해결하고, 소프트웨어 품질을 개선하고, 새로운 소프트웨어 업데이트를 검증 및 릴리스하는 데 걸리는 시간을 단축하는 것입니다.

CD는 지속적 전달(Continuous Delivery)로 이 서비스가 사용자에게 배포되는 프로세스를 의미합니다.

지속적 전달(Continuous Delivery)은 프로덕션에 릴리스하기 위한 코드 변경이 자동으로 준비되는 소프트웨어 개발 방식입니다.

현대 애플리케이션 개발의 기반인 지속적 전달은 빌드 단계 이후의 모든 코드 변경을 테스트 환경 및/또는 프로덕션 환경에 배포함으로써 지속적 통합을 확장합니다.

적절하게 구현할 경우, 개발자는 언제나 즉시 배포할 수 있고 표준화된 테스트 프로세스를 통과한 빌드 아티팩트를 보유할 수 있습니다.

지속적 전달에서는 개발자가 단순한 유닛 테스트 외에도 다양한 테스트를 자동화할 수 있으므로,

고객에게 배포하기 전에 여러 차원에서 애플리케이션 업데이트를 확인할 수 있습니다.

이러한 테스트에는 UI 테스트, 로드 테스트, 통합 테스트, API 안정성 테스트 등이 포함될 수 있습니다.

이를 통해 개발자는 업데이트를 좀 더 철저히 검증하고 문제를 사전에 발견할 수 있습니다.

온프레미스에서는 힘들었지만, 클라우드에서는 테스트용으로 여러 개의 환경을 생성하고 복제하는 작업을 비용 효율적으로 손쉽게 자동화할 수 있습니다.

Gitflow는 Vincent Driessen의 branching model을 적용해 고수준으로 저장소를 관리할 수 있게 해주는 확장 기능입니다.

이를 통해 데브옵스를 수행합니다.

이 모델은 feature - develop (dev) - release - hotfix - master 단계로 브랜치를 나눠 코드를 관리하는 전략입니다.

master : 제품으로 출시될 수 있는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치
feature : 기능을 개발하는 브랜치
release : 이번 출시 버전을 준비하는 브랜치
hotfix : 출시 버전에서 발생한 버그를 수정 하는 브랜치

GitFlow 지침은 다음과 같습니다.

develop을 지속적 통합 브랜치로 사용합니다.
feature 브랜치를 사용하여 여러 기능에 대한 작업을 수행합니다.
release 브랜치를 사용하여 특정 릴리스에 대한 작업을 수행합니다(다중 기능).
master에서 분기된 hotfix 브랜치를 사용하여 핫픽스를 푸시합니다.
매 출시 후 master로 병합합니다.
master는 프로덕션 준비 상태의 코드를 포함합니다.

Gitflow 설치

git-flow를 설치하기 위해서는 우선 git이 설치되어 있어야 합니다. git-flow를 설치하면 git 저장소를 git-flow에 맞게 초기화할 수 있습니다

brew install git-flow-avh

Gitflow 초기화

git-flow를 사용하기 위해서는 git 저장소를 git-flow에 맞게 초기화해야 합니다. 어떤 브랜치를 어떤 용도로 사용할 것인지 등을 명시하게 됩니다.

git flow init

혹은 

git flow init -d 
Using default branch names.

Which branch should be used for bringing forth production releases?
   - main
Branch name for production releases: [main] 
Branch name for "next release" development: [develop] 

How to name your supporting branch prefixes?
Feature branches? [feature/] 
Bugfix branches? [bugfix/] 
Release branches? [release/] 
Hotfix branches? [hotfix/] 
Support branches? [support/] 
Version tag prefix? [] 
Hooks and filters directory? [/Users//gitflow/robot_example/.git/hooks]

master 브랜치

이 워크플로우에서는 두 개의 브랜치를 변경 이력을 유지하기 위해 사용합니다.

master브랜치는 릴리스 이력을 관리하기 위해 사용합니다.

develop 브랜치

이 워크플로우에서는 두 개의 브랜치를 변경 이력을 유지하기 위해 사용합니다.

develop브랜치는 기능 개발을 위한 브랜치들을 병합하기 위해 사용합니다.

Feature 브랜치

새로운 기능을 위한 feature 브랜치는 develop 브랜치의 HEAD에서 생성됩니다.

새로운 기능 개발이나 버그 수정을 위한 일련의 코드 수정이 이뤄지는 브랜치입니다.

이 브랜치에서 개발자 혼자 작업을 할 수도 있고, 특정 기능 개발을 위한 여러명의 개발자들이 공동으로 작업할 수도 있습니다.

develop 브랜치에서 작업된 내용은 최종적으로 PR을 거쳐 develop 브랜치에 병합(Merge)됩니다.

$ git flow feature start <feature name>

생성된 브랜치는 feature/의 이름이나 git flow init에서 feature 브랜치 이름으로 입력한 문자열이 feature 저장됩니다.

github 같은 플랫폼에 feature 브랜치를 push하려면 아래 명령을 수행합니다.

$ git flow feature publish <feature name>

반대로 원격 저장소에서 feature branch를 가져오려면 아래 명령을 수행합니다.

$ git flow feature pull origin <feature name>

개발과 커밋을 수행하고 종료시에는 아래 명령어 완료합니다.

$ git flow feature finish <feature name>

이 때 gitflow는 develop 브랜치로 checkout, feature 브랜치의 변경사항을 merge, feature 브랜치를 삭제를 수행합니다.

Release 브랜치

release 브랜치는 릴리즈를 하기 위한 목적으로 생성되는 브랜치입니다.

release 브랜치는 develop 브랜치를 기반으로 생성됩니다. 다음 릴리즈에 포함되어야 하는 기능셋과 버그픽스들이 확정된 다음 생성됩니다.

릴리즈 브랜치가 생성된 다음 QA 테스트가 릴리즈 브랜치를 기준으로 진행됩니다.

이 과정에서 발견된 버그 수정 사항들이 release 브랜치와 develop 브랜치에 적용되며, 그 밖에 메이저 기능들이 중간에 추가되지는 않습니다.

테스트 이후 release 브랜치의 코드가 안정적이라고 판단되면, master 브랜치에 병합되고 릴리즈에 해당하는 태그가 생성됩니다.

release 브랜치는 release-*또는 release/*과 같은 이름을 가지는 것이 일반적인 관례입니다.

release/version 이라는 브랜치가 생성합니다.

$ git flow release start <version>

git flow init 수행시 release 브랜치 이름으로 다른 문자열을 입력했으면 그 문자열이 release 대신 설정된다.

feature 브랜치와 유사하게 원격 저장소로 보내기 혹은 가져오기올 수 있습니다. 이때 명령어를 주의합니다.

$ git flow release publish <version>
$ git flow release track <version>

릴리즈 완료하려면 아래 명령을 수행합니다.

$ git flow release finish <version>

이를 통해 release 브랜치를 master 브랜치에 병합(merge) 하고 release 버전을 태그로 생성합니다.

이 때, git flow init 에서 명시한 Version tag prefix 문자열이 release버전 앞에 태그됩니다.

이후 release 브랜치를 develop 브랜치에 병합되고 release 브랜치를 삭제됩니다.

이제 새로운 릴리즈가 포함된 master 브랜치를 원격 저장소에 태그들과 함께 push하여 완료합니다.

$ git push --tags

Hotfix 브랜치

hotfix 브랜치는 정기적인 릴리즈 이외에 긴급하게 수행되어야 할 버그 수정을 반영하기 위해 생성되는 브랜치입니다.

다음 릴리즈 프로세스를 기다릴 수 없을 정도로 긴급한 패치가 바로 반영되어야 하는 경우 이 브랜치를 사용합니다.

hotfix 브랜치는 master 브랜치를 기반으로 생성됩니다. 생성된 hotfix 브랜치에 긴급한 패치들이 반영됩니다.

이후 hotfix 브랜치는 master 브랜치에 병합되고 태그 생성이 됩니다.

마찬가지로 수정 사항은 develop 브랜치로도 병합되어 긴급 수정 사항이 이후 릴리즈에도 반영되도록 합니다

긴급 패치를 위한 hotfix 브랜치 생성도 릴리즈 브랜치와 유사합니다.

$ git flow hotfix start <version>.

이제 긴급하게 패치할 버그 수정사항들을 이 브랜치에 반영한 다음 finish 명령으로 핫픽스를 완료합니다.

$ git flow hotfix finish <version>

hotfix 브랜치를 master 브랜치로 병합한다. git flow init 에서 명시한 Version tag prefix 문자열이 hotfix 버전 앞에 추가되어 태그로 생성됩니다.

이후 hotfix 브랜치를 develop 브랜치에 병합하고 hotfix 브랜치를 삭제됩니다.

AWS gitflow

AWS에서 gitflow를 지원하는 서비스를 살펴봅니다.

AWS는 AWS CodePipeline, AWS CodeCommit, AWS CodeBuild 및 AWS CodeDeploy를 사용하여 GitFlow를 모델링합니다.

이를 통해 feature/release/hotfix 브랜치 작업을 수행하고 협업, 테스트 및 배포 변경을 빠르게 수행할 있는 환경을 제공하기 위해 CI/CD 전략수행합니다.

각 브랜치별로 파이프라인을 생성하는 것이 핵심입니다

각 브랜치는 AWS CodePipeline을 가집니다.
AWS CodePipeline은 AWS CodeCommit가 소스 제공자로, AWS CodeBuild가 빌드 제공자로, AWS CodeDeploy가 배포 제공자로 구성됩니다.
AWS CodeBuild는 AWS CodePipeline이 소스로 구성됩니다.
각 AWS CodePipeline은 배포를 위해 이름 태그를 사용하는 AWS CodeDeploy 배포 그룹을 가집니다.
단일 Amazon S3 버킷이 아티팩트 스토어로 사용되지만 리포지토리 기반의 개별 버킷을 유지할 수 있습니다.