1. 형상관리란 무엇인가

형상 관리란 특정 항목의 변화에 대해 관리하면서 시스템의 통합과 일치를 보장하는 것이다. 소프트웨어 개발이라는건 끊임없는 수정을 필요로 한다. 사용자의 요구사항 추가, 버그 수정등 지속적으로 생기는 변경사항들을 체계적으로 정리 및 관리를 해야한다.
그렇지 않으면 변경 전의 모듈로 개발하는 경우도 생길 수 있기 때문이다.

형상 관리는 개발 중 발생하는 모든 산출물들이 변경됨으로써 점차 변해가는 소프트웨어 형상을 체계적으로 관리하고 유지하는 기법이다.

1.1 형상관리의 개념과 목적

• 개념
  소프트웨어 개발 생명주기 전반에 걸쳐 생성되는 모든 산출물의 종합 및 변경 과정을 체계적으로 관리하고 유지는 일련의 개발 관리 활동

• 목적
  소프트웨어의 가시성과 추적 기능성을 부여하여 제품의 품질과 안정성을 높여 좋품질이 좋은 소프트웨어를 생산하고 유지보수도 용이하게 해주는 데 목적이 있음

• 이점

1. 형상 관리를 통해 언제라도 특정 시간대에 가장 안정적인 버전의 소프트웨어를 유지할 수 있도록, 소프트웨어 제품이 변경되어가는 상태에 대한 가시성을 확보해준다.

2. 누가 변경했는지, 변경된 것은 무엇인지, 언제 변경되었는지, 왜 변경했는지 체계적인 관리가 가능하다.

3. 형상 관리에서는 적절한 변경 관리를 통하여 무절제한 변경을 사전에 예방하고, 변경에 따른 부작용을 최소화한다.

2. 형상 관리 수행 절차

2.1 형상 식별

형상 관리를 위해 어떤 산출물을 형상 관리의 대상으로 할 것인지 결정해야 한다. 형상 식별(configuration identification)은 형상 관리의 가장 밑바탕이 되는 활동으로, 프로젝트를 계획할 때 형상 관리 계획을 근거로 형상 관리의 대상이 무엇인지 식별하는 과정이다. 식별된 형상 항목은 유일하게 식별할 수 있도록 형상 항목의 이름, 작성자, 생성 날짜, 문서 번호, 다른 형상 항목과의 관계 등과 함께 관리 목록의 번호를 부여하여 메타 데이터베이스에 저장해서 변경 관리의 대상으로 삼는다.

여기서 형상 항목은 개발 단계에서 생산되거나 사용되는 작업이나 산출물이다. 실행 파일, 문서 형식의 산출물, 원시 코드, 개발 이력, 개발 도구 등이 이에 해당한다.

형상 식별은 형상 항목 선정, 형상 식별자 규칙 선정, 베이스라인 기준 선정으로 세분화할 수 있다.

2.2 형상 통제

소프트웨어 개발에서 가장 어려운 부분 중의 하나가 사용자 요구 사항의 잦은 변경을 꼽을 수 있다. 사용자의 요구 사항은 더는 없다고 확정하고 도장을 찍는 순간에도 일어날 만큼 계속 발생한다. 또 개발자의 수정도 빈번히 발생한다.

이처럼 변경에 대한 요구를 무조건 다 수용하다가는 소프트웨어 개발이 순조롭게 진행될 수 없을 것이다. 따라서 변경을 위해서는 변경하고자 하는 요구를 정해진 양식에 맞추어 작성하고 형상통제위원회(CCB: Configuration Control Board)에서는 그 변경 요청을 수용할 것인지, 거절할 것인지 결정하여 결과를 통보해준다. 이처럼 형상 목록의 변경 요구를 검토 및 승인하여 현재의 소프트웨어 기준선에 반영될 수 있도록 통제하는 일련의 과정을 형상 통제(configuration control)라 한다.

형상 통제는 변경 요청, 변경 심사, 변경 실시, 변경 확인 등으로 세분화할 수 있다

2.3 형상 상태 보고

형상 항목의 개발 상태에 대한 가시성을 통해 형상을 효율적으로 관리하기 위하여 베이스라인으로 설정된 형상 항목의 구조와 변경 상태를 기록하고, 관련된 사람들에게 보고하는 것을 형상 상태 보고(configuration status reporting)라 한다. 이때 보고하는 형상 상태 보고서는 베이스라인의 모든 변경에 대한 추적을 목적으로 하며, 변경 요청 상태 형상 담당자가 작성하여 상위 관리자에게 보고한다.

