[Git] 형상 관리 / 소프트웨어 형상 관리 도구

 

 

---

 

 

목차

 

형상관리란?

형상관리 목적

형상 관리 절차

형상 관리 도구

 

---

 

 

---

[ 형상관리란? (SCM : Software Configuration Management)]

형상 관리를 알기 위해서는 변경관리, 버전 관리에 대해 알아야 한다.

1. 변경 관리

세상의 모든 것은 시간이 지남에 따라 변해간다. 자연에도 계절의 변화가 있고, 사람의 얼굴과 신체도 변한다.

자연에는 변화가 있지만 소프트웨어에는 변경이 일어난다. 소프트웨어 개발 도중에도 수정 사항이 생기고, 시간이 지날수록 새로운 기술이 생겨난다. 이것을 ‘변경’이라고 한다.

소프트웨어 개발 전체 단계에서 생기는 변경사항은 많은 부분에 영향을 미친다.

즉, 각 개발 단계에서 문서화된 산출물뿐만 아니라 데이터베이스, 코드, 테스트에도 영향을 미친다.

따라서 변경되는 과정을 관리하지 못하면 엄청난 혼란이 올 수 있다.

 

<변경의 요인>

- 업무 환경의 변화

: 새로운 기능의 추가와 같이 고객의 요구가 바뀌는 경우

: 시장 여건이 변경될 수도 있고, 예산과 일정 계획 등에서 변경이 생길 수도 있다.

- 기술 환경의 변화

: 하드웨어나 운영체제가 변경되는 경우 -> 프로젝트 계획에서부터 코딩 단계의 모든 영역에 영향을 끼치게 된다.

 

따라서 변경되는 항목뿐 아니라 그 히스토리까지 적합한 변경 관리 도구를 사용하여 철저히 관리해야 곳곳에서 발생할 수 있는 오류를 줄일 수 있고 고품질의 소프트웨어 개발로 이어질 수 있다.

 

 

 

2. 버전 관리

 

대학교를 다니면서 과제, 보고서 등을 제출한 적이 있을 것이다. 보고서를 작성하면서 수정하고 최종본이 계속 생겨난다. 하지만 쌓인 파일들을 보면 막상 어떤 것이 최종 보고서인지 혼란스러웠던 경험이 있었다.

이러한 혼란을 방지하기 위해 버전 관리를 해야 한다.

 

- 풀 모델 체인지 (full model change) : 크게 바뀌는 것

외형의 디자인도 대폭 바뀌고, 내부 인테리어뿐 아니라 엔진까지도 바뀌는 경우로

하드웨어 등과 같은 제 품의 품질을 대폭적으로 개선하여 형태 번호를 변경하는 것을 말한다.

- 마이너 체인지 (minorchange): 약간만 바뀌는 것

외형적인 디자인과 내부 인테리어 정도가 바뀌는 것이라고도 한다. 즉 , 소프트웨어 또는 하드웨어 신제품을 발표하는 경우. 기존 제품에 비해 수정한 내용이 별로 없는 상황을 말한다.

소프트웨어의 Ver.1.0에서 Ver.2.0으로 바뀌는 것은 풀 모델 체인지, 1.0에서 Ver.1.1 또는 Ver.1.1.1에서 Ver.1.1.2로 바뀌는 것은 마이너 체인지와 유사하다.

소프트웨어 버전이란 개발 단계 또는 순서를 번호로 표시한 것이다. 소프트웨어의 판 명칭. 보통 소프트웨어를 말할 때 끝에 붙는 소수점이 찍힌 숫자이다. 소프트웨어에서 개발이 1차 완료되면 알파 버전이나 베타 버전을 특정한 사용자들에게 먼저 배포하여 기능과 오류를 검증하게 한 후, 기능이 확정되어 개발이 완료되면 버전 1.0(V1.0)으로 내놓는다. 이후 기능을 개선하여 발표할 때마다 1.1, 1.2, ···, 2.0 등으로 버전을 상품에 표시한다.

 

