[정보처리기사 실기] 11장 요약 _ 제품 소프트웨어 패키징

[11] 제품 소프트웨어 패키징

 

11.1 소프트웨어 패키징

소프트웨어 패키징의 개요

- 모듈별로 생성한 실행 파일들을 묶어 배포용 설치 파일을 만드는 것. 

- 개발자가 아니라 사용자 중심으로 진행함. 

- 소스 코드는 향후 관리를 고려하여 모듈화하여 패키징함. 

- 사용자가 소프트웨어를 사용하게 될 환경을 이해하여, 다양한 환경에서 소프트웨어를 손쉽게 사용할 수 있도록 일반적인 배포 형태로 패키징함. 

- 사용자를 중심으로 진행되는 작업이므로 사용자의 편의성 및 실행 환경을 우선적으로 고려해야 함. 

 

패키징 시 고려사항

- 사용자의 시스템 환경, 즉 운영체제, CPU, 메모리 등에 필요한 최소 환경을 정의함. 

- UI는 사용자가 눈으로 직접 확인할 수 있도록 시각적인 자료와 함께 제공하고 메뉴얼과 일치시켜 패키징함.

- 소프트웨어는 단순히 패키징하여 배포하는 것으로 끝나는 것이 아니라 하드웨어 함께 관리 될 수 있도록 Managed Service 형태로 제공하는 것이 좋음. 

- Managed Service: 고객이 사용중인 소프트웨어를 24시간 모니터링 하면서 문제 발생 시 현장에 바로 출동하여 필요한 점검을 수행하는 등의 체계적인 운영관리와 유지보수를 수행하는 서비스 

- 고객의 편의성을 고려한 안정적인 배포가 중요함. 

- 다양한 사용자 요구사항을 반영할 수 있도록 패키징의 변경 및 개선에 대한 관리를 항상 고려함. 

 

 

패키징 작업 순서

- 패키징 주기는 소프트웨어 개발 기법에 따라 달라지는데, 짧은 개발 주기를 반복하는 애자일 기법의 경우 보통 2-4주 내에서 지정하며, 각 주기가 끝날 때마다 패키징을 수행함. 

- 프로젝트 개발 과정에서 주기별로 패키징한 결과물은 테스트 서버에 배포. 

- 마지막 개발 과정을 거처 최종 패키징한 결과물은 고객이 사용할 수 있도록 온라인 또는 오프라인으로 배포함. 

• 온라인 배포: 별도로 마련한 운영 서버에 설치 및 사용 매뉴얼과 함께 배포 파일을 등록하여 고객이 직접 다운받아 사용할 수 있도록 함. 
• 오프라인 배포: CD-ROM이나 DVD, USB 등에 설치 및 사용 메뉴얼과 함께 배포 파일을 담음. 

- 패키징 작업 순서

1) 기능 식별: 작성된 코드의 기능을 확인함. 

2) 모듈화: 확인된 기능 단위로 코드들을 분류

3) 빌드 진행: 모듈 단위로 실행 파일을 만듬. 빌드란 소스코드 파일 들을 컴퓨터에서 실행할 수 있는 제품 소프트웨어로 변환하는 과정 또는 결과물. 

4) 사용자 환경 분석: 웹, 모바일, PC 등 소프트웨어가 사용될 환경이나 운영체제, CPU, RAM 등의 최소 운영환경을 정의함. Window 같은 경우 32bit와 64bit 두가지 버전으로 패키징. 

5) 패키징 및 적용 시험: 빌드된 실행 파일들을 정의된 환경에 맞게 배포용 파일 형식으로 패키징 함. 정의된 환경과 동일한 환경에서 패키징 결과를 테스팅 한 후 소프트웨어에 대한 불편 사항을 사용자 입장에서 확인. 

6) 패키징 변경 개선: 확인된 불편 사항을 반영하기 위한 패키징의 변경 및 개선을 진행. 

7) 배포: 배포 수행 시 오류가 발생하면 해당 개발자에게 전달하여 수정을 요청. 

 

주요 배포용 파일 형식

msi	Window 용 패키지 형식
dmg	Mac OS 용 패키지 형식
jar	java 응용 소프트웨어나 라이브러리를 배포하기 위한 패키지 형식
war	java Servlet, java Class, xml 및 웹 어플리케이션 서비스를 제공하기 위한 패키지 형식
ear	jar과 war을 묶어 하나의 애플리케이션 서비스를 제공할 수 있는 패키지 형식.
apk	안드로이드용 앱 패키지 형식
ipa	IOS용 앱 패키지 형식

