[소프트웨어 개발] 3장. 제품 소프트웨어 패키징
041 소프트웨어 패키징
◈ 소프트웨어 패키징의 개요
- 모듈별로 생성한 실행 파일들을 묶어 배포용 설치 파일을 만드는 것
- 개발자가 아닌 사용자 중심으로 진행
- 소스 코드는 향후 관리를 고려해 모듈화 하여 패키징
- 다양한 환경에서 소프트웨어를 손쉽게 사용할 수 있도록 일반적인 배포 형태로 패키징
- 사용자의 편의성 및 실행 환경을 우선적으로 고려
◈ 패키징 시 고려사항
- 사용자의 시스템 환경, 즉 OS, CPU, 메모리 등에 필요한 최소 환경을 정의
- UI는 시각적인 자료와 함께 제공하고 매뉴얼과 일치시켜 패키징함
- 소프트웨어를 패키징해 배포한 이후 하드웨어와 함께 관리될 수 있도록 Managed Service 형태로 제공
- 고객의 편의성을 고려한 안정적인 배포 중요
- 다양한 사용자의 요구사항을 반영할 수 있도록 패키징의 변경 및 개선에 대한 관리를 항상 고려해야 함
※ Managed Service : 고객이 사용 중인 소프트웨어를 24시간 모니터링하면서 문제 발생 시 현장에 바로 출동
◈ 패키징 작업 순서
- 패키징 주기는 소프트웨어 개발 기법에 따라 달라지는데 각 주기가 끝날 때마다 패키징 수행
- 프로젝트 개발 과정에서 주기별로 패키징한 결과물은 테스트 서버에 배포
- 마지막 개발 과정을 거쳐 패키징한 결과물은 고객이 사용할 수 있도록 온라인 배포 또는 오프라인으로 배포
- 작업 순서
① 기능 식별 : 작성된 코드의 기능 확인
② 모듈화 : 확인된 기능 단위로 코드를 분류
③ 빌드 진행 : 모든 단위별로 실행 파일을 만듦
④ 사용자 환경 분석 : 웹, 모바일, PC 등 소프트웨어가 사용될 환경이나 운영체제, CPU, RAM 등의 최소 운영 환경 정의
⑤ 패키징 및 적용 시험 : 빌드된 실행 파일들을 정의된 환경에 맞게 배포용 파일 형식으로 패키징하여 정의된 환경과 동일한 환경에서 패키징 결과를 테스팅하고 소프트웨어에 대한 불편사항을 사용자 입장에서 확인
⑥ 패키징 변경 개선 : 확인된 불편 사항을 반영하기 위한 패키징의 변경 및 개선 진행
⑦ 배포 : 배포 수행 시 오류가 발생하면 개발자에게 전달하여 수정 요청
042 릴리즈 노트 작성
◈ 릴리즈 노트(Release Note)의 개요
- 개발 과정에서 정리된 릴리즈 정보를 소프트웨어의 최종 사용자인 고객과 공유하기 위한 문서
- 테스트 진행 방법에 대한 결과와 소프트웨어 사양에 대한 개발팀의 정확한 준수 여부를 확인할 수 있음
- 소프트웨어에 포함된 전체 기능, 서비스의 내용, 개선 사항 등을 사용자와 공유할 수 있음
- 소프트웨어의 버전 관리나 릴리즈 정보를 체계적으로 관리할 수 있음
- 소프트웨어의 초기 배포 시 또는 출시 후 개선 사항을 적용한 추가 배포 시에 제공
- 소프트웨어 출시 후 개선된 작업이 있을 때마다 관련 내용을 릴리즈 노트에 담아 제공
- 릴리즈 노트에 정리된 정보들은 철저한 테스트를 거쳐 개발팀에서 제공하는 소프트웨어 사양에 대한 최종 승인까지 얻은 후 문서화되어 제공
◈ 릴리즈 노트 초기 버전 작성 시 고려사항
- 정확하고 완전한 정보를 기반으로 개발팀에서 직접 현재 시제로 작성
- 신규 소스, 빌드 등의 이력이 정확하게 관리되어 변경 또는 개선된 항목에 대한 이력 정보들도 작성
- 표준 형식은 없지만 일반적으로 다음과 같은 항목이 포함
* Header(머릿말) : 릴리즈 노트 이름, 소프트웨어 이름, 릴리즈 버전, 릴리즈 날짜, 릴리즈 노트 날짜, 릴리즈 노트 버전 등
* 개요 : 소프트웨어 및 변경사항 전체에 대한 간략한 내용
* 목적 : 해당 릴리즈 버전에서의 새로운 기능이나 수정된 기능의 목록과 릴리즈 노트의 목적에 대한 간략한 개요
* 문제 요약 : 수정된 버그에 대한 간략한 설명 또는 릴리즈 추가 항목에 대한 요약
* 재현 항목 : 버그 발견에 대한 과정 설명
* 수정/개선 내용 : 버그를 수정/개선한 내용을 간단히 설명
* 사용자 영향도 : 사용자가 다른 기능들을 사용하는 데 있어 해당 릴리즈 버전에서의 기능 변화가 미칠 수 있는 영향에 대한 설명
* SW 지원 영향도 : 해당 릴리즈 버전에서의 기능 변화가 다른 응용 프로그램들을 지원하는 프로세스에 미칠 수 있는 영향에 대한 설명
* 노트 : SW/HW 설치 항목, 업그레이드, 소프트웨어 문서화에 대한 참고 항목
* 면책 조항 : 회사 및 소프트웨어 관련하여 참조할 사항
* 연락처 : 사용자 지원 및 문의 응대를 위한 연락처 정보
◈ 추가 버전 작성 시 고려사항
- 소프트웨어의 테스트 과정에서 베타 버전이 출시되거나 긴급한 버그 수정, 업그레이드와 같은 자체 기능 향상, 사용자 요청 등의 특수한 상황이 발생하는 경우 릴리즈 노트를 추가로 작성
- 중대한 오류가 발생해 긴급 수정하는 경우에는 릴리즈 버전을 출시하고 버그 번호를 포함한 모든 수정된 내용을 담아 릴리즈 노트 작성
- 소프트웨어에 대한 기능 업그레이드를 완료한 경우에 릴리즈 버전을 출시하고 릴리즈 노트 작성
- 사용자로부터 접수된 요구사항에 의해 추가나 수정된 경우 자체 기능 향상과는 다른 별도의 릴리즈 버전을 출시하고 릴리즈 노트 작성
◈ 릴리즈 노트 작성 순서
① 모듈 식별 : 모듈별 빌드 수행 후 릴리즈 노트에 작성될 내용들 확인
② 릴리즈 정보 확인 : 릴리즈 노트 이름, 소프트웨어 이름, 릴리즈 버전, 릴리즈 날짜, 노트 날짜, 노트 버전 등을 확인
③ 릴리즈 노트 개요 작성 : 소프트웨어 및 변경사항 전체에 대한 간략한 내용 작성
④ 영향도 체크 : 버그나 이슈 관련 내용 또는 해당 릴리즈 버전에서의 기능 변화가 다른 소프트웨어나 기능을 사용하는데 미칠 수 있는 영향에 대해 기술
⑤ 정식 릴리즈 노트 작성 : 머릿말, 개요, 영향도 체크 항목을 포함하여 정식 릴리즈 노트에 작성될 기본 사항들을 작성
⑥ 추가 개선 항목 식별 : 추가 버전 릴리즈 노트 작성이 필요한 경우 추가 릴리즈 노트 작성
043 디지털 저작권 관리(DRM)
◈ 저작권의 개요
- 창작자가 가지는 배타적 독점적 권리로 타인의 침해를 받지 않을 고유한 권한
- 복제하기 쉬운 저작물에 대해 불법 복제 및 배포 등을 막기 위한 기술적인 방법을 통칭해 저작권 보호 기술이라 함
◈ 디지털 저작권 권리(DRM; Digital Right Management)
- 원본 콘텐츠가 아날로그인 경우에는 디지털로 변환한 후 패키저에 의해 DRM 패키징 수행
- 콘텐츠의 크기가 음원이나 문서와 같이 크기가 작은 경우 사용자가 콘텐츠를 요청하는 시점에서 실시간으로 패키징을 수행하고 크기가 큰 경우 미리 패키징을 수행 후 배포
- 패키징 수행 시 콘텐츠에는 암호화된 저작권자의 전자서명이 포함되고 저작권자가 설정한 라이선스 정보가 클리어링 하우스에 등록됨
- 사용자가 콘텐츠를 사용하기 위해서는 클리어링 하우스에 등록된 라이선스 정보를 통해 사용자 인증과 콘텐츠 사용 권한 소유 여부를 확인받아야 함
- 종량제 방식을 적용한 소프트웨어의 경우 클리어링 하우스를 통해 서비스의 실제 사용량을 측정하여 이용한 만큼의 요금 부과
※ 클리어링 하우스 : 디지털 저작권 라이선스의 중개 및 발급을 수행하고 디지털 저작물의 이용 내역을 근거로 저작권료의 정산 및 분배 수행
※ 종량제 방식 : 실제 사용한 양에 따라 요금을 차등 적용
◈ 디지털 저작권 관리의 흐름도
- 클리어링 하우스(Clearing House) : 저작권에 대한 사용 권한, 라이선스 발급, 사용량에 따른 결제 관리 등을 수행하는 곳
- 콘텐츠 제공자(Contents Provider) : 콘텐츠를 제공하는 저작권자
- 패키저(Packager) : 콘텐츠를 메타 데이터와 함께 배포 가능한 형태로 묶어 암호화하는 프로그램
- 메타 데이터(Meta Data) : 데이터에 대한 데이터, 즉 데이터에 대한 속성 정보 등을 설명하기 위한 데이터
- 콘텐츠 분배자(Contents Distributor) : 암호화된 콘텐츠를 유통하는 곳이나 사람
- 콘텐츠 소비자(Customer) : 콘텐츠를 구매해서 사용하는 주체
- DRM 컨트롤러(DRM Controller) : 배포된 콘텐츠의 이용 권한을 통제하는 프로그램
- 보안 컨테이너(Security Container) : 콘텐츠 원본을 안전하게 유통하기 위한 전자적 보안 장치
◈ 디지털 저작권 관리의 기술 요소
- 암호화(Encryption) : 콘텐츠 및 라이선스를 암호화하고 전자 서명을 할 수 있는 기술
- 키 관리(Key Management) : 콘텐츠를 암호화한 키에 대한 저장 및 분배 기술
- 암호화 파일 생성(Packager) : 콘텐츠를 암호화된 콘텐츠로 생성하기 위한 기술
- 식별 기술(Identification) : 콘텐츠에 대한 식별 체계 표현 기술
- 저작권 표현(Right Expression) : 라이선스의 내용 표현 기술
- 정책 관리(Policy Management) : 라이선스 발급 및 사용에 대한 정책 표현 및 관리 기술
- 크랙 방지(Tamper Resistance) : 크랙에 의한 콘텐츠 사용 방지 기술
- 인증(Authentication) : 라이선스 발급 및 사용의 기준이 되는 사용자 인증 기술
044 소프트웨어 설치 매뉴얼 작성
◈ 소프트웨어 설치 매뉴얼의 개요
- 개발 초기에서부터 적용된 기준이나 사용자가 소프트웨어를 설치하는 과정에 필요한 내용을 기록한 설명서와 안내서
- 설치 매뉴얼은 사용자 기준으로 작성
- 설치 시작부터 완료될 때까지의 전 과정을 빠짐없이 순서대로 설명
- 설치 과정에서 표시될 수 있는 오류 메시지 및 예외 상황에 관한 내용을 별도로 분류하여 설명
- 소프트웨어 설치 매뉴얼에는 목차 및 개요, 서문, 기본 사항 등이 기본적으로 포함
- 소프트웨어 설치 매뉴얼의 목차에는 전체 설치 과정을 순서대로 요약한 후 관련 내용의 시작 페이지를 함께 기술
- 소프트웨어 설치 매뉴얼의 개요에는 설치 매뉴얼의 주요 특징, 구성과 설치 방법, 순서 등의 내용 기술
◈ 서문
- 서문에는 문서 이력, 설치 매뉴얼의 주석, 설치 도구의 구성, 설치 환경 체크 항목을 기술
- 문서 이력
* 버전, 작성자, 검토자, 일시, 검수인, 변경 내용
- 설치 매뉴얼의 주석
* 주의 사항과 참고 사항을 기술
* 주의 사항 : 설치할 때 사용자가 반드시 알고 있어야 하는 중요한 내용 기술
* 참고 사항 : 설치에 영향을 미칠 수 있는 사용자의 환경이나 상황에 대한 내용 기술
- 설치 도구의 구성
* exe, dll, ini, chm 등의 설치 관련 파일에 대해 설명
* 폴더 및 설치 프로그램 실행 파일에 대해 설명
* 설치 과정 및 결과가 기록되는 log 폴더에 대해 설명
- 설치 환경 체크 항목
* 사용자 환경 : CPU, Memory, OS 등
* 응용 프로그램 : 설치 전 다른 응용 프로그램 종료
* 업그레이드 버전 : 업그레이드 이전 버전에 대한 존재 유무 확인
* 백업 폴더 확인 : 데이터 저장 폴더를 확인하여 설치 시 폴더를 동기화
◈ 기본 사항
- 소프트웨어와 관련하여 기본적으로 설명되어야 할 항목
- 소프트웨어 개요
* 소프트웨어의 주요 기능 및 UI 설명
* UI 및 화면 상의 버튼, 프레임 등을 그림으로 설명
- 설치 관련 파일
* 소프트웨어 설치에 필요한 파일 설명
* exe, ini, log 등의 파일 설명
- 설치 아이콘
* 설치 아이콘 설명
- 프로그램 삭제
* 설치된 소프트웨어의 삭제 방법 설명
- 관련 추가 정보
* 소프트웨어 이외의 관련 설치 프로그램 정보
* 소프트웨어 제작사 등의 추가 정보 기술
◈ 설치 매뉴얼 작성 방법
- 설치 매뉴얼은 사용자가 설치 과정을 이해하기 쉽도록 설치 화면을 누락 없이 캡처하고 순서대로 상세히 설명
- 설치 화면 및 UI, 설치 이상 메시지, 설치 완료 및 결과, FAQ, 설치 시 점검 사항, Network 환경 및 보안, 고객 지원 방법, 준수 정보 및 제한 보증 등에 대한 내용 기술
◈ 설치 매뉴얼 작성 순서
① 기능 식별 : 소프트웨어의 개발 목적과 주요 기능을 흐름 순으로 정리하여 기록
② UI 분류 : 설치 매뉴얼을 작성할 순서대로 UI를 분류한 후 기록
③ 설치 파일 / 백업 파일 확인 : 폴더 위치, 설치 파일, 백업 파일 등의 개별적인 기능을 확인하여 기록
④ Uninstall 절차 확인 : 직접 Uninstall을 수행하면서 그 순서를 단계별로 자세히 기록
⑤ 이상 Case 확인 : 설치 과정에서 발생할 수 있는 다양한 Case를 만들어 확인하고 해당 Case에 대한 대처법 자세하게 기록
⑥ 최종 매뉴얼 적용 : 설치가 완료된 화면과 메시지를 캡처하여 추가. 완성된 매뉴얼을 검토하고 고객 지원에 대한 내용 기록
045 소프트웨어 사용자 매뉴얼 작성
◈ 소프트웨어 사용자 매뉴얼의 개요
- 소프트웨어를 사용하는 과정에서 필요한 내용을 문서로 기록한 설명서와 안내서
- 소프트웨어 사용에 필요한 절차, 환경 등의 제반 사항이 모두 포함
- 소프트웨어 배포 후 발생될 수 있는 오류에 대한 패치나 기능에 대한 업그레이드를 위해 매뉴얼의 버전 관리
- 개별적으로 동작이 가능한 컴포넌트 단위로 매뉴얼 작성
- 사용자 매뉴얼은 컴포넌트 명세서와 컴포넌트 구현 설계서를 토대로 작성
- 사용자 매뉴얼에는 목차 및 개요, 서문, 기본 사항 등이 기본적으로 포함
- 사용자 매뉴얼의 목차에는 매뉴얼 전체 내용을 순서대로 요약한 후 관련 내용의 시작 페이지를 함께 기술
- 개요에는 소프트웨어의 주요 특징, 매뉴얼의 구성과 실행 방법, 사용법, 항목별 점검 기준, 항목별 설정 방법 등에 대한 내용 기술
◈ 서문
- 서문에는 문서 이력, 사용자 매뉴얼의 주석, 기록 보관을 위해 필요한 내용을 기술함
- 문서 이력
* 버전, 작성자, 작성일, 검토자, 일시, 검수인, 변경 내용
- 사용자 매뉴얼의 주석
* 주의 사항과 참고 사항 기술
- 기록 보관 내용
* 소프트웨어를 사용하면서 필요한 기술 지원이나 추가 정보를 얻기 위한 소프트웨어 등록 정보를 기술
* 소프트웨어 등록 시 필요한 정보는 소프트웨어 명칭, 모델명, 문서 번호, 제품 번호, 구입 날짜 등
◈ 기본 사항
- 소프트웨어와 관련하여 기본적으로 설명되어야 할 항목
- 소프트웨어 개요
* 소프트웨어의 주요 기능 및 UI 설명
* UI 및 화면 상의 버튼, 프레임 등을 그림으로 설명
- 소프트웨어 사용 환경
* 소프트웨어 사용을 위한 최소 환경 설명
* CPU, Memory, OS 설명
* 최초 구동에 대한 설명
* 소프트웨어 사용 시 발생할 수 있는 프로그램 충돌이나 개인정보, 보안 등에 관한 주의사항을 설명
- 소프트웨어 관리
* 소프트웨어의 사용 종료 및 관리 등에 관한 내용 설명
- 모델, 버전별 특징
* 모델 및 버전별로 UI 및 기능의 차이점을 간략하게 요약
- 기능, 인터페이스의 특징
* 제품의 기능과 인터페이스 특징을 간략하게 요약
- 소프트웨어 구동 환경
* 개발에 사용한 언어 및 호환 가능한 운영체제에 대해 설명
* 설치 후 구동하기까지의 과정을 운영체제별로 설명
◈ 사용자 매뉴얼 작성 방법
- 사용자 매뉴얼은 사용자가 사용 방법을 이해하기 쉽도록 상황별로 누락 없이 캡처하여 순서대로 상세히 설명
- 사용자 화면 및 UI, 주요 기능 분류, 응용 프로그램 및 설정, 장치 연동, Network 환경, Profile 안내, 고객 지원 방법, 준수 정보 및 제한 보증
◈ 사용자 매뉴얼 작성 순서
① 기능 식별 : 소프트웨어의 개발 목적과 사용자 활용 기능을 흐름 순으로 정리하여 기록
② 사용자 화면 분류 : 사용자 화면을 메뉴별로 분류하여 기록
③ 사용자 환경 파일 확인 : 폴더 위치, 사용자 로그 파일, 백업 파일 등의 개별적인 기능을 확인하여 기록
④ 초기화 절차 확인 : 프로그램을 사용하기 위한 초기화 절차를 확인하고 그 단계를 순서대로 기록
⑤ 이상 Case 확인 : 소프트웨어 사용 과정에서 발생할 수 있는 다양한 이상 Case를 만들어 확인. 해당 Case에 대한 대처법을 자세하게 기록
⑥ 최종 매뉴얼 작성 : 사용과 관련된 문의 답변(FAQ)을 정리하여 기록. 완성된 매뉴얼을 검토하고 고객 지원에 대한 내용을 기록
046 소프트웨어 버전 등록
◈ 소프트웨어 패키징의 형상 관리
- 형상 관리(SCM : Software Configuration Management)는 소프트웨어의 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동
- 소프트웨어 변경의 원인을 알아내고 제어하며 적절히 변경되고 있는지 확인하여 해당 담당자에게 통보
- 형상 관리는 소프트웨어 개발의 전 단계에 적용되는 활동이며 유지보수 단계에서도 수행됨
- 형상 관리는 개발의 전체 비용을 줄이고 개발 과정의 여러 방해 요인이 최소화되도록 보증하는 것을 목적으로 함
◈ 형상 관리의 중요성
- 지속적인 소프트웨어의 변경 사항을 체계적으로 추적 및 통제
- 제품 소프트웨어에 대한 무절제한 변경 방지
- 제품 소프트웨어에서 발견된 버그나 수정 사항 추적 가능
- 소프트웨어는 형태가 없어 가시성이 결핍되어 진행 정도를 확인하기 위한 기준으로 사용
◈ 형상 관리 기능
- 형상 식별 : 형상 관리 대상에 이름과 관리 번호를 부여하고 계층 구조로 구분해 수정 및 추적이 용이하도록 하는 작업
- 버전 제어 : 다른 버전의 형상 항목을 관리하고 이를 위해 특정 절차와 도구를 결합시키는 작업
- 형상 통제(변경 관리) : 식별된 형상 항목에 대한 변경 요구를 검토하여 현재의 기준선이 반영될 수 있도록 조정
- 형상 감사 : 기준선의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업
- 형상 기록(상태 보고) : 형상의 식별, 통제, 감사 작업의 결과를 기록, 관리하고 보고서를 작성
◈ 소프트웨어의 버전 등록 관련 주요 용어
- 저장소(Repository) : 최신 버전의 파일들과 변경 내역에 대한 정보들이 저장되어 있는 곳
- 가져오기(import) : 버전 관리가 되고 있지 않은 아무것도 없는 저장소에 처음으로 파일을 복사
- 체크아웃(Check-Out) : 프로그램을 수정하기 위해 저장소에서 파일을 받아오고 소스 파일과 함께 버전 관리를 위한 파일들도 받아옴
- 체크인(Check-In) : 체크아웃 한 파일의 수정을 완료한 후 저장소의 파일을 새로운 버전으로 갱신
- 커밋(Commit) : 체크인을 수행할 때 이전에 갱신된 내용이 있는 경우에 충돌을 알리고 diff 도구를 이용해 수정한 후 갱신을 완료
- 동기화(Update) : 저장소에 있는 최신 버전으로 자신의 작업 공간을 동기화함
◈ 소프트웨어의 버전 등록 과정
① 가져오기(Import) : 개발자가 저장소에 신규로 파일을 추가
② 인출(Check-Out) : 수정 작업을 진행할 개발자가 저장소에 추가된 파일을 자신의 작업 공간으로 인출
③ 예치(Commit) : 인출할 파일을 수정한 후 설명을 붙여 저장소에 예치
④ 동기화(Update) : 커밋 후 새로운 개발자가 자신의 작업 공간을 동기화함. 이때 기존 개발자가 추가했던 파일이 전달됨
⑤ 차이(Diff) : 새로운 개발자가 추가된 파일의 수정 기록을 확인하면서 이전 개발자가 처음 추가한 파일과 이후 변경된 파일의 차이를 확인
047 소프트웨어 버전 관리 도구
◈ 공유 폴더 방식
- 버전 관리 자료가 로컬 컴퓨터의 공유 폴더에 저장되어 관리되는 방식
- 개발자들은 개발이 완료된 파일을 약속된 공유 폴더에 매일 복사
- 담당자는 공유 폴더의 파일을 자기 PC로 복사한 후 이상 유무를 확인
- 이상 유무 확인 중 파일의 오류가 확인되면, 해당 파일을 등록한 개발자에게 수정 의뢰
- 파일에 이상이 없다면 다음날 각 개발자들이 동작 여부를 다시 확인
- 파일을 잘못 복사하거나 다른 위치로 복사하는 것에 대비하기 위해 파일의 변경사항을 데이터베이스에 기록하여 관리
- ex) SCCS, RCS, PVCS, QVCS
◈ 클라이언트/서버 방식
- 버전 관리 자료가 서버에 저장되어 관리되는 방식
- 서버의 자료를 개발자별로 자신의 PC로 복사해 작업한 후 변경된 내용을 서버에 반영
- 모든 버전 관리는 서버에서 수행
- 하나의 파일을 서로 다른 개발자가 작업할 경우 경고 메시지 출력
- 서버에 문제 발생 시 협업 및 버전 관리 작업 중단됨
- ex) CVS, SVN(Suvbersion), CVSNT, Clear Case, CMVC, Perforce
◈ 분산 저장소 방식
- 버전 관리 자료가 하나의 원격 저장소와 분산된 개발자 PC의 로컬 저장소에 함께 저장되어 관리되는 방식
- 개발자별로 원격 저장소의 자료를 자신의 로컬 저장소로 복사해 작업한 후 변경된 내용을 로컬 저장소에서 우선 반영한 다음 이를 원격 저장소에 반영
- 원격 저장소에 문제가 생겨도 로컬 저장소의 자료를 이용해 작업할 수 있음
- ex) Git, GNU arch, DCVS, Bazaar, TeamWare, Bitkeeper 등
◈ Subversion(서브버전, SVN)
- CVS를 개선한 것으로 아파치 소프트웨어 재단에서 2000년에 발표
- 클라이언트/서버 구조로 서버에는 최신 버전의 파일들과 변경 내역 관리
- 서버의 자료를 클라이언트로 복사해와 작업 후 변경 내용을 서버에 반영
- 모든 개발 작업은 trunk 디렉터리에서 수행
- 추가 작업은 branches 디렉터리 안에 별도의 디렉터리를 만들어 작업을 완료 후 trunk 디렉터리와 병합
- 커밋할 때마다 리비전(Revision)이 1씩 증가
- 클라이언트는 대부분의 운영체제에서 사용되지만 서버는 주로 유닉스 사용
- 소스가 오픈되어 있어 무료로 사용
- CVS의 단점이었던 파일이나 디렉터리의 이름 변경, 이동 등이 가능
- Subversion의 주요 명령어
* add : 새로운 파일이나 디렉터리를 버전 관리 대상으로 등록
* commit : 버전 관리 대상으로 등록된 클라이언트의 소스 파일을 서버의 소스 파일에 적용
* update : 서버의 최신 commit 이력을 클라이언트의 소스 파일에 적용
* checkout : 버전 관리 정보와 소스 파일을 서버에서 클라이언트로 받아옴
* lock/unlock : 서버의 소스 파일이나 디렉터리를 잠그거나 해제
* Import : 아무것도 없는 서버의 저장소에 맨 처음 소스 파일을 저장
* export : 버전 관리에 대한 정보를 제외한 순수한 소스 파일만을 서버에서 받아 옴
* info : 지정된 파일에 대한 정보 표시
* diff : 지정된 파일이나 경로에 대해 전 리비전과의 차이 표시
* merge : 다른 디렉터리에서 작업된 버전 관리 내역을 기본 개발 작업과 병합
※ CVS(Concurrent Version System) : 공동 개발을 편리하게 작업 할 수 있도록 버전 관리를 도와주는 시스템
※ trunk : 개발 과정에서 가장 중심이 되는 디렉터리로 trunk 디렉터리 안에 소스 파일이 추가 작업을 위한 서브 디렉터리인 branches 디렉터리가 있음
※ branches : 새로운 기능의 테스트와 같이 추가적인 작업을 사용하기 위한 디렉터리
※ 리비전(Revision) : 커밋의 버전으로 처음 저장소를 만들면 리비전은 0이고 이후 커밋이 수행될 때마다 리비전이 1씩 증가
◈ Git(깃)
- 리누즈 토발즈가 2005년 리눅스 커널 개발에 사용할 관리 도구로 개발한 이후 주니오 하마노가 유지 보수
- Git은 분산 버전 관리 시스템으로 2개의 저장소인 지역 저장소와 원격 저장소가 존재
- 지역 저장소는 개발자들이 실제 개발을 진행하는 장소로 버전 관리를 수행
- 원격 저장소는 여러 사람들이 협업을 위해 버전을 공동 관리하고 자신의 버전 관리 내역을 반영하거나 다른 개발자의 변경 내용을 가져올 때 사용
- 버전 관리가 지역 저장소에서 진행되므로 버전 관리가 신속하게 처리되고 원격 저장소나 네트워크에 문제가 발생해도 작업 가능
- 브랜치를 이용하면 기본 버전 관리 틀에 영향을 주지 않으면서 다양한 형태의 기능 테스팅 가능
- 파일의 변화를 스냅샷으로 저장하고 스냅샷은 이전 스냅샷의 포인터를 가지므로 버전의 흐름 파악 가능
- Git의 주요 명령어
* add : 작업 내역을 지역 저장소에 저장하기 전 스테이징 영역에 추가
* commit : 작업 내역을 지역 저장소에 저장
* branch : 새로운 브랜치 생성
* checkout : 지정한 브랜치로 이동
* merge : 브랜치 병합
* init : 지역 저장소 생성
* remote add : 원격 저장소에 연결
* push : 로컬 저장소의 변경 내역을 원격 저장소에 반영
* fetch : 원격 저장소의 변경 이력만을 지역 저장소로 가져옴
* clone : 원격 저장소의 전체 내용을 지역 저장소로 복제
* fork : 지정한 원격 저장소의 내용을 자신의 원격 저장소로 복제
※ 브랜치(Branch) : 새로운 기능을 추가하는 작업은 새로운 브랜치를 만들어 작업을 수행하고 작업이 마무리되면 작업 내용을 마스터 브랜치에 병합
※ 스냅샷(Snapshot) : 영문자와 숫자가 혼합된 40자리 문자열로 표시
048 빌드 자동화 도구
◈ 빌드 자동화 도구 개념
- 빌드란 소스 코드 파일들을 컴파일한 후 여러 개의 모듈을 묶어 실행 파일로 만드는 과정
- 빌드, 테스트 및 배포를 자동화하는 도구
- 지속적인 통합이 이루어지는 애자일 같은 개발 환경에서 유용
- 빌드 자동화 도구 : Ant, Make, Maven, Gradle, Jenkins
- 대표 : Gradle, Jenkins
◈ Jenkins
- JAVA 기반의 오픈 소스 형태로 가장 많이 사용되는 빌드 자동화 도구
- 서블릿 컨테이너에서 실행되는 서버 기반 도구
- SVN, Git 등 대부분의 형상 관리 도구와 연동 가능
- 친숙한 Web GUI 제공으로 사용이 쉬움
- 여러 대의 컴퓨터를 이용한 분산 빌드나 테스트 가능
※ 서블릿 컨테이너 : 클라이언트의 요청을 처리해 주기 위해 서버 측에서 실행되는 작은 프로그램인 서블릿을 실행하고 서블릿의 생명주기를 관리하는 역할
◈ Gradle
- Groovy 기반의 오픈 소스 형태로 안드로이드 앱 개발 환경에서 사용
- 별도의 플러그인 설정 시 JAVA, C/C++, Python 등의 언어도 빌드 가능
- Groovy를 사용해서 만든 DSL을 스크립트 언어로 사용
- Gradle은 실행할 처리 명령들을 모아 태스크로 만든 후 태스크 단위로 실행
- 테스트 재사용이나 다른 시스템의 태스크를 공유할 수 있는 빌드 캐시 기능을 지원하므로 빌드 속도 빠름
※ DSL(Domain Specific Language) : 웹페이지 영역에 특화되어 사용되는 HTML과 같이 특정한 도메인으로 영역이나 용도에 맞게 기능을 구성한 언어
※ 스크립트 언어(Script Language) : HTML 문서 안에 직접 프로그래밍 언어를 삽입하여 사용하며 기계어로 컴파일이 되지 않고 별도의 번역기가 소스를 분석하여 동작하게 하는 언어