[정처기 필기] 「2」 | 제품 소프트웨어 패키징 - (3.2) 소프트웨어 버전 등록, 관리 기구, 빌드 자동화 기구

[정처기 필기] 「2」 | 제품 소프트웨어 패키징 - (3.2) 소프트웨어 버전 등록, 관리 기구, 빌드 자동화 기구

「1」 소프트웨어 설계

> 「2」 소프트웨어 개발

- 데이터 입 / 출력 구현, 통합 구현, > 제품 소프트웨어 패키징, 애플리케이션 테스트 관리, 인터페이스 구현

「3」 데이터베이스 구축

「4」  프로그래밍 언어 활용

「5」  정보시스템 구축 관리

 

1 소프트웨어 패키징

2 디지털 저작권 관리(DRM)

3 소프트웨어 설치 매뉴얼 작성

4 소프트웨어 사용자 매뉴얼 작성

> 5 소프트웨어 버전 등록

> 6 소프트웨어 버전 관리 도구

> 7 빌드 자동화 도구

5. 소프트웨어 버전 등록

소프트웨어 패키징의 형상 관리

 

형상 관리(SCM; Software Configuration Management)는 개발 과정에서 변경 사항을 관리하기 위해 개발된 일련의 활동

 

- 변경의 원인 알아내고 제어, 적절히 변경되는지 확인하여 담당자에게 통보

- 소프트웨어 개발의 전 단계에 적용되는 활동, 유지보수 단계에서도 수행

- 개발의 전체 비용을 줄이고, 방해 요인이 최소화되도록 보증하는 것이 목표

- 관리 항목에 소스코드, 프로젝트 계획, 분석서, 설계서, 프로그램, 테스트 케이스 등 포함

- 가시성, 추적성을 보장하여 소프트웨어 생산성, 품질 높임

- Git, CVS, Subversion 등

 

형상 관리의 중요성

 

- 지속적인 변경 사항을 체계적으로 추적, 통제할 수 있음

- 무절제한 변경 방지, 발견된 버그나 수정 사항 추적 가능

- 진행 정도를 확인하기 위한 기준, 배포본 효율적으로 관리, 동시 개발 가능

 

형상 관리 기능

 

품질 보증의 중요한 요소로 다음 기능을 수행함

 

형상 식별

: 형상 관리 대상에 이름, 관리 번호 부여, 계층(Tree) 구조로 구분하여 수정 / 추적이 용이하도록 하는 작업

버전 제어

: 다른 버전의 형상 항목을 관리, 특정 절차와 도구를 결합시키는 작업

형상 통제(변경 관리)

: 식별된 형상 항목에 대한 변경 요구를 검토, 현재의 기준선(Base Line)이 잘 반영되도록 조정하는 작업

형상 감사

: 기준선의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업

형상 기록(상태 보고)

: 형상의 식별, 통제, 감사 작업의 결과를 기록 / 관리, 보고서 작성하는 작업

 

소프트웨어의 버전 등록 관련 주요 기능

 

버전을 관리하기 위해 자료를 등록 / 갱신하는 과정에서 사용하는 용어와 의미는 다음과 같음

 

저장소(Reponsitory)

: 최신 버전의 파일들과 변경 내역에 대한 정보들이 저장된 곳

가져오기(Import)

: 아무것도 없는 저장소에 처음으로 파일을 복사

체크아웃(Check-Out)

: 수정하기 위해 저장소에서 파일 받아옴

: 소스 파일과 함께 버전 관리를 위한 파일도 받아옴

체크인(Check-In)

: 체크아웃 한 파일의 수정 완료 후 저장소의 파일을 새로운 버전으로 갱신

커밋(Commit)

: 이전에 갱신된 내용이 있는 경우에 충돌(Conflict)을 알리고, diff 도구를 이용하여 수정 후 갱신 완료

동기화(Update)

: 저장소에 있는 최신 버전으로 자신의 작업 공간을 동기화

 

소프트웨어 버전 등록 과정

 

1 가져오기(Import)

: 개발자가 저장소에 신규로 파일 추가

2 인출(Check-Out)

: 수정 작업을 진행할 개발자가 저장소에 추가된 파일을 자신의 작업 공간으로 인출

3 예치(Commit)

: 인출한 파일을 수정 후 설명을 붙여 저장소에 예치

4 동기화(Update)