2.4 형상 감사

일반적으로 '감사'란 일을 처리하는 데 문제는 없었는지 확인하는 활동이다. 마찬가지로 형상 감사(configuration audit)도 형상 관리 계획서대로 형상 관리가 진행되고 있는지, 형상 항목의 변경이 요구 사항에 맞도록 제대로 이뤄졌는지 등을 살펴보는 활동이라고 할 수 있다. 따라서 단계별 베이스라인의 적정성과 무결성을 평가하고 승인한다. 형상 감사는 형상 담당자에 의해 실시되며 형상 감사 수행 전에 형상 관리 계획서 상에 형상 감사를 위한 계획이 수립되어 있어야 한다.

형상 감사는 감사 일정 및 절차 정의, 정해진 베이스라인에 따른 감사 실시, 감사 보고서 작성으로 세분화할 수 있고 다음과 같은 내용을 중심으로 검증한다

• 승인된 변경 요청이 제대로 반영되었는지 검증
• 승인되지 않은 내용이 혹시 반영되었는지 검증
• 승인된 변경과 관련된 항목들이 갱신되었는지 검증

2.5 형상관리 관련 참고 문서

네이버 지식백과
https://terms.naver.com/entry.naver?docId=3533073&cid=58528&categoryId=58528

3. 형상관리를 위한 도구와 특징

• CVS(Concurrent Version System)
  90년에 출시된 무료 서버-클라이언트 형상관리 시스템. 파일 전체를 저장하는 것이 아니라 변경사항만을 저장함으로 용량을 적게 차지하지만 속도가 상대적으로 느리다

• SVN(Subversion)
  형상관리/소스관리 툴의 일종. 중앙관리만을 지원. 다른 사용자의 커밋과 엉키지 않으며, 커밋 실패 시 롤백 기능을 지원. 안정성에 있어 CVS보다 상대적으로 좋지 않다.

• Git
  분산형 버전관리 시스템. Repository의 완전한 복사본을 로컬에 저장할 수 있다. 처리속도가 빠르지만 대용량 코드 관리에 부적절하다.

• Perforce(P4D)
  빠른속도, 빠른 Merge가 가능하며 큰 리소스 관리에 좋다. 하지만 유료이고 파일명이 바뀌면 히스토리 추적이 곤란하다.

4. Git

형상 관리 도구는 버전 관리 시스템이라고 한다.
Git은 소프트웨어를 개발하는 기업의 핵심 자산인 소스코드를 효율적으로 관리 할 수 있게 해주는 무료, 공개소프트웨어

4.1 Git의 장점

• 소스코드를 주구 받을 필요 없이, 같은 파일을 여러 명이 동시에 작업하는 병렬 개발이 가능하다.(브랜치를 통해 개발한 뒤, 본 프로그램에 합치는 방식(Merge))으로 개발을 진행할 수 있다.

• 분산 버전관리이기 때문에 인터넷이 연결되지 않은 곳에서도 개발을 진행할 수 있으며, 중앙 저장소가 날라가버려도 다시 원상복구 할 수 있다.

• 팀 프로젝트가 아닌, 개인 프로젝트일지라도 GIT을 통해 버전관리를 하면 체계적인 개발이 가능해지고, 프로그램이나 패치를 배포하는 과정도 간단해진다(pull을 통한 업데이트, patch 파일 배포)

4.2 Github?

• Github : 형상 관리 도구(버전관리)웹호스팅 서비스
  협업하고 있는 코드를 저장할 서버가 필요하다.
  버전 관리 시스템을 지원하는 웹호스팅 서비스의 기능을 통해, push,pull request같은 이벤트에 반응하여 자동으로 작업(배포 등)을 실행하게 할 수 있다.
  ex)GitHub, GitLab, BitBucket

4.4 관련 용어들

• Repository : 저장소를 의미하며, 저장소는 히스토리, 태그, 소스의 가지치기 혹은 branch에 따라 버전을 저장한다. 저장소를 통해 작업자가 변경한 모든 히스토리를 확인 할 수 있다.