이때 버전 번호는 점으로 구분된 두 개의 숫자로 구성되어 있다. 점 앞의 숫자는 주 번호, 점 뒤의 숫자는 부 번호라고 한다.

소프트웨어 개발이 크게 변화된 경우 주 번호를 변경시키고, 이전 버전에 있던 오류를 수정하는 정도의 기능 변화가 크지 않을 때는 부 번호를 바꾼다.

이와 같은 방법으로 프로그램을 개발할 때에도 계속적인 변경 내용을 반영하기 위해 버전 업을 시키며 관리를 하며 나아간다.

<버전 관리의 필요성>

파일의 이력이나 차이점을 관리해 애플리케이션의 버전과 각 원시 파일이나 문서를 유용하게 활용하기 위함이다.

 

버전 관리에 대해 자세한 설명은 다음 게시글을 보도록 하자.(클릭)

 

[Git] 형상 관리 / 형상 관리 버전 관리

 

 

 

 

3. 형상 관리

 

자동차, 비행기와 같은 제품은 수만에서 수십만 개의 부품으로 이루어져 있다.

이러한 작은 단위의 부품들을 형상관리에서 ‘형상 항목’이라고 한다.

자동차나 비행기의 조립 과정에서 부품이 변경되거나 새로 개발된 부품을 장착하여 사용할 경우, 기존 부품들과 오류 없이 안정적으로 작동이 되어야 한다.

만약 어떤 한 부품이 관리되지 않고 규격이 바뀌거나, 누락되었다면 사고가 발생할 수 있다.

따라서 형상관리는 이러한 특정 항목의 변화에 대해 관리하며 시스템의 통합과 일치를 보장하는 것이다.

 

소프트웨어 개발도 한번 시작해서 변경 없이 마무리되는 경우는 없다. 대부분 사용자의 요구사항이 추가되거나 수정되는 등 지속적인 변경이 생긴다. 따라서 변경되는 것들을 체계적으로 정리하여 관리하지 않으면 어떤 개발자는 변경 전의 모듈로 개발하는 경우가 발생하여 원하는 결과를 얻지 못하게 된다. 이러한 부작용을 없애기 위해 형상관리를 해야 한다.

 

정리하면 형상관리 (SCM : Software Configuration Management)는 소프트웨어 개발을 위한 전체 과정에서 발생하는 모든 항목의 변경 사항을 관리하기 위한 활동이다.

 

형상 관리 절차를 중심으로 형상 항목을 식별하여 그 기능적 물리적 특성을 문서화하고, 그러한 특성에 대한 변경을 공식적으로 통제하고, 변경 처리 상태를 기록 및 보고하고, 명시된 요구사항에 부합하는지 확인하는 일련의 사항에 대해 기술적 행정적인 지침과 관리적인 감독, 감시활동을 포함한 유지보수까지 적용한다.

 

그러므로 형상 관리에서는 적절한 변경관리를 통하여 무절제한 변경을 사전에 예방하고 변경에 따른 부작용을 최소화한다. 또한 형상관리는 통해 프로젝트를 적절히 통제하여 체계적이고 효율적으로 관리할 수 있으며, 가시성과 추적성을 보장함으로써 소프트웨어의 생산성과 품질을 높일 수 있다.

<요약>

기능 , 성능, 제약 조건 등의 추상적인 관리 대상을 형상화하여 정하고 변경 사항에 대해서 통제 및 확인하며 이를 관련된 사람들에게 보고하는 것을 말한다.

 

 

 

---

[형상관리 목적]

 

형상관리의 궁극적인 목표는 프로젝트를 개발하는 동안 생산성과 안전성을 높여 좋은 품질의 소프트웨어를 생산하고 유지보수도 용이하게 해주는 데 목적이 있다. 만약 잦은 요구 사항과 변경과 수정된 산출물의 이력이 정확하게 관리되지 않고 관련자들 모두에게 변경 내용이 제대로 전달되지 않는다면, 이중작업과 중복작업이 발생할 수 있고, 그로 인해 작업에 혼란이 생겨 결국 원하는 결과를 얻을 수 없게 된다.