11.2 릴리즈 노트 작성

릴리즈 노트의 개요

- 개발 과정에서 정리된 릴리즈(배포) 정보를 소프트웨어의 최종 사용자인 고객과 공유하기 위한 문서. 

- 릴리즈 노트를 통해 테스트 진행 방법에 대한 결과와 소프트웨어 사양에 대한 개발팀의 정확한 준수 여부를 확인할 수 있음. 

- 소프트웨어에 포함된 전체 기능, 서비스의 내용, 개선 사항 등을 사용자와 공유할 수 있음. 

- 릴리즈 노트를 이용해 소프트웨어의 버전 관리나 릴리즈 정보를 체계적으로 관리할 수 있음. 

- 릴리즈 노트는 소프트웨어의 초기 배포 시 또는 출시 후 개선 사항을 적용한 추가 배포 시에 제공함. 

- 소프트웨어의 초기 배포시 제공되는 릴리즈 노트에는 소프트웨어에 포함된 기능이나 사용환경에 대한 내용을 확인할 수 있음. 

- 소프트웨어 출시 후 개선된 작업이 있을 때마다 관련 내용을 릴리즈 노트에 담에 제공. 

- 릴리즈 노트에 정리된 정보들은 철저한 테스트를 거친 것이며, 개발 팀에서 제공하는 소프트웨어 사양에 대한 최종 승인을 얻은 후 문서화 되어 제공함. 

 

릴리즈 노트 초기 버전 작성 시 고려사항

- 릴리즈 노트는 정확하고 완전한 정보를 고려하여 작성함. 

- 신규 소스, 빌드 등의 이력이 정확하게 관리되어 변경 또는 개선된 항목에 대한 이력 정보들도 작성되어야 함. 

- 릴리즈 노트 작성에 포함되는 항목(표준 형식은 없음)

• Header(머릿말): 릴리즈 노트 이름, 소프트웨어 이름, 릴리즈 버전, 릴리즈 날짜, 릴리즈 노트 날짜, 릴리즈 노트 버전 등
• 개요: 소프트웨어 및 변경 사항 전체에 대한 간략한 내용
• 목적: 해당 릴리즈 버전에서의 새로운 기능이나 수정된 기능의 목록과 릴리즈 노트의 목적에 대한 간략한 개요
• 문제 요약: 수정된 버그에 대한 간략한 설명 또는 릴리즈 추가 항목에 대한 요약
• 재현 항목: 버그 발견에 대한 과정 설명
• 수정/개선 내용: 버그를 수정/개선한 내용을 간단히 설명
• 사용자 영향도: 사용자가 다른 기능들을 사용하는데 있어 해당 릴리즈 버전에서의 기능 변화가 미칠 수 있는 영향에 대한 설명
• SW 지원 영향도: 해당 릴리즈 버전에서의 기능 변화가 다른 응용 프로그램들을 지원하는 프로세스에 미칠 수 있는 영향에 대한 설명. 
• 노트: SW/HW 설치 항목, 업그레이드, 소프트웨어 문서화에 대한 참고 항목
• 면책 조항: 회사 및 소프트웨어와 관련하여 참조할 사항 (예) 프리웨어, 불법 복제 금지 등
• 연락처: 사용자 지원 및 문의 응대를 위한 연락처 정보

 

릴리즈 노트 추가 버전 작성 시 고려사항

- 소프트웨어의 테스트 과정에서 베타 버전이 출시되거나 긴급한 버그 수정, 업그레이드와 같은 자체 기능 향상, 사용자 요청 등의 특수한 상황이 발생하는 경우 릴리즈 노트를 추가로 작성. 

- 중대한 오류가 발생하여 긴급하게 수정하는 경우에는 릴리즈 버전을 출시하고 버그 번호를 포함한 모든 수정된 내용을 담아 릴리즈 노트를 작성함. 

- 소프트웨어에 대한 기능 업그레이드를 완료한 경우에는 릴리즈 버전을 출시하고 릴리즈 노트를 작성. 

- 사용자로부터 접수된 요구사항에 의해 추가나 수정된 경우 자체 기능 향상과는 다른 별도의 릴리즈 버전으로 출시하고 릴리즈 노트를 작성. 

 

릴리즈 노트 작성 순서

1) 모듈 식별: 모듈별 빌드 수행 후 릴리즈 노트에 작성될 내용들을 확인함. 

