728x90

728x170

12. 제품 소프트웨어 패키징

(1) 소프트웨어 패키징

소프트웨어 패키징

모듈별로 생성한 실행 파일들을 묶어 배포용 설치 파일을 만드는 것
개발자가 아니라 사용자를 중심으로 진행한다.
소스 코드는 향후 관리를 고려하여 모듈화하여 패키징한다.

패키징 작업 순서

기능 식별	작성된 코드의 기능을 확인함.
↓
모듈화	확인된 기능 단위로 코드들을 분류함.
↓
빌드 진행	모듈 단위별로 실행 파일을 만듦.
↓
사용자 환경 분석	웹, 모바일, PC 등 소프트웨어가 사용될 환경이나 운영체제, CPU, RAM 등의 최소 운영 환경을 정의함.
↓
패키징 및 적용 시험	- 빌드된 실행 파일들을 정의된 환경에 맞게 배포용 파일 형식으로 패키징함. - 정의된 환경과 동일한 환경에서 패키징 결과를 테스팅한 후, 소프트웨어에 대한 불편사항을 사용자 입장에서 확인함.
↓
패키징 변경 개선	확인된 불편 사항을 반영하기 위한 패키징의 변경 및 개선을 진행함.
↓
배포	배포 수행 시 오류가 발생하면 해당 개발자에게 전달하여 수정을 요청함.

(2) 릴리즈 노트 작성

릴리즈 노트(Release Note)

소프트웨어 개발 과정에서 정리된 릴리즈 정보를 최종 사용자인 고객과 공유하기 위한 문서
릴리즈 노트를 통해 테스트 진행 결과와 소프트웨어 사양에 대한 개발팀의 정확한 준수 여부를 확인할 수 있다.
소프트웨어에 포함된 전체 기능, 서비스의 내용, 개선 사항 등을 사용자와 공유할 수 있다.

릴리즈 노트 작성 항목

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

릴리즈 노트 작성 순서

모듈 식별	모듈별 빌드 수행 후, 릴리즈 노트에 작성될 내용을 확인함.
↓
릴리즈 정보 확인	릴리즈 노트 이름, 소프트웨어 이름, 릴리즈 버전, 릴리즈 날짜, 노트 날짜, 노트 버전 등을 확인함.
↓
릴리즈 노트 개요 작성	소프트웨어 및 변경 사항 전체에 대한 간략한 내용을 작성함.
↓
영향도 체크	버그나 이슈 관련 내용 또는 해당 릴리즈 버전에서의 기능 변화가 다른 소프트웨어나 기능을 사용하는데 미칠 수 있는 영향에 대해 기술함.
↓
정식 릴리즈 노트 작성	Header(머릿말), 개요, 영향도 체크 항목을 포함하여 정식 릴리즈 노트에 작성될 기본 사항을 작성함.
↓
추가 개선 항목 식별	추가 버전 릴리즈 노트 작성이 필요한 경우, 추가 릴리즈 노트를 작성함.

(3) 디지털 저작권 권리(DRM)

저작권

소설, 시, 논문, 강연, 연술, 음악, 연극, 무용, 회화, 서예, 건축물, 사진, 영상, 지도, 도표, 컴퓨터 프로그램 저작물 등에 대하여 창작자가 가지는 배타적 독점 권리로, 타인의 침해를 받지 않을 고유한 권한
컴퓨터 프로그램들과 같이 복제하기 쉬운 저작물에 대해 불법 복제 및 배포 등을 막기 위한 기술적인 방법을 통칭해 저작권 보호 기술이라고 한다.

디지털 저작권 권리(DRM; Digital Right Management)

저작권자가 배포한 디지털 콘텐츠가 저작권자가 의도한 용도로만 사용되도록 디지털 콘텐츠의 생성, 유통, 이용까지의 전 과정에 걸쳐 사용되는 디지털 콘텐츠 관리 및 보호 기술
원본 콘텐츠가 아날로그인 경우에는 디지털로 변환한 후 패키저(Packager)로 DRM 패키징을 수행한다.
패키징을 수행하면 콘텐츠에는 암호화된 저작권자의 전자서명이 포함되고, 저작권자가 설정한 라이선스 정보가 클리어링 하우스(Clearing House)에 등록된다.