: 커밋 후 새로운 개발자가 자신의 작업 공간을 동기화, 기존 개발자가 추가했던 파일이 전달

5 차이(Diff)

: 새로운 개발자가 추가된 파일의 수정 기록(Change Log)을 확인하며 이전 개발자가 처음 추가한 파일과 이후 변경된 파일의 차이 확인

6. 소프트웨어 버전 관리 도구

공유 폴더 방식

 

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

 

- 개발자들은 약속된 공유 폴더에 매일 복사

- 담당자는 공유 폴더의 파일을 자기 PC로 복사, 컴파일하여 이상 유무 확인

- 확인 과정에서 파일의 오류가 확인되면, 파일을 등록한 개발자에게 수정 의뢰

- 파일에 이상이 없다면 다음날 각 개발자들이 동작 여부 재확인

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

- SCCS, RCS, PVCS, QVCS

 

클라이언트 / 서버 방식

 

버전 관리 자료가 중앙 시스템(서버)에 저장되어 관리되는 방식

 

- 서버의 자료를 개발자별로 자신의 클라이언트로 복사하여 작업, 변경된 내용을 서버에 반영

- 모든 버전 관리는 서버에서 함

- 하나의 파일을 서로 다른 개발자가 작업할 경우 경고 메시지 출력

- 서버에 문제가 생기면, 복구 전까지 협업 / 버전 관리 작업 중단

- CVS, SVN(Subcersion), CVSNT, Clear Case, CMVC, Perforce 등

 

분산 저장소 방식

 

버전 관리 자료가 하나의 원격 저장소, 분산된 개발자 PC의 로컬 저장소에 함께 저장되어 관리

 

- 원격 저장소의 자료를 자신의 로컬 저장소로 복사하여 작업 후, 변경된 내용을 로컬 저장소에서 우선 반영(버전 관리)한 다음, 원격 저장소에 반영

- 로컬 저장소에서 버전 관리 가능, 원격 저장소에 문제 생겨도 작업 가능

- Git, GNU arch, DCVS, Bazaar, Mercurial, TeamWare, Bitkeeper, Plastic SCM 등

 

Subversion(서브버전, SVN)

 

CVS를 개선한것, 아파치 소프트웨어 재단에서 발표, 서버 / 클라이언트 방식

 

- 서버(저장소)에는 최신 버전의 파일들과 변경 내역이 관리

- 서버의 자료를 클라이언트로 복사하여 작업 후, 변경된 내용을 서버에 반영(Commit)

- 모든 개발 작업은 trunk(몸통, 줄기) 디렉터리에서 수행, 추가 작업은 branches(가지) 디렉터리 안에 별도의 디렉터리를 만들어 작업 후, trunk 디렉터리와 병합

- 커밋할 때마다 리비전(Revision) 1씩 증가

- 서버는 주로 유닉스 사용, 소스가 오픈되어 무료로 사용 가능

- CVS의 단점이었던 파일, 디렉토리의 이름 변경, 이동 가능

 

주요 명령어

add

: 새로운 파일, 디렉터리를 버전 관리 대상으로 등록

: add로 등록되지 않은 대상은 commit이 적용되지 않음

commit

: 버전 관리 대상으로 등록된 클라이언트의 소스 파일을 서버의 소스 파일에 적용

undate

: 서버의 최신 commit 이력을 클라이언트 소스 파일에 적용

: commit 전 매번 update를 수행하여 적용되지 않은 서버의 변동 내역을 클라이언트에 적용

checkout

: 버전 관리 정보, 소스파일을 서버에서 클라이언트로 받아옴

lock / unlock

: 서버의 소스 파일, 디렉토리를 잠그거나 해제

import

: 아무것도 없는 서버의 저장소에 맨 처음 소스 파일을 저장, 맨 처음 한번만 사용

export

: 버전 관리 제외한 순수 소스 파일만 서버에서 받아옴

info

: 지정한 파일경로, 마지막 수정 일자 등 정보를 표시

diff

: 지정된 파일, 경로에 이전 리비전과의 차이 표시

merge

: 다른 디렉토리에서 작업된 버전 관리 내역을 기본개발 작업과 병합

 

중앙 서버	Check-Out → → → → → ← ← ← ← ← Commit	클라이언트 A
버전 3		File
버전 2	Check-Out → → → → → ← ← ← ← ← Commit	클라이언트 B
버전 1		File

 