2) 릴리즈 정보 확인: 릴리즈 노트 이름, 소프트웨어 이름, 릴리즈 버전, 릴리즈 날짜, 노트 날짜, 노트 버전 등을 확인.

3) 릴리즈 노트 개요 작성: 소프트웨어 및 변경 사항 전체에 대해 간략한 내용을 작성. 

4) 영향도 체크: 버그나 이슈 관련 내용 또는 해당 릴리즈 버전에서의 기능 변화가 다른 소프트웨어나 기능을 사용하는 데 미칠 수 있는 영향에 대해 기술함. 

5) 정식 릴리즈 노트 작성: 머릿말, 개요, 영향도 체크 항목을 포함하여 정식 릴리즈 노트에 작성될 기본 사항들을 작성. 

6) 추가 개선 항목 식별: 추가 버전 릴리즈 노트 작성이 필요한 경우 추가 릴리즈 노트를 작성함.

 

 

11.3 디지털 저작권 관리

저작권의 개요

- 저작권이란 소설, 시, 논문, 강연, 연술, 음악, 연극, 무용, 회화, 서예, 건축물, 사진, 영상, 지도, 도표, 컴퓨터 프로그램 저작물 등에 대하여 창작자가 가지는 배타적 독점적 권리로 타인의 침해를 받지 않을 고유한 권한. 

- 컴퓨터 프로그램들과 같이 복제하기 쉬운 저작물에 대해 불법 복제 및 배포 등을 막기 위한 기술적인 방법을 통칭해 저작권 보호 기술이라고 함. 

 

디지털 저작권 관리(DRM)의 개요

- 저작권자가 배포한 디지털 콘텐츠가 저작권자가 의도한 용도로만 사용되도록 디지털 콘텐츠의 생성, 유통, 이용까지의 전 과정에 걸처 사용되는 디지털 콘텐츠 관리 및 보호 기술. 

- 원본 콘텐츠가 아날로그인 경우, 디지털로 변환한 후 패키저에 의해 DRM 패키징을 수행함. 

- 콘텐츠의 크기에 따라 음원이나 문서 같이 크기가 작은 경우에는 사용자가 콘텐츠를 요청하는 시점에서 실시간으로 패키징을 수행하고, 크기가 큰 경우에는 미리 패키징을 수행한 후 배포함. 

- 패키징을 수행하면 콘텐츠에는 암호화된 저작권자의 전자서명이 포함되고 저작권자가 설정한 라이선스 정보가 클리어링 하우스에 등록됨. 

- 클리어링 하우스

• 디지털 저작권라이선스의 중개 및 발급을 수행하는 곳. 
• 디지털 저작물의 이용 내역을 근거로 저작권료의 정산 및 분배가 수행됨. 
• 클리어링에는 결제라는 의미도 있으므로 결제가 이루어지는 곳이라고 해석할 수도 있음.

- 사용자가 콘텐츠를 사용하기 위해서는 클리어링 하우스에 등록된 라이선스 정보를 통해 사용자 인증과 콘텐츠 사용 권한 소유 여부를 확인 받아야 함. 

- 종량제 방식(실제 사용한 양에 따라 요금을 차등 적용하는 방식)을 적용한 소프트웨어의 경우 클리어링 하우스를 통해 서비스의 실제 사용량을 측정하여 이용한 만큼의 요금을 부과함. 

 

디지털 저작권 관리의 흐름도

- 클리어링 하우스: 저작권에 대한 사용 권한, 라이선스 발급, 사용량에 따른 결제 관리를 수행하는 곳. 

- 콘텐츠 제공자: 콘텐츠를 제공하는 저작권자

- 패키저: 콘텐츠를 메타 데이터(데이터에 대한 속성 정보 등을 설명하기 위한 데이터)와 함께 배포 가능한 형태로 묶어 암호화하는 프로그램. 

- 콘텐츠 분배자: 암호화된 콘텐츠를 유통하는 곳이나 사람. 

- 콘텐츠 소비자: 콘텐츠를 구매해서 사용하는 주체. 

- DRM 컨트롤러: 배포된 콘텐츠의 이용 권한을 통제하는 프로그램. 

- 보안 컨테이너: 콘텐츠 원본을 안전하게 유통하기 위한 전자적 보안 장치. 

 

디지털 저작권 관리의 기술 요소

- 암호화: 콘텐츠 및 라이선스를 암호화하고 전자 서명을 할 수 있는 기술. 