디지털 저작권 관리의 흐름 및 구성 요소

구성 요소	설명
클리어링 하우스 (Clearing House)	저작권에 대한 사용 권한, 라이선스 발급, 암호화된 키 관리, 사용량에 따른 결제 관리 등을 수행하는 곳
콘텐츠 제공자 (Contents Provider)	콘텐츠를 제공하는 저작권자
패키저(Packager)	콘텐츠를 메타 데이터와 함께 배포 가능한 형태로 묶어 암호화하는 프로그램
콘텐츠 분배자 (Contents Distributor)	암호화된 콘텐츠를 유통하는 곳이나 사람
콘텐츠 소비자 (Customer)	콘텐츠를 구매해서 사용하는 주체
DRM 컨트롤러 (DRM Controller)	배포된 콘텐츠의 이용 권한을 통제하는 프로그램
보안 컨테이너 (Security Container)	콘텐츠 원본을 안전하게 유통하기 위한 전자적 보안 장치

*메타 데이터(Meta Data) : 데이터에 대한 데이터, 즉 데이터에 대한 속성 정보 등을 설명하기 위한 데이터

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

구성 요소	설명
암호화 (Encryption)	콘텐츠 및 라이선스를 암호화하고 전자 서명을 할 수 있는 기술
키 관리 (Key Management)	콘텐츠를 암호화한 키에 대한 저장 및 분배 기술
암호화 파일 생성 (Packager)	콘텐츠를 암호화된 콘텐츠로 생성하기 위한 기술
식별 기술 (Identification)	콘텐츠에 대한 식별 체계 표현 기술
저작권 표현 (Right Expression)	라이선스의 내용 표현 기술
정책 관리 (Policy Management)	라이선스 발급 및 사용에 대한 정책 표현 및 관리 기술
크랙 방지 (Temper Resistence)	크랙에 의한 콘텐츠 사용 방지 기술
인증 (Authentication)	라이선스 발급 및 사용의 기준이 되는 사용자 인증 기술

*전자 서명(Digital Signiture) : 전자 문서의 변경 여부를 확인할 수 있도록 작성자의 고유 정보를 암호화하여 문서에 포함하는 기술

(4) 소프트웨어 설치 메뉴얼 작성

소프트웨어 설치 메뉴얼

개발 초기에서부터 적용된 기준이나 사용자가 소프트웨어를 설치하는 과정에 필요한 내용을 기록한 설명서와 안내서
설치 메뉴얼은 사용자 기준으로 작성한다.
설치 시자부터 완료할 때까지의 전 과정을 빠짐없이 순서대로 설명한다.
설치 과정에서 표시될 수 있는 오류 메시지 및 예외 상황에 관한 내용을 별도로 분류하여 설명한다.

설치 메뉴얼 작성 순서

기능 식별	소프트웨어의 개발 목적과 주요 기능을 흐름 순으로 정리하여 기록함.
↓
UI 분류	설치 메뉴얼을 작성할 순서대로 UI를 분류한 후 기록함.
↓
설치 파일 / 백업 파일 확인	폴더 위치, 설치 파일, 백업 파일 등의 개별적인 기능을 확인하여 기록함.
↓
Uninstall 절차 확인	직접 Uninstall을 수행하면서 그 순서를 단계별로 자세히 기록함.
↓
이상 Case 확인	설치 과정에서 발생할 수 있는 다양한 Case를 만들어 확인하고, 해당 Case에 대한 대처법을 자세하게 기록함.
↓
최종 메뉴얼 적용	- 설치가 완료된 화면과 메시지를 캡쳐하여 추가함. - 완성된 메뉴얼을 검토하고 고객 지원에 대한 내용을 기록함.

