반응형

최근에 수행된 프로젝트 또는 신규 시스템들은 Operation 모드 돌입 시  Source Version Control Tool 로서 대부분 Git을 많이 사용한다. 하지만 Git은 의외로 진입장벽이 높다. 한가지 예로, SVN만 사용한 개발자 분들은 Git Flow에 대해 이해하지 못하는 경우를 많이 봤다. 현재 Git을 사용하고 계신 분들은 이해를 못 할 수도 있지만, Git을 처음 사용할 때의 기억을 더듬어 본다면 어느정도 공감 할 수 있을 것이다. 

 

때문에, 어떤 프로젝트에서는 Git을 도입하기는 했지만 개발팀의 Learning Curve 너무 길어 SVN처럼 사용하는 Site도 많이 보았다. 내가 투입된 Site도 마찬가지 였다. Git의 사상을 이해하지 못하여 SVN 처럼 사용하고 이에 따라 배포(=Deploy) 부분에 많은 문제점이 있었으며 그 결과 많은 장애가 유발되고 있었다. 

 

상세내용은 아래와 같다. 

 

1. Deploy Issue 사항

 - k8s Container Image 배포 관련 휴먼(배포정책) Error 다수 발생 

 - 사유: 개발 Project 1개를 여러 업무 Scrum에서 개발 및 배포하는 과정에서 소스 연계성 불일치로 인한 서버 Error 발생 

 

2. 주요 원인 

 - CI/CD Flow 를 점검하였을 때, Jenkins Pipeline 설계 부분에서 문제가 될 수 있는 부분을 발견함  

 - 1개의 Git Master 에서 QA서버 / Live서버 Image를 생성하여 배포하는 것이 가장 큰 문제점으로 진단함

 - 위 그림과 같이, k8s Image 배포 시 Git Master 에서 Image를 생성하여 QA와 Live 서버에 동일하게 배포 하고 있었음

 - 상세 Flow 분석시 아래와 같은 문제점 발견

  1) A개발자가 Git Master 에서 소스를 Pull 받은 후 개발 내역을 Push 함

  2) QA Test를 위하여 Git Master를 빌드하여 Image를 생성 후 QA서버에 배포함 

  3) A개발자가 배포한 내역 중 결함이 발견되어 소스를 다시 수정해야하는 상황 발생 

  4) 동시에 B개발자는 자신이 맡은 개발과 TEST를 모두 완료하여 Live 서버 배포가 필요함

  5) B개발자는 Git Master 를 빌드하여 Image를 생성 후 Live 서버에 배포함 

  6) 이 때,  A개발자의 소스가 함께 배포되어 의도치 않은 서버 Error 발생 (*)

 

3. 개선 방안

 1) Master는 Image 생성 시 Live서버로만 배포 진행 

 2) QA Branch의 Image 생성 시 QA서버로만 배포 진행

 위와 같이 Pipeline를 이원화하여 관리하여 문제점 해결 

 

4.  개선된 Git Flow 상세 

 

  1) Git Master 로 부터 Feature Branch 생성 

  2) 개발진행 

  3) 개발완료 시 DEV Branch 소스 Merge 진행 (개발자)

  4) DEV 배포 진행 (개발자)

  5) DEV 단위 Test 수행

  6) QA Branch 소스 Merge 진행 (개발자)

  7) QA 배포 진행 (개발자) 

  8) QA 통합 Test 수행

  9) 정기 배포일날 배포자가 Git Master 로 부터 Feature Branch 생성

 10) 배포 Feature Branch에 소스 Merge (개발자) 

 11) 배포 Feature Branch 를 Master로 소스 Merge 수행

 12) Master 빌드 및 Image 생성 후 Live 서버 배포 수행 

 

위와 같은 Git Flow로 개발을 진행 했을 경우, Issue를 해결 할 수 있었다. 

Git Flow의 경우 각 프로젝트 성격 및 상황에 맞게 구성할 수 있다. 

'IT Governance' 카테고리의 다른 글

DML (Data Manipulation Language) 작업 Process  (0) 2024.04.19

+ Recent posts