#4 VCS(버전 관리 시스템)과 Issue 관리

VCS(Version Control System)
 :  소스 코드의 변경 이력 관리
 : 여러 사람이 동일 소스 코드(동일한 Baseline)를 공유
 : 단순 Copy 복사는 Copy가 전달 되는 과정에서 왜곡 될 수 있음 (잘못된 버전 제공 등의 이유)
  > 이를 제거하고자 VCS 사용

소스코드의 변경 이력 관리
 : 문제점이 발생했을 때, 원인 추적에 유용
  > 과거 특정 시점의 내용 확인
  > 과거 특정 시점으로 되돌려 수정 가능
ex) 현재 시점 : C

예시 이미지

B 코드 문제 발생 시 해결

   ) E는 B와 Relation을 가지고 있음(버전 관리 이력)
   ) 문제를 파악하여 버전을 언제든지 되돌리고 문제 해결을 위함
   ) 감시를 통한 이점은 없음
 
 : 여러개의 버전으로 분기
  > 다양한 방법의 구현/검증을 나누기
  > 기존의 릴리즈 한 버전의 수정
   ~> 새로운 버전의 개발 과정과 나눌 수 있음

E 에서 버그 발생

브랜치를 열어 Hotfix 버전과 최신 버전 기능 개발을 분기

 : 여러 사람이 동일 소스 코드를 공유
  > 중앙 집중식 관리 : CVS, SubVersion(SVN) 등
  > 분산 관리 : Git, Mecurial 등
 - 중앙 집중식 VCS
  : Centralized Version Control System
  : 코드 관리 공간 1개
   > Check-out 시 Lock을 걸어 다른 사람이 못 건드리도록 할 수 있음
   > 다른 것을 수정할 때에는 문제가 없으나 같은 것을 수정하게 될 경우
     Check-in이 진행될 때마다 충돌(Conflict)이 발생할 가능성이 높음

중앙 집중식

 - 분산관리 VCS
 : DeCentralized Version Control System
 : VCS 전체를 가져옴(Clone(최초) / Fetch)
  > Local에서 개발(VCS가 모름)
  > Push를 통해 다른 사람과 변경사항 공유
 : 중앙은 Push단위(Check-In 단위 X)로 Conflict(충돌) 발생
 : commit >= push (횟수 비교)
 : 중앙집중식은 commit시 충돌이지만, 분산에서는 push할 경우 충돌 발생(발생 횟수가 적어짐)
 : 네트워크 단절 시 중앙 집중식은 개발 방법이 없음(commit이 불가능하기 때문)
  > 분산관리에서는 형상관리하는데 문제 없음(각광받는 이유)

분산 관리

이슈 관리 시스템(Issue Tracker / Bug Tracker)
1) 이슈 트래킹
 : 이슈 = 업무
 : 업무를 추적 기록 하는 시스템
  > 개발자 / 경영자 / 품질관리 테스트 등의 프로젝트 참여자
  > 업무 진행 상황의 참여자간 공유

2) 이슈 트래커 기능
 - 팀 커뮤니케이션
  > 참여자 간 의견을 나눌 수 있는 환경
   : 게시판과 같은 형태의 대기 시간이 길어도 되는 소통
   : 메신저, 이메일, 화상회의 등의 대기 시간이 짧은 소통

 - 일정 관리
  > 프로젝트 진행 관리
   : Kanban, CPM, PERT, Gantt 등의 방법
  > 스케쥴의 공유
   : Calendar 등

 - 이슈 보고 및 등록
  > 개발 및 운영의 각 단계에서 제기된 어떤 일
   : 회의 등에서 발굴한 기능
   : 품질 검사 / 관리 중에 발견한 결함
   : 사용자로부터 보고된 인시던트
   : 고객이 요구한 추가사항 등

 - 담당자 배정
  > 보고 / 등록된 이슈에 대하여 처리할 사람 배정
   : 해당 이슈에 적합한 사람에게 할당
   : 현재 업무가 적은 사람에게 할당

 - 이슈 검토와 해결
  > 이슈가 해결 가능한 지 검토
   : 반려 | 문제 해결 수행
  > 이슈를 제기한 사람과 소통을 지원해야 함
  > 이슈가 할당된 사람
   : 주어진 이슈를 해결하고 해결을 선언
   : 검증 담당자가 있다면, 검증 담당자에 의해 검증 수행
  ~> 이것들을 시스템으로 어느정도로 자동화 해주냐가 DevOps의 핵심 역량임
  > 이슈의 정보화
   - 이슈의 검색
    ex) 처리 되지 않은 이슈
          오랫 동안 처리 되지 않은 이슈
          나에게 할당된 이슈
          아무에게도 할당되지 않은 이슈
   - 이슈 분류
    ex) 태그 등을 통한 분류
          분류를 통한 검색 수행
          프로젝트 진행 상황의 파악에 활용

 - 소프트웨어 개발(VCS와의 연동)
  > 어떤 이슈는 개발을 수행해야 함
   : 어떤 이슈가 VCS의 어떤 Commit과 연관 관계를 맺기
    ~> 이슈의 개발 진행 상황 파악 용이
    ~> 이슈 단위로 개발 단위를 가져갈 수 있음(Commit의 그룹화)