import로 소스 파일을 서버에 등록, 이후 버전 관리는 checkout > 작업 > add > update > commit

 

Git(깃)

 

리누스 토발즈가 개발 후 주니오 하마노에 의해 유지 보수 되고 있음, 분산 버전 관리 시스템

 

- 2개의 저장소, 로컬 저장소와 원격 저장소 존재

- 지역 저장소는 개발자들이 실제 개발을 진행하는 장소, 버전 관리 수행

- 원격 저장소는 협업하기 위해 버전을 공동 관리, 자신의 버전 관리 내역을 반영하거나 다른 개발자의 변경 내용을 가져올 때 사용

- 버전 관리가 지역 저장소에서 진행되어 버전 관리가 신속하게 처리, 원격 저장소나 네트워크에 문제 발생해도 작업 가능

- 브랜치를 이용하면, 기본 틀에 영향 주지 않으며, 다양한 형태의 기능 테스팅 가능

- 파일의 변화를 스냅샷(Snapshot)으로 저장, 이전의 스냅샷의 포인터를 가지므로 버전의 흐름 파악

 

주요 명령어

add

: 작업 내역을 지역 저장소에 저장하기 위해 스테이징 영역(Staging Area)에 추가

: '--all' 옵션으로 작업 디렉토리의 모든 파일을 스테이징 영역에 추가

commit

: 작업 내역을 지역 저장소에 저장

branch

: 새로운 브랜치 생성

: 최초로 commit 시 마스터(master) 브랜치 생성

: commit 할 때마다 해당 브런치는 가장 최근의 commit 내용을 가리킴

: '-d' 옵션으로 브랜치 삭제

checkout

: 현재 작업 중인 브랜치는 HEAD 포인터가 가리키는데, HEAD 포인터를 지정한 브랜치로 이동

merge

: 지정한 브랜치 변경 내역을 현재 HEAD 포인터가 가리키는 브랜치에 반영, 두 브랜치 병합

init

: 지역 저장소 생성

remote add

: 원격 저장소에 연결

push

: 로컬 저장소의 변경 내역을 원격 저장소에 반영

fetch

: 원격 저장소의 변경 이력만 지역 저장소로 가져와 반영

clone

: 원격 저장소의 전체 내용을 로컬 저장소로 복제

 

원격 저장소	Fetch / Clone → → → → → ← ← ← ← ← Push	로컬 저장소 A
버전 3		버전 3	버전 2	버전 1
버전 2	Fetch / Clone → → → → → ← ← ← ← ← Push	로컬 저장소 B
버전 1		버전 3	버전 2	버전 1

 

init으로 지역 저장소 만들고, remote add로 원격 저장소에 연결 후, add > all > commit > push, 이후 버전 관리는 fetch > 작업 > add > commit > push

7. 빌드 자동화 도구

빌드 자동화 도구의 개요

 

빌드란 소스 코드 파일들을 컴파일한 후, 여러 모듈을 묶어 실행 파일로 만드는 과정인데, 이러한 빌드, 테스트, 배포를 자동화하는 도구

 

- 애자일 환경에서 하나의 작업 완료 시 모듈 단위의 코드들을 지속적으로 통합, 지속적인 통합(Continuous Integration) 개발 환경에서 유용하게 활용

- Ant, Make, Maven, Gradle, Jenkins

 

Jenkins

 

JAVA 기반 오픈 소스 형태, 가장 많이 사용

 

- 서블릿 컨테이너에서 실행되는 서버 기반 도구

- SVN, Git 등 대부분 형상 관리 도구와 연동 가능

- 친숙한 Web GUI 제공

- 여러 컴퓨터를 이용한 분산 빌드나 테스트 가능

 

Gradle

 

Groovy 기반 오픈 소스 형태, 안드로이드 앱 개발 환경에서 사용

 

- 플러그인 설정하면, JAVA, C/C++, Python 등 언어도 빌드 가능

- Groovy를 사용하여 만든 DSL(Domain Specific Language)을 스크립트 언어로 사용

- 실행할 처리 명령을 태스크(Task)로 만든 후 태스크 단위로 실행

- 이전의 태스크를 재사용하거나 다른 시스템의 태스크 공유하는 빌드 캐시 기능 지원, 빌드의 속도 향상

 

 

 

 

 

 

 

 

출처 | <시나공> 정보처리기사 필기 2024 기본서 (길벗알앤디)