(5) 소프트웨어 사용자 메뉴얼 작성

소프트웨어 사용자 메뉴얼

사용자가 소프트웨어를 사용하는 과정에서 필요한 내용을 문서로 기록한 설명서와 안내서
사용자 메뉴얼은 사용자가 소프트웨어 사용에 필요한 절차, 환경 등의 제반 사항이 모두 포함되도록 작성한다.
소프트웨어 배포 후 발생될 수 있는 오류에 대한 패치나 기능에 대한 업그레이드를 위해 메뉴얼의 버전을 관리한다.
개별적으로 동작이 가능한 컴포넌트 단위로 메뉴얼을 작성한다.
사용자 메뉴얼은 컴포넌트 명세서와 컴포넌트 구현 설계서를 토대로 작성한다.

사용자 메뉴얼 작성 순서

기능 식별	소프트웨어의 개발 목적과 사용자 활용 기능을 흐름 순으로 정리하여 기록함.
↓
사용자 화면 분류	사용자 화면을 메뉴별로 분류하여 기록함.
↓
사용자 환경 파일 확인	폴더 위치, 사용자 로그 파일, 백업 파일 등의 개별적인 기능을 확인하여 기록함.
↓
초기화 절차 확인	프로그램을 사용하기 위한 초기화 절차를 확인하고, 그 단계를 순서대로 기록함.
↓
이상 Case 확인	소프트웨어 사용 과정에서 발생할 수 있는 다양한 이상 Case를 만들어 확인하고, 해당 Case에 대한 대처법을 자세하게 기록함.
↓
최종 메뉴얼 적용	- 사용과 관련된 문의 답변(FAQ)을 정리하여 기록함. - 완성된 메뉴얼을 검토하고, 고객 지원에 대한 내용을 기록함.

(6) 소프트웨어 버전 등록

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

형상 관리(SCM; Software Configuration Management) : 개발 과정에서 소프트웨어의 변경 사항을 관리하기 위해 개발된 일련의 활동
형상 관리는 소프트웨어 개발의 전 단계에 적용되는 활동이며, 유지보수 단계에서도 수행된다.
형상 관리는 소프트웨어 개발의 전체 비용을 줄이고, 개발 과정의 여러 방해 요인이 최소화되도록 보증하는 것을 목적으로 한다.

형상 관리 기능

기능	내용
형상 식별	형상 관리 대상에 이름과 관리 번호를 부여하고, 계층(Tree) 구조로 구분하여 수정 및 추적이 용이하도록 하는 작업
버전 제어	소프트웨어 업그레이드나 유지 보수 과정에서 생성된 다른 버전의 형상 항목을 관리하고, 이를 위해 특정 절차와 도구(Tool)를 결합시키는 작업
형상 통제	식별된 형상 항목에 대한 변경 요구를 검토하여 현재의 기준선(Base Line)이 잘 반영될 수 있도록 조정하는 작업
형상 감사	기준선의 무결성을 평가하기 위해 확인, 검증, 검열 과정을 통해 공식적으로 승인하는 작업
형상 기록	형상의 식별, 통제, 감사 작업의 결과를 기록·관리하고 보고서를 작성하는 작업

*기준선(Base Line, 변경 통제 시점) : 정식으로 검토되고 합의된 명세서나 제품으로, 소프트웨어 개발 시 소프트웨어 변경을 적절히 제어할 수 있도록 도와줌.

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