- 키 관리: 콘텐츠를 암호화 한 키에 대한 저장 및 분배 기술

- 암호화 파일 생성: 콘텐츠를 암호화된 콘텐츠로 생성하기 위한 기술

- 식별 기술: 콘텐츠에 대한 식별 체계 표현 기술

- 저작권 표현: 라이선스의 내용 표현 기술

- 정책 관리: 라이선스 발급 및 사용에 대한 정책 표현 및 관리 기술

- 크랙 방지: 크랙에 의한 콘텐츠 사용방지 기술

- 인증: 라이선스 발급 및 사용의 기준이 되는 사용자 인증 기준

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

 

소프트웨어 설치 매뉴얼의 개요

- 소프트웨어 설치 매뉴얼: 개발 초기에서부터 적용된 기준이나 소프트웨어를 설치하는 과정에 필요한 내용을 기록한 설명서와 안내서.

- 설치 매뉴얼은 사용자를 기준으로 작성. 

- 설치 시작부터 완료할 때까지의 전 과정을 빠짐없이 순서대로 설명. 

- 설치 과정에서 표시될 수 있는 오류 메시지 및 예외 상황에 관한 내용을 별도로 분류하여 설명함. 

- 소프트웨어 설치 매뉴얼에는 목차 및 개요, 서문, 기본 사항 등이 기본적으로 포함되어 있어야 함. 

- 소프트웨어 설치 메뉴얼의 목차에는 전체 설치 과정을 순서대로 요약한 후 관련 내용의 시작 페이지를 함께 기술. 

- 소프트웨어 설치 메뉴얼의 개요에는 설치 매뉴얼의 주요 특징, 구성과 설치 방법, 순서 등의 내용을 기술.

 

서문

- 문서이력

- 설치 매뉴얼의 주석

• 주의 사항: 소프트웨어를 설치할 때 사용자가 반드시 알고 있어야 하는 중요한 내용 기술. 
• 참고 사항: 설치에 영향을 미칠 수 있는 사용자의 환경이나 상황에 대한 내용 기술

- 설치 도구의 구성

• exe(실행 가능한 파일의 확장자), dll(장치의 드라이버 등 동적 링크 라이브러리 파일의 확장자), ini(Windows 기반 컴퓨터의 기본 구성 값을 변경해야 하는 경우 사용되는 설정 초기화 파일의 확장자), chm(HTML로 구성된 도움말 파일의 확장자) 등 설치 관련 파일에 대해 설명
• 폴더 및 설치 프로그램 실행 파일에 대해 설명
• 설치 과정 및 결과가 기록되는 log 폴더에 대해 설명

- 설치 환경 체크 항목

• 사용자 환경: CPU, Memory, OS 등
• 응용 프로그램: 설치 전 다른 응용 프로그램 종료
• 업그레이드 버전: 이전 버전 존재 유무 확인
• 백업 폴더 확인: 데이터 저장 폴더를 확인하여 설치시 폴더를 동기화 시킴. 

 

기본 사항

- 소프트웨어 개요

• 소프트웨어의 주요 기능 및 UI 설명
• UI 및 화면 상의 버튼, 프레임 등을 그림으로 설명

- 설치 관련 파일

• 소프트웨어 설치에 필요한 파일 설명
• exe, ini, log 등의 파일 설명

- 설치 아이콘

- 프로그램 삭제: 소프트웨어 삭제 방법 설명

- 관련 추가 정보

• 소프트웨어 이외의 관련 설치 프로그램 정보
• 소프트웨어 제작사 등의 추가 정보 기술

 

설치 매뉴얼 작성 방법

- 사용자가 설치 과정을 이해하기 쉽도록 설치 화면을 누락없이 캡처하고 순서대로 상세히 설명함. 

- 설치 화면 UI

• 설치 실행
• 메인 화면 및 안내 창

- 설치 이상 메시지

- 설치 완료 및 결과

- FAQ

- 설치 시 점검 사항

• 설치 전 사용자의 설치 환경에 따라 점검해야 할 사항 설명
• 설치에 필요한 사용자 계정 및 설치 권한에 대해 확인할 수 있도록 설명
• 설치 과정에서 오류가 발생할 경우 점검할 수 있는 사항들에 대해 설명

- Network 환경 및 보안

- 고객 지원 방법

- 준수 정보 및 제한 보증

• 시리얼 보존, 불법 등록 사용 금지 등에 대한 준수 사항 안내.
• 저작권자 소유권 정보, SW 허가권 정보, 통신 규격 등과 관련된 내용 안내

 