Issue와 VCS와의 연계
VCS의 브랜치 전략
1) Git-Flow
  : 브랜치를 4가지로 나누어 개발
  1. 메인 브랜치 / 개발 브랜치
    : 주로 개발하는 브랜치
    master 브랜치 : 현재 배포 가능한 상태의 브랜치
    develop 브랜치 : 다음에 배포할 것을 개발하는 브랜치
                             : 통합 브랜치 역할(개발의 중심)
  2. 피처 / 토픽 브랜치 : 기능별로 짧게 개발
                                  : 기능을 완성할 때 까지 유지
                                  : 기능 완성 시  develop 브랜치로 merge | 필요 없다면 drop(remove)
  3. 릴리스 브랜치 : 스테이징 시 발생하는 문제를 해결하고 릴리스 할 수 있도록 작업하는 브랜치
                            : 품질 검사 등을 위해 진행하는 브랜치
                            : develop에서 배포를 예정하고 있는 상태에서 가지치기
                            : 배포를 위한 수정이 발생
                            : 배포 가능 상태 도달
                             > master에 병합 + 태그 부여 : CD에서 Release가 발생해야 함
                             > develop에 병합 : 후속 개발에 변경사항 반영
  4. 핫픽스 브랜치 : 릴리즈 후 픽스를 해야할 때 사용
                            : 기존의 배포한 버전에서 긴급하게 수정해야 할 필요가 있을 때
                            : master에서 가지치기
                             > 버그를 수정하는 것과 기존의 develop 브랜치의 개발이 병행
                            : hotfix 수정 완료
                             > master에 병합 + 태그 부여
                             > develop에 병합 : 후속 개발에 변경사항 반영

 - master/develop 브랜치가 중심
  : master -> develop으로 가지치기
  : develop -> feature, release, hotfix 브랜치 생성
  : feature -> develop 브랜치로 병합
  : Release, hotfix -> master 브랜치로 병합
  : feature, release, hotfix -> 병합 후 제거

Git-Flow Branch

 2) Github-Flow
 - Git-flow가 Github에서 사용하기 복잡하다고 여겨 나온 전략
 - 흐름의 단순화 > Role 단순화
 - Master 브랜치에 대한 Role이 명확(Master 외의 브랜치의 Role이 없음)
  > 나머지 브랜치에 대해서는 관여 안 함
  > Feature / Hotfix 브랜치 구분 안 함
 - Pull-Request 기능 적극 활용
 - 적합한 경우
  1) 수시로 배포가 일어나는 경우
  2) CI/CD 자동화가 되어 있는 경우

 - Master 브랜치 : 언제나 배포 가능
                          : 항상 최신 상태 + Stable 상태 (Product에 배포 가능 상태)
                          : 엄격한 Role과 함께 사용
                           > Master에 Merge하기 전에 충분히 테스트 진행(CI를 통한 자동화)
 - Master에서 새로운 일 시작 : 브랜치 이름을 명확하게 지어야 함
                                             : 브랜치는 항상 Master 브랜치에서 만듦
                                             : 새로운 기능을 추가하거나, 버그를 해결하기 위한 브랜치 이름은 어떤 일을 하고 있는지 자세히 작성
                                             : 커밋 메시지를 명확하게 작성
 - 원격지 브랜치로 수시로 Push : Git-flow와 상반되는 방식
                                                 : 항상 원격지에 올려 자신이 하고 있는 일을 다른 사람들도 확인 가능하게 만듦
                                                 : 하드웨어 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아 작업 가능
 - 피드백이나 도움이 필요할 때, Merge 준비가 완료되었을 때 Pull Request 생성
  : Pull Request는 코드 리뷰를 도와주는 시스템
  : 자신의 코드를 공유, 리뷰
  : Merge 준비가 완료되었다면 Master 브랜치로 반영 요구
 -  기능에 대한 리뷰와 논의가 끝난 후 Master로 Merge
  : Product로 반영 가능 > 이해관계가 연결된 사람들과 충분한 논의 이후 반영
  : CI 통과 필수
 - Master로 Merge되고 Push 되었을 때는 즉시 배포
  : GitHub-Flow의 핵심
  : Master로 Merge가 일어나면 자동으로 배포가 되도록 설정