• Working Tree : 저장소를 어느 한 시점을 바라보는 작업자의 현재 시점.

• Staging Area : 저장소에 커밋하기 전에 커밋을 준비하는 위치.

• Commit : 현재 변경된 작업 상태를 점검을 마치면 확정하고 저장소에 저장하는 작업.

• Head : 현재 작업중인 Branch를 가리킨다.

• Branch : 가지 또는 분기점을 의미하며, 작업을 할때에 현재 상태를 복사하여 Branch에서 작업을 한 후에 완전하다 싶을때 Merge를 하여 작업을 한다.

• Merge : 다른 Branch의 내용을 현재 Branch로 가져와 합치는 작업을 의미한다.

4.5 Git 사용하기 (기초용어)

• git init : 버전관리 하고싶은 폴더에서 초기화를 하는 준비

• git branch

1. 독립적인 공간을 만든다.
2. 새로 만든 branch lab1은 master와 완전히 동일한 상태를 가진 공간.
3. 브랜치에서 수정을 한 후 커밋하면 lab1에만 기록되며 master 브랜치에는 어떤 영향도 주지 않는다.
4. 원하는 만큼 빠르게 branch를 만들 수 있다.
5. 실험 중 다른 브랜치로 돌아가야 할 때 : checkout master 로 head를 옮겨야 한다.
   (cf > 작업 중인 위치를 가르키는 가상의 커서가 존재하는데 이를 git에서는 HEAD라 한다.)
6. 실험 성공 : lab1 브랜치의 내용을 마스터 브랜치와 병합(Merge) 한다.
7. 실험 실패 : lab1 브랜치를 삭제한다.

• checkout
  독립된 작업 공간인 브랜치를 자유롭게 이동할 수 있다.

• git commit
  의미있는 수정 작업이 끝났을 때 마침을 알리는 작업

• pull
  리모트 저장소의 변경된 내용을 로컬(내 컴퓨터) 저장소에 적용하는 작업을 pull이라 한다.

• master
  git init을 했을 때, default로 만들어지는 가지가 'master'이다.

동료와 함께 작업하려면? -> github! or bitbucket

• git은 'remote 저장소'를 지원한다.
• github이 바로 remote저장소이다.
• bitbucket은 5명까지 공동작업 가능하다. (그 이상은 유료)
• github은 private가 유료이다.
  

4.6 Git의 개념 참고 문서

출처: https://goddaehee.tistory.com/91?category=381481 [갓대희의 작은공간]

5. Git-flow란 무엇인가?

Git-flow는 Vincent Driessen이라 제시한 Git으로 개발할 때 거의 표준과 같이 사용되는 방법론이다.

참고 링크 : https://nvie.com/posts/a-successful-git-branching-model/

SVN과 CVS에 비해 git이 갖는 큰 장점은 효율적인 브랜치(Branch) 관리가 가능하다는 점이다. 소스코드의 일부분을 수정하기 위해 브랜치를 생성하고 작업한 다음 원래 소스코드에 손쉽게 수정사항을 병합(Merge)할 수 있다

Git-flow에는 총 5가지의 브랜치가 존재한다.
항상 유지되는 메인 브랜치들(master, develop)과 일정 기간 동안만 유지되는 보조 브랜치들(feature, release, hotfix)이 있다.

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

처음에는 master와 develop 브랜치가 존재한다. develop 브랜치에서는 상시로 버그를 수정한 커밋들이 추가된다.

새로운 기능 추가 작업이 있는 경우 develop 브랜치에서 feature 브랜치를 생성한다. feature 브랜치는 언제나 develop 브랜치에서부터 시작하게 된다. 기능 추가 작업이 완료되었다면 feature 브랜치는 develop 브랜치로 merge 된다.

develop에 이번 버전에 포함되는 모든 기능이 merge 되었다면 QA를 하기 위해 develop 브랜치에서부터 release 브랜치를 생성한다. QA를 진행하면서 발생한 버그들은 release 브랜치에 수정된다.

QA를 무사히 통과했다면 release 브랜치를 master와 develop 브랜치로 merge 합니다. 마지막으로 출시된 master 브랜치에서 버전 태그를 추가한다.

5.1 Git-flow의 개념 참고 문서

우아한 형제들 기술 블로그 https://techblog.woowahan.com/2553/