설치 매뉴얼 작성 순서

1) 기능 식별: 소프트웨어의 개발 목적과 주요 기능을 흐름순으로 정리하여 기록

2) UI 분류: 설치 매뉴얼을 작성할 순서대로 UI 분류한 후 기록

3) 설치 파일/백업 파일 확인: 폴더 위치, 설치 파일, 백업 파일등의 개별적인 기능을 확인하여 기록

4) Uninstall 절차 확인: 직접 Uninstall을 수행하면서 그 순서를 단계별로 자세히 기록

5) 이상 케이스 확인: 설치 과정에서 발생할 수 있는 다양한 케이스를 만들어 해당 케이스에 대한 대체법 상세 기록.

6) 최종 매뉴얼 적용: 설치 완료된 화면과 메시지 캡쳐. 완성된 매뉴얼을 검토하고 고객 지원에 대한 내용 기록

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

 

소프트웨어 사용자 매뉴얼의 개요

- 소프트웨어 사용자 매뉴얼: 사용자가 소프트웨어를 사용하는 과정에서 필요한 내용을 문서로 기록한 설명서와 안내서. 

- 소프트웨어 배포 후 발생될 수 있는 오류에 대한 패치(프로그램의 오류 수정을 위해 프로그램의 일부 파일을 변경하는 것)나 기능에 대한 업그레이드를 위해 매뉴얼의 버전을 관리함. 

- 개별적으로 동작이 가능한 컴포넌트 단위로 매뉴얼을 작성. 

- 사용자 매뉴얼은 컴포넌트 명세서와 컴포넌트 구현 설계서를 토대로 작성. 

 

기본 사항

- 소프트웨어 개요

- 소프트웨어 사용 환경

- 소프트웨어 관리

- 모델, 버전별 특징

- 기능, 인터페이스의 특징

- 소프트웨어 구동 환경

 

사용자 매뉴얼 작성 순서

1) 기능 식별: 소프트웨어의 개발 목적과 사용자 활용 기능을 흐름순으로 정리하여 기록

2) 사용자 화면 분류: 메뉴별로 분류하여 기록

3) 사용자 환경 파일 확인: 폴더 위치, 사용자 로그 파일, 백업 파일 등의 개별적인 기능을 확인하여 기록

4) 초기화 절차 확인: 프로그램을 사용하기 위한 초기화 절차를 확인하고 그 단계를 순서대로 기록

5) 이상 케이스 확인

6) 최종 매뉴얼 적용: 사용과 관련된 FAQ 정리하여 기록. 

11.6 소프트웨어 버전 등록

 

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

- 형상 관리(SCM)는 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동

- 소프트웨어 변경의 원인을 알아내고 제어하며, 적절히 변경되고 있는지 확인하여 해당 담당자에게 통보. 

- 형상 관리는 소프트웨어 개발의 전 단계에 적용되는 활동이며, 유지보수 단계에서도 수행됨. 

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

 

형상 관리의 중요성

- 지속적인 소프트웨어의 변경 사항을 체계적으로 추적하고 통제할 수 있음. 

- 제품 소프트웨어에 대한 무절제한 변경을 방지할 수 있음. 

- 제품 소프트웨어에서 발견된 버그나 수정사항을 추적할 수 있음. 

- 소프트웨어는 형태가 없어서 가시성이 결핍되므로 진행 정도를 확인하기 위한 기준으로 사용될 수 있음. 

 

형상 관리 기능

- 형상 식별: 형상 관리 대상에 이름과 관리 번호를 부여하고, 계층 구조로 구분하여 수정 및 추적이 용이하도록 하는 작업.

- 버전 제어: 소프트웨어 업그레이드나 유지 보수 과정에서 생성된 다른 버전의 형상 항목을 관리하고, 이를 위해 특정 절차와 도구를 결합시키는 작업. 

- 형상 통제(변경 관리): 식별된 형상 항목에 대한 변경 요구를 검토하여 현재의 기준선(정식적으로 검토되고 합의된 제품으로, 소프트웨어 변경을 적절히 제어할 수 있도록 도와줌)이 잘 반영될 수 있도록 조정하는 작업. 

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

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

 

소프트웨어 버전 등록 관련 주요 용어

- 저장소(Repository): 최신 버전의 파일들과 변경 내역에 대한 정보들이 저장되어 있는 곳. 

- 가져오기(Import): 버전 관리가 되고 있지 않은 아무것도 없는 저장소에 처음으로 파일을 복사.

