MERGE 전략

feature → develop

• 같은 파트 내의 팀원이 모두 동의했을 경우
• 동의하는 경우 MR에 확인 메세지를 남긴다

develop → master

• CI/CD가 구축 되었다면, release로 1주일에 1회(권장) - 수요일
• 팀원 전체의 동의 필요

Branch Style Guide

Structure

feature/포지션/기능명

feature 브랜치 생성 기준 : 스토리

• 포지션 : FE/BE/DevOps/AI 로 구분
• 기능명 : 지라의 스토리 기능명을 작성, camelCase적용

예)

feature/FE/mainPage

Git flow / CICD

배포 사이클

• master : 리얼 서버에 배포되는 서비스
• hotfix : 리얼 서버에서 긴급상황 발생시 사용

개발 사이클

• develop : develop 개발메인 브랜치
• feature : feature/FE/issueName 형식으로 생성 기능개발 브랜치

Git flow

1. 스프린트 마다 feature들을 선정 및 작성한다.
2. develop에서 feature를 따서 작업을 한다.
3. 작업이 끝난 feature 는 develop 으로 머지된다.
4. 스프린트 단위로 작업이 끝나면 develop 에서 realease로 머지가 된다.(버전 관리)
5. release에서 QA 이상이 없을 시, 해당 버전이 master 로 배포가 된다.(이때, 병합한 커밋에 Release 버전 태그를 부여!)
6. QA에서 버그 발생시 hotfix 또는 다음 스프린트 계획으로 작업한다.

CI/CD

• CI : feature -> Test -> develop
• CD : release -> Deploy -> master

git flow 및 버전 관리 참고 자료

• https://gmlwjd9405.github.io/2018/05/11/types-of-git-branch.html
• http://woowabros.github.io/experience/2017/10/30/baemin-mobile-git-branch-strategy.html

CI/CD

CI /CD 란?

"CI"는 개발자를 위한 자동화 프로세스인 지속적인 통합(Continuous Integration)을 의미한다.

CI를 성공적으로 구현할 경우 애플리케이션에 대한 새로운 코드 변경 사항이 정기적으로 빌드 및 테스트되어 공유 리포지토리에 병합되므로 여러 명의 개발자가 동시에 애플리케이션 개발과 관련된 코드 작업을 할 경우 서로 충돌할 수 있는 문제를 해결할 수 있다.

"CD"는 지속적인 서비스 제공(Continuous Delivery) 및/또는 지속적인 배포(Continuous Deployment)를 의미하며 이 두 용어는 상호 교환적으로 사용된다.

두 가지 의미 모두 파이프라인의 추가 단계에 대한 자동화를 뜻하지만 때로는 얼마나 많은 자동화가 이루어지고 있는지를 설명하기 위해 별도로 사용되기도 한다.