항목	설명
저장소 (Repository)	최신 버전의 파일들과 변경 내역에 대한 정보들이 저장되어 있는 곳
가져오기 (Import)	버전 관리가 되고 있지 않은 아무것도 없는 저장소(Repository)에 처음으로 파일을 복사함.
체크아웃 (Check-Out)	- 프로그램을 수정하기 위해 저장소(Repository)에서 파일을 받아옴. - 소스 파일과 함께 버전 관리를 위한 파일들도 받아옴.
체크인 (Check-In)	체크아웃 한 파일의 수정을 완료한 후, 저장소(Repository)의 파일을 새로운 버전으로 갱신함.
커밋 (Commit)	체크인을 수행할 때 이전에 갱신된 내용이 있는 경우에는 충돌(Conflict)을 알리고 diff 도구를 이용해 수정한 후, 갱신을 완료함.
동기화 (Update)	저장소에 있는 최신 버전으로 자신의 작업 공간을 동기화함.

*diff 도구 : 비교 대상이 되는 파일들의 내용(소스 코드)을 비교하며 서로 다른 부분을 찾아 표시해주는 도구

*버전 관리 프로그램에 따라 방법은 다를 수 있지만, diff <commit1> <commit2>와 같이 지정하면, 지정한 두 커밋(Commit) 사이의 수정 내역을 확인할 수 있다.

소프트웨어 버전 등록 과정

가져오기 (Import)	개발자가 저장소에 신규로 파일을 추가함.
↓
인출 (Check-Out)	수정 작업을 진행할 개발자가 저장소에 추가된 파일을 자신의 작업 공간으로 인출함.
↓
예치 (Commit)	인출한 파일을 수정한 후 설명을 붙여 저장소에 예치함.
↓
동기화 (Update)	커밋(Commit) 후 새로운 개발자가 자신의 작업 공간을 동기화(Update) 함. 이때 기존 개발자가 추가했던 파일이 전달됨.
↓
차이 (Diff)	새로운 개발자가 추가된 파일의 수정 기록(Change Log)을 확인하면서 이전 개발자가 처음 추가한 파일과 이후 변경된 파일의 차이를 확인함.

(7) 소프트웨어 버전 관리 도구

공유 폴더 방식

버전 관리 자료가 지역 컴퓨터의 공유 폴더에 저장되어 관리되는 방식
파일을 잘못 복사하거나 다른 위치로 복사하는 것에 대비하기 위해 파일의 변경 사항을 데이터베이스에 기록하여 관리한다.
종류 : SCCS, RCS, PVCS, QVCS 등

클라이언트/서버 방식

버전 관리 자료가 서버에 저장되어 관리 되는 방식
모든 버전 관리는 서버에서 수행된다.
서버에 문제가 생기면 서버가 복구되기 전까지 다른 개발자와의 협업 및 버전 관리 작업은 중단된다.
종류 : CVS, SVN(Subversion), CVSNT, Clear Case, CMVC, Perforce 등

분산 저장소 방식

버전 관리 자료가 하나의 원격 저장소와 분산된 개발자 PC의 지역 저장소에 함께 저장되어 관리되는 방식
지역 저장소에서 버전 관리가 가능하므로 원격 저장소에 문제가 생겨도 지역 저장소의 자료를 이용하여 작업할 수 있다.
종류 : Git, GNU arch, DCVS, Bazaar, Mercurial, TeamWare, Bitkeeper, Plastic SCM 등

Subversion(서브버전, SVN)

Suvbersion CVS를 개선한 것으로, 아파치 소프트웨어 재단에서 2000년에 발표하였다.
- CVS(Concurrent Version System) : 공동 개발을 편리하게 작업할 수 있도록 각종 소스의 버전 관리를 도와주는 시스템
클라이언트/서버 구조로, 서버(저장소, Repository)에는 최신 버전의 파일들과 변경 사항이 관리된다.
소스가 오픈되어 있어 무료로 사용할 수 있다.
CVS의 단점이었던 파일이나 디렉터리의 이름 변경, 이동 등이 가능하다.
Subversion의 주요 명령어

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

깃(Git)

리누스 토발즈(Linus Torvalds)가 2005년 리눅스 커널 개발에 사용할 관리 도구로 개발한 이후 주니오 하마노(Junio Hamano)에 의해 유지 보수되고 있다.
분산 버전 관리 시스템으로 2개의 저장소, 즉 지역 저장소와 원격 저장소가 존재한다.
버전 관리가 지역 저장소에서 진행되므로 버전 관리가 신속하게 처리되고, 원격 저장소나 네트워크에 문제가 있어도 작업이 가능하다.
Git의 주요 명령어