- 체크 아웃: 프로그램을 수정하기 위해 저장소에서 파일을 받아옴. 소스 파일과 함께 버전 관리를 위한 파일들도 받아옴. 

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

- 커밋(Commit): 체크인을 수행할 때 이전에 갱신된 내용이 있는 경우에는 충돌을 알리고 diff 도구를 이용해 수정한 후 갱신을 완료. 

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

 

소프트웨어 버전 등록 과정

1) 가져오기(Import): 개발자가 저장소에 신규로 파일을 추가 

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

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

4) 동기화(Update): 커밋 후 새로운 개발자가 자신의 작업 공간을 동기화 함. 이때 기존 개발자가 추가했던 파일이 전달됨. 

5) 차이(Diff): 새로운 개발자가 추가된 파일의 수정 기록을 확인하면서 이전 개발자가 처음 추가한 파일과 이후 변경된 파일의 차이를 확인함. 

11.7 소프트웨어 버전 관리 도구

 

공유 폴더 방식

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

- 개발자들은 개발이 완료된 파일을 약속된 공유 폴더에 매일 복사함. 

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

- 이상 유무 확인 과정에서 파일의 오류가 확인되면, 해당 파일을 등록한 개발자에게 수정을 의뢰. 

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

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

- 종류: SCCS, RCS, PVCS, QVCS

클라이언트/서버 방식

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

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

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

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

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

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

 

분산 저장소 방식

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

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

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

- 종류: Git, GNU arch, DCVS, Bazaar, Mercurial, TeamWare, Bikeeper, Plastic SCM

 

Subversion(서브버전, SVN)

- CVS를 개선한 것으로, 아파치 소프트웨어 재단에서 2000년에 발표. 

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

- 서버의 자료를 클라이언트로 복사해와 작업한 후 변경 내용을 서버에 반영(Commit)함. 

- 모든 개발 작업은 trunk 디렉토리에서 수행되며, branches 디렉토리 안에 별도의 디렉토리를 만들어 작업을 완료한 후 trunk 디렉토리와 병합(Merge)함. 

• trunk: 개발 과정에서 가장 중심이 되는 디렉토리. trunk 디렉토리 안에 소스 파일과 추가 작업을 위한 서브 디렉토리인 branches 디렉토리가 있음. 
• branches: 메인 개발 과정과는 별도로 새로운 기능의 테스트와 같이 추가적인 작업을 수행하기 위한 디렉토리. 하위에 작업별로 디렉토리를 만들어 개발을 진행하고 개발 결과를 trunk와 병합. 

- 커밋할 때마다 리비전(커밋의 버전으로, 처음 저장소를 만들면 00)이 1씩 증가함. 

- 클라이언트의 대부분의 운영체제에서 사용되지만, 서버는 주로 유닉스를 사용. 

- 소스가 오픈되어 있어 무료로 사용할 수 있음. 

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

- Subversion 의 주요 명령어 

• add: 새로운 파일이나 디렉터리를 버전 관리 대상으로 등록. add로 등록되지 않은 대상은 commit이 적용되지 않음. 
• commit: 버전 관리 대상으로 등록된 클라이언트의 소스 파일을 서버의 소스 파일에 적용. 
• update: 서버의 최신 commit 이력을 클라이언트의 소스 파일에 적용. commit 전에는 매번 update를 수행하여 클라이언트에 적용되지 않은 서버 변동 내역을 클라이언트에 적용함. 
• checkout: 버전관리 정보와 소스파일을 서버에서 클라이언트로 받아옴. 
• lock/unlock: 서버의 소스 파일이나 디렉토리를 잠그거나 해제. 
• import: 아무것도 없는 서버의 저장소에 맨 처음 소스 파일을 저장하는 명령으로 한 번 사용하면 다시 사용하지 않음. 
• export: 버전 관리 정보를 제외한 순수한 소스 파일만을 서버에서 받아옴. 
• info: 지정한 파일에 대한 위치나 마지막 수정 날짜 등에 대한 정보 표시
• diff: 지정된 파일이나 경로에 대해 이전 리비전과의 차이를 표시. 
• merge: 다른 디렉터리에서 작업된 버전 관리 내역을 기본 개발 작업과 병합.  

 

Git(깃)

- 리누스 토발스가 2005년 리눅스 커널 개발에 사용할 관리 도구로 개발한 이후 주니오 하마노에 의해 유지보수 되고 있음. 

