소프트웨어 패키징의 형상 관리(SCM; Software Configuration Management)
- 형상 관리: SW 개발 과정에서 SW 변경 사항을 관리하기 위해 개발된 일련의 활동
- 소프트웨어 개발의 전 단계에 적용되는 활동이며, 유지보수 단계에서도 수행
1)SCM 중요성
- 소프트웨어의 변경 사항을 체계적으로 추적하고 통제할 수 있음
- 제품 소프트웨어에 대한 무절제한 변경 방지
- 진행 정도를 확인하기 위한 기준으로 사용될 수 있음
2) 형상 관리 기능 식통감기
→ 형상 식별 : 형상 관리 대상에 이름과 관리 번호를 부여하고, 계층(Tree) 구조로 구분하여 수정 및 추적이 용이하도록 하는 작업
→ 형상 통제(변경 관리) : 식별된 형상 항목에 대한 변경 요구를 검토하여 현재의 기준선(베이스 라인, Base line)이 잘 반영될 수 있도록 조정하는 작업
→ 형상 감사 : 기준선(베이스 라인)의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업
→ 형상 기록(상태 보고) : 형상의 식별, 통제, 감사 작업의 결과를 기록, 관리하고 보고서를 작성하는 작업
버전 제어 : 소프트웨어 업그레이드나 유지 보수 과정에서 생성된 다른 버전의 형상 항목을 관리하고, 이를 위해 특정 절차와 도구(Tool)를 결합시키는 작업
3) 소프트웨어 버전 등록 관련 주요 용어
- 저장소(Repository) 최신 버전의 파일들과 변경 내역에 대한 정보들이 저장되어 있는 곳
- 가져오기(Import) 버전 관리가 되고 있지 않은 빈 저장소에 처음으로 파일을 복사하는 것
- 체크아웃(Check-Out) 프로그램을 수정하기 위해 저장소(Repository)에서 파일을 받아오는 것
- 체크인(Check-In) 체크아웃 한 파일의 수정을 완료한 후, 저장소(Repository)의 파일을 새로운 버전으로 갱신하는 것
- 커밋(Commit) 체크인을 수행할 때 이전에 갱신된 내용이 있는 경우에는 충돌(Confilct)을 알리고 diff도구를 이용해 수정한 후, 갱신을 완료함
- 동기화(Update) 저장소에 있는 최신 버전으로 자신의 작업 공간(로컬/지역 저장소)을 동기화하는 것
4) 소프트웨어 버전 등록 과정 #임체컴업디
- 가져오기(Import) → 인출(Check-Out) → 예치(Commit) → 동기화(Update) → 차이(Diff)
5) 제품 소프트웨어의 형상 관리 역할 20년 3회 기출문제
- 형상 관리를 통해 이전 리비전이나 버전에 대한 정보에 접근 가능하여 배포본 관리에 유용
- 불필요한 사용자의 소스 수정 제한
- 동일한 프로젝트에 대해 여러 개발자 동시 개발 가능
버전 관리 도구
1) 공유 폴더 방식
- 버전 관리 자료가 로컬 컴퓨터의 공유 폴더에 저장되어 관리되는 방식
- 개발자들은 개발이 완료된 파일을 약속된 공유 폴더에 매일 복사함
- 담당자는 공유 폴더의 파일을 자기 PC로 복사해 컴파일 한 후 이상 유무 확인
- 파일의 변경 사항을 데이터베이스에 기록하며 관리
eg. SCCS, RCS, PVCS, QVCS
2) 클라이언트/서버 방식
- 버전 관리 자료가 중앙 시스템(서버)에 저장되어 관리되는 방식
- 서버의 자료를 개발자별로 자신의 PC(클라이언트)로 복사해 작업한 후 변경된 내용을 중앙 서버에 반영
- 하나의 파일을 서로 다른 개발자가 작업할 경우 경고 메시지 출력
- 서버에 문제가 생기면 다른 개발자와의 협업 및 버전 관리 작업은 중단
eg. CVS, SVN(Subversion)
3) 분산 저장소 방식
- 하나의 원격 저장소와 분산된 개발자 PC의 로컬 저장소에 함께 저장되어 관리되는 방식
- 개발자별로 원격 저장소의 자료를 자신의 로컬 저장소로 복사해 작업한 후 변경 된 내용을 로컬 저장소에서 우선 반영(Commit)한 다음 이를 원격 저장소에 반영(Push)
- 원격 저장소에 문제가 생겨도 로컬 저장소의 자료를 이용해 작업 가능
- 로컬 저장소에서 작업을 수행할 수 있어 처리속도가 빠름
eg. Git, Bitkeeper
4)대표적인 버전 관리 도구
4.1) 클라이언트/서버 방식 : SVN(Subversion)
- CVS를 개선한 것으로 아파치 소프트웨어 재단에서 2000년 발표함
- 모든 개발 작업은 trunk 디렉터리에서 수행되며, 추가 작업은 branches 디렉터리 안에 별도의 디렉터리를 만들어 작업을 완료한 후 trunk 디렉터리와 병합(merge)
- 서버는 주로 유닉스(UNIX) 사용
- 오픈 소스로 무료사용 가능
- CVS의 단점이었던 파일이나 디렉터리의 이름 변경, 이동 등이 가능
- add 새로운 파일이나 디렉터리를 버전 관리 대상으로 등록
- commit 버전 관리 대상으로 등록된 클라이언트의 소스 파일을 서버의 소스 파일에 적용
- Commit할 때마다 리비전(Revision)이 1씩 증가
- update 서버의 최신 commit이력을 클라이언트의 소스파일에 적용
- checkout 버전 관리 정보와 소스 파일을 서버에서 클라이언트로 받아옴
- lock/unlock 서버의 소스 파일이나 디렉터리를 잠그거나 해제
- import 아무것도 없는 서버의 저장소에 맨 처음 소스 파일을 저장하는 명령으로 한 번 사용 후 다시 사용하지 않음
- export 버전 관리에 대한 정보를 제외한 순수한 소스 파일만을 서버에서 받아옴
- info 지정한 파일에 대한 위치나 마지막 수정 일자 등에 대한 정보를 표시
- diff 지정된 파일이나 경로에 대해 이전 리비전과의 차이를 표시
- merge 다른 디렉터리에서 작업된 버전 관리 내역을 기본 개발 작업과 병합
4.2) 분산 저장소 방식: Git(깃)
- 리누스 토발즈(Linus Torvalds)가 2005년 리눅스 커널 개발에 사용할 관리 도구로 개발한 이후 주니오 하마노(Junio Hamano)에 의해 유지 보수되고 있음
- 원격 저장소는 여러 사람들이 협업을 위해 버전을 공동 관리하는 곳으로, 자신의 버전 관리 내역을 반영(Push)하거나 다른 개발자의 변경 내용을 가져올 때(Fetch) 사용
- 로컬 저장소는 개발자들이 본인의 실제 개발을 진행하는 장소로 버전 관리가 수행됨
- 브랜치(Branch)를 이용하면 기본 버전 관리 틀에 영향을 주지 않으면서 다양한 형태의 기능 테스팅 가능
- 파일의 변화를 스냅샷(Snapshot)으로 저장, 이전 스냅샷의 포인터를 가지므로 버전의 흐름 파악 가능
- add 작업 내역을 로컬 저장소에 저장하기 위해 스테이징 영역에 추가함,
- ‘--all’ 옵션으로 작업 디렉터리의 모든 파일을 스테이징 영역에 추가 가능
- commit 작업 내역을 로컬 저장소에 저장
- branch 새로운 브랜치를 생성,
- 최초로 commit을 하면 마스터(master) 브랜치가 생성됨,
- commit 할 때마다 해당 브랜치는 가장 최근의 commit한 내용을 가리킴,
- ‘-d’옵션으로 브랜치 삭제 가능
- checkout 지정한 브랜치로 이동
- merge 지정한 브랜치의 변경 내역을 현재 HEAD 포인터가 가리키는 브랜치에 반영, 두 브랜치를 병합
- init 로컬 저장소를 생성
- remote 원격 저장소에 연결
- push 로컬 저장소의 변경 내역을 원격 저장소에 반영
- fetch 원격 저장소의 변경 이력만을 로컬 저장소로 가져와 반영
- clone 원격 저장소의 전체 내용을 로컬 저장소로 복제
- fork 지정한 원격 저장소의 내용을 자신의 원격 저장소로 복제
일반적 순서 : git init → git remote add → git add -all → git commit → git push
'Challenges > 정보처리기사' 카테고리의 다른 글
[정보처리기사]2.소프트웨어 개발/애플리케이션 테스트 관리/ 동적 테스트 (0) | 2021.08.25 |
---|---|
[정보처리기사]2.소프트웨어 개발/애플리케이션 테스트 관리/ 애플리케이션 테스트 (0) | 2021.08.25 |
[정보처리기사]2.소프트웨어 개발/제품 소프트웨어/디지털 저작권 관리 (0) | 2021.08.24 |
[정보처리기사]2.소프트웨어 개발/제품 소프트웨어/소프트웨어 패키징 & 릴리즈 노트 (0) | 2021.08.24 |
[정보처리기사]2.소프트웨어 개발/통합 구현/개발 지원 도구 (0) | 2021.08.23 |