소프트웨어 개발의 전체 비용을 줄이고 개발 과정의 여러 방해 요인이 최소화되도록 보증하는 것을 목적으로 한다.

또한 누가 변경했는지, 변경된 것은 무엇인지, 언제 변경되었는지, 왜 변경했는지 와 같은 질문에 대답해준다.

 

- 프로젝트 생명주기 동안 제품의 무결성과 변경에 대한 추적성을 확보

- 프로젝트 변경이 발생되었을 때 처리하는 메커니즘을 제공.

- 대표적인 메커니즘으로 형상 관리 대상 파악, 베이스 라인 지정, 형상관리, 접근제어 등이 잇다.

- 산출물 품질의 향상

- 개발 및 유지보수 생산성의 향상

- 사용자 요구사항을 체계적으로 관리

 

 

 

 

---

[형상관리 절차]

 

1. 형상 식별 : 형상 관리 대상에 이름과 관리 번호를 부여하고, 계층 구조로 구분하여 수정 및 추적이 용이하도록 하는 작업으로 형상 관리의 대상이 무엇인지 식별하는 것을 말한다. 식별 대상을 형상 항목이라고 한다.

2. 형상 통제 : 식별된 형상 항목에 대한 변경 요구를 검토하여 현재의 기준선 (Baseline)이 잘 반영될 수 있도록 조정하는 작업으로 형상 항목의 버전과 변경에 대한 판단을 내리는 것이다.

3. 형상 상태 보고 : 기준선의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업이다.

4. 형상 감사 : 형상의 식별, 통제 , 감사 작업의 결과를 기록/ 관리하고 보고서를 작성하는 작업. 변경된 형상 항목을 관계된 사람들에게 알리는 것을 말한다.

 

형상 관리절차에 대해 자세한 설명은 다음 게시글을 보도록 하자.(클릭)

 

[Git] 형상 관리 / 형상 관리 구성

 

---

[형상 관리 도구]

 

초기의 소프트웨어 형상관리 도구는 공유 폴더 방식을 많이 활용하였지만, 최근에는 클라이언트/ 서버 방식과 분산 저장소 방식이 많이 활용된다.

 

● 공유 폴더 방식

: 버전 관리 자료가 지역 컴퓨터의 공유 폴더에 저장되어 관리되는 방식

파일을 잘 못 복사하거나 다른 위치로 복사하는 것에 대비하기 위해 파일의 변경사항을 데이터베이스에 기록하며 관리한다.

매일 개발이 완료된 파일은 약속된 위치의 공유 폴더에 복사하는 방식

담당자 한 명이 매일 공유 폴더의 파일을 자기 PC로 복사하고 컴파일하여 에러 확인과 정삭 동작 여부 확인

종류 : SCCS, RCS, PVCS, QVCS

- RCS(Revision Control System) : CVS와 달리 소스파일의 수정을 한 사람만으로 제한하여 다수의 사람이 파일의 수정을 동시에 할 수 없도록 파일 잠금 방식으로 형상을 관리하는 도구

 

● 클라이언트 / 서버 방식

: 버전 관리 자료가 서버에 저장되어 관리되는 방식

모든 버전 관리는 서버에서 수행된다.

서버에 문제가 생기면 서버가 복구되기 전까지 다른 개발자와의 협업 및 버전 관리 작업은 중단된다.

중앙에 버전 관리 시스템을 항시 동작시키는 방식

개발자들의 현재 작업 내용과 이전 작업 내용 추적에 용이

서로 다른 개발자가 같은 파일을 작업했을 때 경고 메시지 출력

종류 : CVS, SVN(Subversion), CVSNT, Clear Case, CMVC, Perforce 등

- CVS(Concurrent Version System) : 서버와 클라이언트로 구성되어있고, 다수의 인원이 동시에 범용적인 운영체제로 접근 가능한 형상관리 도구