- 분산 버전 관리 시스템으로 2개의 저장소, 즉 로컬 저장소와 원격 저장소가 존재. 

- 원격 저장소: 주로 웹 서버를 빌려 사용하는데, git 사용자들이 가장 많이 사용하는 웹 호스팅 서비스는 깃 허브임. 깃 허브는 오픈 소스 프로젝트에 대해서는 무료로 제공하지만 소스를 비공개로 하는 프로젝트에 대해서는 비용을 받음. 

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

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

- 버전 관리가 지역 저장소에서 진행되므로 버전 관리가 신속하게 처리되고, 원격 저장소나 네트워크에 문제가 있어도 작업이 가능함. 

- 브랜치를 이용하면 기본 버전 관리 틀에 영향을 주지 않으면서 다양한 형태의 기능 테스팅이 가능함. 

- 브랜치: 깃에서는 저장소가 처음 만들어지면 마스터 브랜치가 생성되고 이 브랜치에서 기본적인 버전 관리가 진행됨. 새로운 기능을 추가하는 작업은 새로운 브랜치를 만들어 수행하며, 작업이 정상적으로 마무리 되면 작업 내역을 마스터 브랜치에 병합. 이렇게 마스터 브랜치와 별도로 생성하는 브랜치를 토픽 브랜치, 피처 브랜치라고 하며 각각의 브랜치는 다른 브랜치에 영향을 주지 않으므로 독립적인 여러 작업을 동시에 진행할 수 있음. 

- 파일의 변화를 스냅샷(영문자와 숫자가 혼합된 40자리 문자열)으로 저장하는데, 스냅샷은 이전 스냅샷의 포인터를 가지므로 버전의 흐름을 파악할 수 있음. 

- Git의 주요 명령어

add	￮ 작업 내역을 지역 저장소에 저장하기 위해 스테이징 영역에 추가함.  ￮ 스테이징 영역: 작업 내역을 스테이징 영역에 저장했다가 커밋을 하는 이유는 스테이징 영역에서 작업 내용을 한 번 더 확인하여 선별적으로 지역 저장소에 반영하기 위함. 좀 더 안정적인 버전 관리 작업이 가능.  ￮ --all 옵션으로 작업 디렉터리의 모든 파일을 스테이징 영역에 추가할 수 있음.
commit	￮ 작업 내역을 지역 저장소에 저장.  ￮ -m 옵션으로 메시지 부여할 수 있음
branch	￮ 새로운 브랜치 생성 ￮ 최초로 커밋을 하면 마스터 브랜치가 생성.  ￮ 커밋할때마다 해당 브랜치는 가장 최근의 커밋 내용을 가리키게 됨.  ￮ --d 옵션으로 브랜치 삭제할 수 있음.
checkout	￮ 지정한 브랜치로 이동 ￮ 현재 작업중인 브랜치는 HEAD 포인터가 가리키는데, checkout 명령을 통해 HRAD 포인터를 지정한 브랜치로 이동시킴..
merge	지정한 브랜치의 변경 내역을 현재 HEAD 포인터가 가리키는 브랜치에 반영함으로써 두 브랜치를 병합.
init	지역 저장소를 생성.
remote add	원격 저장소에 연결.
push	로컬 저장소의 변경 내역을 원격 저장소에 반영.
fetch	원격 저장소의 변경 이력만을 지역 저장소로 가져와 반영.
clone	원격 저장소의 전체 내용을 지역 저장소로 복제.
fork	지정한 원격 저장소의 내용을 자신의 원격 저장소로 복제

 

Git(깃) 명령어 활용

계정 설정하기

깃을 통해 버전을 관리하려면 먼저 사용자 이름과 사용자 이메일을 등록하여 계정을 설정해야 함. 

git config --global user.name "sinagong" git config --global user.email "sinagong@gilbut.co.kr"

 

지역 저장소 만들기

계정을 설정한 후에는 버전 관리 내역이 저장될 지역 저장소를 만들어야 함. 지역 저장소는 실제 개발 작업을 진행하는 폴더에 생성해야 함. 

① 작업 폴더가 gitstudy라고 가정하고 gitstudy 폴더로 이동한 후 ‘init’ 명령을 실행하면 현재 폴더에 ‘.GIT’이라는 지역 저장소 폴더가 그 안에 버전 관리에 필요한 폴더 및 파일들을 포함한 상태로 생성됨. 이후 버전 관리 내역은 ‘.GIT’ 폴더에 저장됨

git init

 

