위키원
형상관리
형상관리(Configuration Management; CM) 또는 소프트웨어 구성관리(Software Configuration Management; SCM)는 더 범위가 큰 구성 관리의 학문간 분야의 일부인, 소프트웨어의 변경사항을 추적하고 통제하는 작업이다. 간략히 구성관리라고도 한다.
개요[편집]
형상관리는 소프트웨어 변경사항을 체계적으로 추적, 통제하는 것으로, 어떤 문서나 파일이 변경되었을 경우 변경된 내역을 기록하였다가 나중에 이를 찾아 보아야 할 경우, 변경 원인과 변경 사항을 확인해야 할 경우에 대한 관리를 말한다. 소프트웨어 형상은 사용자, 소프트웨어의 환경에 따라 소프트웨어 생명주기 어느 단계에서나 변경이 발생한다. 새로운 요구사항이 발생되면, 요구사항 관련 형상 항목뿐 아니라, 관련된 설계 형상 항목, 구현, 테스트 형상 항목 및 최종 소프트웨어 제품의 형상 역시 변하게 된다. 이러한 변경 요인은 제품이 개발된 이후, 개발 중 할 것 없이 어디서든 변경이 될 수 있기 때문에 어떤 이유로 변경이 발생했는지, 그 결과로 어떤 형상 항목이 변경되거나, 새로 생성되었는지 관리하는 것이 형상관리이다.[1]
목적[편집]
소프트웨어 수명주기 모델은 소프트웨어 사업의 프로세스 기준을 제시한다. 소프트웨어 수명주기 모델은 소프트웨어 사업을 진행할 때 수행되어야 할 활동들과 그 활동들의 순서를 정하고 관리, 통제하기 위한 기준을 제공하며, 사업에 참여한 여러 사람들 간의 원활한 의사소통을 위한 기준을 제공한다. 소프트웨어 수명주기 모델은 중요한 산출물이 작성되는 이정표를 정의한다. 소프트웨어 형상관리의 활동은 이러한 이정표에 맞추어 형상 항목들을 관리하고 기준선을 설정해야 한다. 소프트웨어 형상관리는 1960년대에 하드웨어를 관리하는데서 시작되어 1970년대에 미 국방부의 표준의 일부로 작성되었다. 이후 지속적으로 발전하다가 1990년대에 들어 컴퓨팅 환경이 복잡해지고 품질 기준이 엄격해지면서 본격적으로 적용되기 시작했다. 현재의 소프트웨어 형상관리는 복잡해진 개발 환경에서 소프트웨어를 체계적으로 작성하고 관리하여 좋은 품질의 소프트웨어를 생산하고, 새로운 버전의 소프트웨어를 보다 효율적으로 만들기 위해 반드시 필요한 프로세스 중의 하나이다. 소프트웨어는 소프트웨어 개발사업의 어느 단계에서나 변경이 일어난다. 변경이 일어나면 소프트웨어 개발 산출물들의 배열에 변화가 일어나고, 새로운 형상이 구성된다. “형상 관리”란 이러한 소프트웨어 개발 산출물들의 배치나 구성을 관리하는 것이다. 형상관리는 프로젝트의 생명주기 동안 제품의 무결성과 변경에 대한 추적성을 확보하고, 프로젝트에서 변경이 발생되었을 때, 처리하는 메커니즘을 제공하기 위함이다. (제공되는 메커니즘으로는 형상 관리 대상 파악, 베이스라인 지정, 버전관리, 접근제어 등)[2]
특징[편집]
형상관리 시스템은 프로젝트 자원의 'Undo' 기능으로, 프로젝트 수행 도중 변경한 여러 형상 항목에 결함이 발견될 경우, 언제든지 형상항목을 변경 이전의 상태로 되돌릴 수 있다. 여기서 변경 이전의 상태라 함은 형상관리를 통해 변경 이력을 잘 저장하고, 뒤에서 설명할 베이스라인을 잘 설정하였다는 것이 전제 조건이 된다. 하나의 형상을 여러 명이 동시에 작업을 해야 할 때도, 형상관리 시스템을 이용하면 사전에 작업 순서를 조정하거나, 병행해서 작업한 후 발생하는 충돌을 간단하게 해결할 수 있다. 또한, 과거 특정 시점의 작업 내역을 조회할 수도 있다. 형상관리는 형상 식별, 형상 통제, 버전관리, 배포관리 등 다양한 활동을 포함한다. 다양한 형상관리 활동 중에서도 버전관리, 배포관리(빌드 자동화), 변경관리는 소프트웨어 개발을 위한 기초적인 활동이다. 버전관리에서는 형상항목의 변경 이력 관리, 동시에 다양한 버전의 형상 항목 관리, 형상항목 충돌 방지 등을 할 수 있다. 배포관리에서는 배포된 형상항목 추적성을 관리하고, 버전관리 시스템에 등록된 소스 파일을 연계하여 배포 자동화를 수행한다. 변경관리에서는 형상항목 변경요인 등록, 변경요인에 대한 변경된 형상 항목 추적 관리, 형상 이력의 분석을 통한 소프트웨어 상태 모니터링을 하게 된다.[3]
- 자원의 중앙 집중적 통합관리
- 형상관리를 하게 되면 가장 먼저 하는 일이 대상 자원들을 구분하고 구조화하는 작업을 하게 된다. 그리고 나서 대상 자원들을 특정한 저장소에 모아두게 된다. 이렇게 하여 자원의 분산 및 중복 보관을 막게 된다.
- 자원들의 효율적인 버전 및 이력 관리
- 형상관리의 시작이 버전 및 이력관리에서 출발했 듯이 가장 기본적인 것이라 할 수 있다. 자원들이 변화가 일어날 때마다 변화에 관련되는 정보, 즉 누가, 언제, 왜, 어떻게 등의 정보를 관리하는 기능이다. 많이 보급되고 있는 문서관리/이력관리 툴들이 형상관리의 일부인 것이다.
- 작업 공간의 효율적 사용
- 형상관리 도구들은 고유한 형태의 자원저장소를 보유하고 있으며, 사용자별 또는 작업그룹별로 리포지토리를 접근하거나 볼 수 있는 권한을 제어할 수 있도록 해 준다.
- 작업의 진행상태 파악 및 효율적 분배
- 대부분의 형상관리 도구들이 트래킹 기능을 가지고 있어 각 작업 단위별 작업의 진행상태 및 경과정도 등을 파악할 수 있다. 뿐만 아니라 개발자, 개인별로 작업의 상태 등을 파악할 수 있어서 관리자들은 작업을 분해하기가 쉬워진다.
- 다양한 리포트
- 개발 및 유지보수 동안에 발생하는 다양한 정보들을 기록하고 관리하여 다양한 리포트 형태로 제공한다.
- 작업 프로세스 지원
- 형상관리 도구를 통해 각 작업 단계별로 필요한 작업들을 미리 정의하고, 거기에 준하여 작업할 수 있도록 지원한다는 의미이다.
- 효율적이고 정형화된 의사소통 수단 제공
- 현재 나와 있는 형상관리 도구들은 자체적으로 정형화된 형태의 다양한 변경 요청서를 제공한다. 이를 이용하여 사용자들은 자신의 변경 사유를 기술하게 되고, 이것이 형상관리 도구 내에서 각 개인 사용자들에게 할당되게 되는 것이다.[4]
종류[편집]
깃[편집]
깃(Git)은 컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템이다. 소프트웨어 개발에서 소스 코드 관리에 주로 사용되지만 어떠한 집합의 파일의 변경사항을 지속적으로 추적하기 위해 사용될 수 있다. 기하학적 불변 이론을 바탕으로 설계됐고, 분산 버전 관리 시스템으로서 빠른 수행 속도에 중점을 두고 있는 것이 특징이며 데이터 무결성, 분산, 비선형 워크플로를 지원한다. 깃은 2005년에 리눅스 커널 개발을 위해 초기 개발에 기여한 다른 커널 개발자들과 함께 2005년에 리누스 토발즈가 처음 개발한 것이다. 2005년부터 지금까지 주니오 하마노(Junio Hamano)가 소프트웨어의 유지보수를 맡고 있다. 다른 대부분의 분산 버전 관리 시스템처럼, 또 대부분의 클라이언트-서버 시스템과 달리, 모든 노드의 모든 깃 디렉터리는 네트워크 접속이나 중앙 서버와는 독립적으로 동작하는 완전한 이력 및 완전한 버전 추적 기능을 갖춘 성숙한 저장소이다.[5]
서브버전[편집]
서브버전(SVN)은 여러 명이 작업하는 프로젝트의 버전 관리나 각자 만든 소스의 통합과 같은 문제를 해결하기 위해 저장소를 만들어 그곳에 소스를 저장해 소스 중복이나 여러 문제를 해결하기 위한 형상 관리 및 소스 관리 툴이다. 프로젝트 소스는 서브버전 서버의 트렁크라는 곳에 있는데, 자신의 로컬 저장소에 트렁크의 소스를 다운받아 수정 및 추가 후 다시 업로드하는 방식이다. 자신만의 소스를 다른 개발자들과 떨어져서 작업하려면 브랜치를 만들어 작업 후 자기자신만 접근, 개발하여 완성되면 머지 기능을 사용하여 트렁크와 소스를 합치면 된다.[6] 서브버전의 필요성은 여러 가지가 있다. 기존의 파일 시스템 공유 등으로 문제 발생 시 복구가 가능하며, 프로젝트 진행 중 과거의 특정 시점으로 돌아가야 하는 경우에 필요하다. 여러 사람이 같은 프로젝트에 참여할 경우에도 필요하다. 각자가 수정한 부분을 팀원 전체가 동기화하는 과정을 자동화할 때, 소스 코드의 변경 사항을 추적할 때, 소스 코드에서 누가 수정했는지 추적할 때 필요하며, 대규모 수정 작업을 더욱 안전하게 진행하거나, 마이너 버전(branch)으로 프로젝트에 영향을 최소화하면서 새로운 부분을 개발하기 위해 필요하다.[7] 장점은 원자적 커밋을 지원하므로 다른 사용자의 커밋과 엉키지 않는다. 실패 시 롤백이 가능하며, 직관적이다. 파일과 디렉터리의 삭제, 이동, 이름 변경, 복사를 지원한다. 소스 파일 이외에 이진 파일(텍스트 파일이 아닌, 컴퓨터 파일)도 효율적으로 저장할 수 있으며, 디렉터리도 버전 관리를 할 수 있다. 저장소의 크기에 상관없이 일정한 시간 안에 가지치기나 태그를 할 수 있고, 처리 속도가 상대적으로 빠르다. 단점은 소스 코드는 병합이 가능하지만 이진 파일은 어느 한쪽을 버릴 수밖에 없다. 개별 개발자만의 개발 이력을 가질 수 없으며, .SVN 디렉터리로 인해 저장소가 다소 지저분한 느낌을 준다. 잦은 커밋으로 인해 리비전 번호가 많이 증가할 수 있고, 충돌이 일어날 확률이 높다.[7] 서브버전은 자동 쓰기를 지원하므로, 쓰기 도중 중단으로 인한 저장소 내의 불일치나 손상을 피할 수 있다. 이름을 바꾸거나, 복사하거나, 파일을 지워도 계정 기록을 유지한다. 시스템이 등록부, 개명, 파일 메타데이터에 대해서도 판본 호수를 지정 관리한다. 사용자는 디렉터리 전체를 빠르게 옮기거나 복사하면서도 전체의 개정 이력을 보유할 수 있다. 심볼릭 링크도 판본 호수를 지정하고, 이진 파일의 경우 한번 저장한 후 변경될 경우 차이점만 저장하기 때문에 저장소를 효율적으로 사용할 수 있다. 아파치 HTTP 서버를 네트워크 서버로, 웹대브/델타-V를 통신규약으로 사용한다. 서브버전 서버라는 독립된 서버 프로세스도 있어서 TCP/IP를 통해 전용 통신규약을 사용한다. 소스 저장소의 크기에 관계없이 일정한 시간 안에 가지치기(branching)나 태그 넣기(tagging)를 할 수 있다. 태생적으로 클라이언트-서버, 계층 라이브러리 설계를 채택한다. 클라이언트/서버 통신규약이 버전 간 차이를 양방향으로 보냄. 소스 저장소로의 접근이 최적화되어 있음으로, 소스 저장고에서 필요 없는 네트워크 트래픽을 줄일 수 있다.[8]
각주[편집]
- ↑ 〈소프트웨어 구성 관리〉, 《위키백과》
- ↑ 브로콜리, 〈형상관리〉, 《네이버 블로그》, 2014-09-21
- ↑ mobile, 〈(SE) 소프트웨어 형상관리〉, 《티스토리》, 2019-01-22
- ↑ gmood, 〈형상관리 ② - 형상관리 도구의 필요성〉, 《티스토리》, 2010-01-01
- ↑ 〈깃 (소프트웨어)〉, 《위키백과》
- ↑ gillog, 〈SVN(Subversion) - 개념 및 명령어〉, 《벨로그》, 2020-11-05
- ↑ 7.0 7.1 나트루, 〈(SVN) SVN이란 ? 장점 , 단점 , 용어 정리〉, 《티스토리》, 2020-09-08
- ↑ 〈서브버전〉, 《위키백과》
참고자료[편집]
- 〈소프트웨어 구성 관리〉, 《위키백과》
- 브로콜리, 〈형상관리〉, 《네이버 블로그》, 2014-09-21
- gmood, 〈형상관리 ② - 형상관리 도구의 필요성〉, 《티스토리》, 2010-01-01
- mobile, 〈(SE) 소프트웨어 형상관리〉, 《티스토리》, 2019-01-22
- 〈깃 (소프트웨어)〉, 《위키백과》
- gillog, 〈SVN(Subversion) - 개념 및 명령어〉, 《벨로그》, 2020-11-05
- 나트루, 〈(SVN) SVN이란 ? 장점 , 단점 , 용어 정리〉, 《티스토리》, 2020-09-08
- 〈서브버전〉, 《위키백과》
같이 보기[편집]