- SVN(Subversion) : 하나의 서버에서 소스를 쉽고 유용하게 관리할 수 있게 도와주는 도구

저장소를 만들어 그곳에 소스를 저장해 소스 중복이나 여러 문제를 해결하기 위한 도구

 

 

● 분산 저장소 방식

: 버전 관리 자료가 하나의 원격 저장소와 분산된 개발자 PC의 지역 저장소에 함께 저장되어 관리되는 방식

지역 저장소에서 버전 관리가 가능하므로 원격 저장소에 문제가 생겨도 지역 저장소의 자료를 이용하여 작업할 수 있다.

개발 완료한 파일을 수정한 다음에 로컬 저장소에 우선적으로 커밋한 이후, 다시 원격 저장소에 반영하는 방식

종류 : Git, GNU arch, Bazaar, Mercurial, Team Ware, Bitkeeper, Plastic SCM 등

 

 

- Bitkeeper : SVN과 비슷한 중앙 통제 방식으로 대규모 프로젝트에서 빠른 속도를 내도록 개발된 형상 관리 도구

- git : git의 속도에 중점을 둔 분산형 버전 관리 시스템이며, 대형 프로젝트에서 효과적이고 유용

Git의 커밋(commit)  동작은 로컬 저장소에서 이루어지고 푸시라는 동작으로 원격 저장소에 반영

로컬 저장소에서 작업이 이루어져 매우 빠른 응답을 받을 수 있다.

Git의 작업 폴더는 전체 기록과 각 기록을 추적할 수 있는 정보를 포함하는 완전한 형태의 저장소

● Subversion (서브 버전, SVN)

: CVS를 개선한 것으로, 소스가 오픈되어 있어 무료로 사용할 수 있다.

중앙 서버에서 모든 소스코드를 보관 관리하는 시스템

클라이언트/서버 구조로, 서버(저장소)에는 최신 버전의 파일들과 변경 사항이 관리된다.

CVS의 단점이었던 파일이나 디랙터리의 이름 변경, 이동 등이 가능

 

 

 

 

---

 

[소프트웨어 형상 관리 도구 사용 시 유의사항]

- 버전에 대한 쉬운 정보 접근성

형상관리 지침에 의한 버전에 대한 정보를 언제든지 접근할 수 있어야 한다.

프로젝트 단위 접근이든, 파일 단위의 접근이든 간에 개발자가 원하는 때에 원하는 모습을 다시 구성할 수 있어야 한다.

- 불필요한 사용자에 대한 접근 제어

제품 소프트웨어 개발자, 배포자 이외에 불필요한 사용자가 소스를 수정할 수 없도록 해야 한다.

중요한 파일 혹은 폴더에 대한 접근은 개발자, 배포자 등 권한이 있는 자만 접근할 수 있도록 한다.

- 동일 프로젝트에 대한 동시 사용성

동일한 프로젝트에서 여러 개발자가 동시에 개발할 수 있어야 한다.

여러 개발자가 동일한 파일, 폴더에 접근 시 동시에 파일 수정이 일어나더라도 개발자의 수정 내영 기이 통합될 수 있어야 한다.

- 빠른 오류 복구

에러 발생 시 최대한 빠른 시간 내에 복구가 가능해야 한다.

과거 버전의 소스를 가지고 신속하게 원복 할 수 있어야 한다.

 

 

 

 

 

[Git] 형상 관리 / 형상 관리 버전 관리

[Git] 형상 관리 / 형상 관리 구성

[Git] 깃 / Git / 깃허브 / 깃허브란?

[Git] Git 설치하기 / Git 설치 / Git 2.38.1 설치

---

잘못된 정보는 댓글에 남겨주시면 감사하겠습니다!😊

댓글과 좋아요는 큰 힘이 됩니다!

 

 

 

출처

[네이버 지식백과] 변경 관리 (쉽게 배우는 소프트웨어 공학, 2015. 11. 30., 김치수)