변경 내역을 지역 저장소에 저장하기

작업을 수행하여 변경된 파일들은 다음의 두 단계를 거처 지역 저장소에 저장됨. 

② 작업 내역을 지역 저장소에 저장하기 전에 스테이징 영역에 추가함. 

git add --all

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

git commit -m "첫번째 커밋 작업 완료"

 

병합 기능 사용하기 

처음 커밋을 하면 마스터 브랜치가 생성되고 이 브랜치에서 실질적인 버전 관리가 수행됨. 기본적인 작업과 별도로 새로운 기능에 대한 테스트가 필요할 때는 새로운 브랜치를 만들어 테스트를 수행한 후, 테스트가 정상적으로 완료되면 새로운 기능에 대한 작업 내역을 마스터 브랜치에 병합하여 저장함. 

④ 새로운 브랜치(new_test) 생성

git branch new_test

⑤ 가장 최근의 커밋을 가리키는 포인터를 현재 작업 중인 마스터 브랜치에서 ‘new_test’ 브랜치로 이동

git checkout new_test

⑥ 현재 작업 폴더의 변경 내역을 저장. 커밋을 가리키는 포인터가 ‘new_test’ 로 옮겼기 때문에 변경 내역은 ‘new_test’ 브랜치에 저장됨. 

git add Test05.java git commit -m "두번째 커밋 완료"

⑦ ‘new_test’ 브랜치의 커밋 내역을 마스터 브랜치와 병합하기 위해 커밋을 가리키는 포인터를 마스터 브랜치로 이동. 

git checkout master

⑧ ‘new_test’ 브랜치의 커밋 내역을 마스터 브랜치와 병합한 후 ‘new_test’ 브랜치를 제거

git merge new_test git branch --d new_test

 

지역 저장소의 버전 관리 내역을 원격 저장소에 저장하기

원격 저장소는 여러 사람들이 협업을 위해 공동으로 버전을 관리하는 곳으로 자신의 버전 관리 내역을 반영하거나 다른 개발자의 변경 내용을 가져올 때 사용함. 

⑨ 지역 저장소의 변경 내역을 원격 저장소에 반영할 때 사용하는 명령어는 push 인데, 이 명령을 사용하려면 원격 저장소의 위치를 별명으로 지정해야 함. 

git remote add abc http://github.com/kyk/remotetest.git

⑩지역 저장소의 변경 내역을 원격 저장소에 저장함. 

git push abc master

 

11.8 빌드 자동화 도구

 

빌드 자동화 도구의 개념

- 빌드: 소스 코드 파일들을 컴파일 한 후 여러 개의 모듈을 묶어 실행 파일로 만드는 과정. 

- 빌드 자동화 도구: 빌드, 테스트 및 배포를 자동화하는 도구

- 애자일 환경에서는 하나의 작업이 마무리될 때 마다 모듈 단위로 나워서 개발된 코드들이 지속적으로 통합되는데, 이러한 지속적인 통합 개발 환경에서 빌드 자동화 도구는 유용하게 활용됨. 

- 빌드 자동화 도구: Ant, Make, Maven, Gradle, Jenkins 등

 

Jenkins

- Java 기반의 오픈 소스 형태로, 가장 많이 사용되는 빌드 자동화 도구. 

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

- 서블릿 컨테이너: 클라이언트의 요청을 처리해 주기 위해 서비스 측에서 실행되는 작은 프로그램인 서블릿을 실행하고 서블릿의 생명주기를 관리하는 역할. 

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

- 친숙한 Web GUI 제공으로 사용이 쉬움. 

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

 

Gradle

- Groovy(Java에 Python, Smalltalk, Ruby의 장점을 결함한 동적 객체 지향 프로그래밍 언어)를 기반으로 한 오픈 소스 형태의 자동화 도구로 안드로이드 앱 개발 환경에서 사용됨. 

- 안드로이드 뿐만 아니라 플러그인을 설정하면 Java, C/C++, Python 등의 언어도 빌드가 가능함. 

- Groovy를 사용해서 만든 DSL(특정한 영역이나 용도에 맞게 기능을 구성한 언어)을 스크립트 언어로 사용. 

- Gradle은 실행할 처리 명령들을 모아 테스크로 만든 후 테스크 단위로 실행함. 

- 이전에 사용했던 테스크를 재사용 하거나 다른 시스템의 테스크를 공유할 수 있는 빌드 캐시 기능을 지원하므로 빌드 속도를 향상시킬 수 있음.