명령어	의미
add	- 작업 내역을 지역 저장소에 저장하기 위해 스테이징 영역(Staging Aea)에 추가함. - '--all' 옵션으로 작업 디렉터리의 모든 파일을 스테이징 영역에 추가할 수 있음.
commit	작업 내역을 지역 저장소에 저장함.
branch	- 새로운 브랜치를 생성함. - 최초로 commit을 하면 마스터(Master) 브랜치가 생성됨. - commit 할 때마다 해당 브랜치는 가장 최근의 commit한 내용을 가리키게 됨. - '-d' 옵션으로 브랜치를 삭제할 수 있음.
checkout	- 지정한 브랜치로 이동함. - 현재 작업 중인 브랜치는 HEAD 포인터가 가리키는데, checkout 명령을 통해 HEAD 포인터를 지정한 브랜치로 이동시킴.
merge	지정한 브랜치의 변경 내역을 현재 HEAD 포인터가 가리키는 브랜치에 반영함으로써 두 브랜치를 병합함.
init	지역 저장소를 생성함.
remote add	원격 저장소에 연결함.
push	로컬 저장소의 변경 내역을 원격 저장소에 반영함.
fetch	원격 저장소의 변경 이력만을 지역 저장소로 가져와 반영함.
clone	원격 저장소의 전체 내용을 지역 저장소로 복제함.
fork	지정한 원격 저장소의 내용을 자신의 원격 저장소로 복제함.

*작업 내용을 바로 commit해 지역 저장소에 저장하지 않고, 스테이징(Staging) 영역에 저장했다가 commit을 하는 이유는 스테이징 영역에서 작업 내용을 한 번 더 확인하여 선별적으로 지역 저장소에 반영하기 위함이다. 이렇게 하면 스테이징 영역을 사용하지 않을 때보다 시간은 더 소요되지만, 좀 더 안정된 버전 관리 작업이 가능하다.

(8) Git(깃) 명령어 활용

Git(깃) 명령어 활용

다음은 지역 저장소의 생성, 변경 내역 저장, 새로운 브랜치의 생성과 병합 그리고 지역 저장소의 변경 내역을 원격 저장소에 저장 하는 과정이다.

Git 설치 및 실행하기

https://git-scm.com/downloads 에 접속하여 운영체제에 맞는 Git을 설치한다.
Git을 설치한 후, 'Git bash'를 실행한다.

계정 설정하기

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

$ git config --global user.name "starrykss"
$ git config --global user.email "starrykss@tistory.com"

지역 저장소 만들기

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

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

이후 버전 관리 내역은 '.GIT' 폴더에 저장된다.

$ git init

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

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

작업 폴더(gitstudy)에 Java로 작성한 4개의 파일들이 있고, 4개 파일 모두 변동 내역이 발생한 상태라고 가정하고 이후 작업을 수행한다.

[파일 목록]
Test01.java
Test02.java
Test03.java
Test04.java

② 작업 내역을 지역 저장소에 저장하기 전에 스테이징 영역(Staging Area)에 추가한다.

$ git add -all                       /* 파일 중 변경 내용이 있는 파일만 모두 스테이징 영역에 추가한다. */

※ 1개의 파일만 스테이징 영역에 추가할 때는 '$ git add Test01.java' 와 같이 추가할 파일 이름을 입력하면 된다.

③ 작업 내역을 지역 저장소에 저장한다.

$ git commit -m "첫 번째 커밋 작업 완료"   /* 작업 내역을 지역 저장소에 저장하면서 "첫 번째 커밋 작업 완료" 라는 메시지를 부여한다. */
                                       /* 메시지는 향후 작업 시 참고 자료가 된다. */

병합(Merge) 기능 사용하기

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

④ 새로운 브랜치(new_test)를 생성한다.

$ git branch new_test

⑤ 가장 최근의 commit을 가리키는 포인터를 현재 작업중인 마스터 브랜치에서 'new_test' 브랜치로 이동한다.

$ git checkout new_test

⑥ 현재 작업 폴더의 변경 내역을 저장한다. commit을 가리키는 포인터가 'new_test' 브랜치로 옮겨졌기 때문에 변경 내역은 'new_test' 브랜치에 저장된다.

※ Test05.java를 생성하였다고 가정한다.

$ git add Test05.java                /* 'Test05.java' 파일을 스테이징 영역에 추가한다. */
$ git commit -m "두 번째 커밋 작업 완료" /* 'new_test' 브랜치에서 커밋을 수행하면서 "두 번째 커밋 작업 완료"라는 메시지를 부여한다. */

⑦ 'new_test' 브랜치의 커밋 내역을 마스터 브랜치와 병합하기 위해 commit을 가리키는 포인터를 마스터(master) 브랜치로 이동한다.

$ git checkout master

⑧ 'new_test' 브랜치의 커밋 내역을 마스터 브랜치와 병합한 후, 'new_test' 브랜치를 제거한다.

$ git merge new_test          /* 'new_test' 브랜치의 커밋 내역을 마스터 브랜치에 병합한다. */
$ git branch --d new_test     /* 'new_test' 브랜치를 제거한다. */

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

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

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

$ git remote add abc https://github.com/starrykss/remotetest.git    
                  /* 사용자가 'starrykss'이고 저장소 이름이 'remotetest'인 원격 저장소의 별명을 abc로 지정한다. */

⑩ 지역 저장소의 변경 내역을 다른 개발자와 공유하기 위해 원격 저장소에 저장한다.

$ git push abc master      /* 원격 저장소(abc)에 마스터 브랜치의 내용을 반영한다. */

(9) 빌드 자동화 도구

빌드 자동화 도구

빌드를 포함하여 테스트 및 배포를 자동화하는 도구
애자일(Agile)과 같은 지속적인 통합(Continuous Integration) 개발 환경에서 유용하게 활용된다.
빌드 자동화 도구에는 Ant, Make, Maven, Gradle, Jenkins 등이 있으며, 이중 Jenkins와 Gradle이 가장 대표적이다.

Jenkins

Java 기반의 오픈 소스 형태로, 서블릿 컨테이너에서 실행되는 서버 기반 도구
- 서블릿 컨테이너 : 클라이언트의 요청을 처리하기 위해 서버 측에서 실행되는 작은 프로그램(Server Side Applet)인 서블릿을 실행하고 서블릿의 생명 주기를 관리하는 역할을 한다.
가장 많이 사용되는 빌드 자동화 도구
SVN, Git 등 대부분의 형상 관리 도구와 연동이 가능하다.
친숙한 Web GUI 제공으로 사용이 쉽다.

Gradle

Groovy를 기반으로 한 오픈 소스 형태의 자동화 도구
- Groovy : Java에 Python, Ruby, Smalltalk 등의 장점을 결합한 동적 객체 지향 프로그래밍 언어
안드로이드 앱 개발 환경에서 사용된다.
안드로이드뿐만 아니라 플러그인을 설정하면 Java, C/C++, Python 등의 언어도 빌드할 수 있다.
Groovy를 사용해서 만든 DSL(Domain Specific Language)을 스크립트 언어로 사용한다.
- DSL(Domain Specific Language) : 웹페이지 영역에 특화되어 사용되는 HTML과 같이 특정한 도메인, 즉 영역이나 용도에 맞게 기능을 구성한 언어
- 스크립트 언어(Script Language) : HTML 문서 안에 직접 프로그래밍 언어를 삽입하여 사용하는 것으로, 기계어로 컴파일되지 않고 별도의 번역기가 소스를 분석하여 동작하게 하는 언어