1) 형상 관리 지침을 활용해 제품 소프트웨어의 신규 개발, 변경, 개선과 관련된 수정 내역을 관리하는 도구
2) 제품 소프트웨어의 버전과 변경, 개선 내역을 히스토리로 관리
3) 형상관리 범주 안에 버전관리가 포함
4) 버전 관리는 파일 데이터의 변화를 시간에 따라 기록했다가 특정 시점의 버전을 다시 꺼내올 수 있는 시스템
형상 관리 : 소프트웨어의 생산물을 확인하고 소프트웨어 통제, 변경 상태를 기록하고 보관하는 작업
2. 소프트웨어 버전관리 도구 유형
1) 초기 소프트웨어 버전관리 도구는 공유 폴더 방식
2) 최근 클라이언트/서버 방식과 분산 저장소 방식이 많이 사용
3) 고유 폴더 방식 RCS, SCCS
1] 개발 완료 파일은 매일 약속된 위치의 공유 폴더에 복사
2] 담당자가 공유 폴더의 파일을 매일 개인 PC로 복사하고 컴파일해 에러 확인과 정상 동작 여부 확인
4) 클라이언트/서버 방식 CVS, SVN
1] 중앙에 버전 관리 시스템이 항시 동작하는 중앙 집중형
2] 현재 작업 내용과 이전 작업내용 축적이 용이
3] 서로 다른 개발자가 같은 파일을 작업했을 때 경고 출력
5) 분산 저장소 바익 Git, Bitkeeper
1] 로컬 저장소와 원격 저장소가 구성
2] 중앙의 저장소에서 로컬에 복사한 순간 개발자 자신만의 로컬저장소에 생성
3] 개발 완료 파일 수정 이후 로컬 저장소에 커밋한 이후 다시 원격저장소에 반영하는 방식
3. 버전관리 도구별 특징
1) 개별 프로젝트에서 가장 많이 사용하는 버전관리 도구는 SVN
2) 세계적으로 오픈소스 기반의 가장 많이 사용하는 도구는 Git
3) CVS
1] concurrent versions sytem
2] 서버와 클라이언트로 구성되어 다수의 인원이 동시에 범용적인 운용체제로 접근가능하며 버전 관리를 가능하게 함
3] 클라이언트가 개발도구(이클립스 등)에 내장
4) SVN
1] subversion
2] GNU의 버전 관리 시스템으로 CVS의 장점을 이어받고 단점을 개선하여 2000년에 발표
3] 업계 표쥰
5) RCS 공유폴더방식
1] revision control system
2] CVS와 달리 소스 파일의 수정을 한 사람만으로 제한하여 다수의 사람이 파일의 수정을 동시에 할 수 없음
3] 파일 잠금 방식으로 버전 컨트롤을 수행
6) Bitkeeper
1] SVN과 비슷한 중앙통제방식의 버전컨트롤 도구(분산 저장소 방식이지만 중앙 통제 방식)
2] 대규모 프로젝트에서 빠른 속도를 내도록 개발
7) Git
1] 기존 리눅스 커널의 버전 컨트롤을 하는 Bitkeeper를 대체하기 위해 개발되었으며, 현재 리눅스가 사용중
2] 속도에 중점을 둔 분산형 버전 관리 시스템(DVCS)으로 대형 프로젝트에서 효과적
3] SVN과 다르게 COMMIT은 로컬 저장소에서 이뤄지고 PUSH라는 동작으로 원격 저장소에 반영
4] 원격저장소로부터 소스를 받을 때도 PULL 또는 FETCH로 서버에서 변경된 내역을 받아올 수 있음
8) Clear Case
1] IBM에서 제작된 버전관리 도구로서 복수 서버, 복수 클라이언트 구조
2] 서버가 부족할 때 필요한 서버를 하나씩 추가 확장 가능
GNU
1) 소프트웨어의 공개 개념을 표방하는 비제도권 단체인 자유 소프트웨어재단의 종합 프로젝트 2) 컴퓨터 프로그램은 물론 모든 관련 정보를 돈으로 주고 구입하는 것을 반대
UNIX 1) 1960년 미국 벨 연구소에서 개발한 운영체제 2) 워크스테이션/서버용이었으나 데스크탑이나 임베디드용으로도 사용 3) C언어라는 고급 프로그래밍 언어로 커널까지 작성된 운영체제 4) 다른 하드웨어로의 이식이 쉬우며 멀티태스킹 기술을 도입해 여러 사용자가 동시에 사용 가능
UNIX 특징 1) C언어로 작성해 높은 이식성과 확장성 2) 다양한 네트워킹 3) 대화식 시 분할 운영체제 4) 다중 사용자 프로그램 5) 다중 태스킹 운영체제 6) 파일 소유자, 그룹 및 그 외 사람들로부터 사용자를 구분해 파일을 보호 7) 파일 시스템 : 계층 구조 8) 사용자 위주의 시스템 명령어 제공 9) 사용자는 하나 이상의 작업을 백그라운드 실행 가능해 여러 작업 병행 처리 가능 10) 개방형 시스템 : 구조 공개, 제품의 공급업자가 많고 라이센스가 쌈 11) 단일 작업용, stand alone 시스템이 아닌 서로 공유하면서 작업
UNIX 시스템 구성 1) 커널 1] 핵심적 부분 2] 주기억장치에 적재된 후 상주하면서 실행 3] 프로세스, 기억장치, 파일, 입/출력 관리 4] 프로세스간 통신, 데이터 전송/변환 등 5] 파일 시스템의 접근 권한 처리 6] 자원 활용도 높이기 위한 스케줄링 2) 쉘 1] 명령어 해석기 2] 시스템과 사용자 간의 인터페이스 담당
리눅스 1) 안정성과 신뢰도를 높이는 운영체제 2) 인터넷에 소스가 공개된 무료 프로그램 3) 전문가가 언제든 개선가능해 전문가들을 중심으로 보급 4) GNU 프로젝트의 전폭적인 지지로 세계 서버용 OS의 27% 점유 5) 리누스 토발즈가 개발 6} 유닉스 소스 코드를 수정해 개인 PC에서도 사용할 수 잇는 공개 운영체제로 개발
4. 버전 관리 도구 사용 유의점
1) 형상관리 지침에 의거 버전에 대한 정보를 언제든지 접근할 수 있어야 함
1] 프로젝트 단위 접근 혹은 파일 단위 접근이던 간에 개발자가 원하는 때에 언제는 소프트웨어 소스에 접근이 가능해야 함
2) 개발자, 배포자 이외에 불필요한 사용자가소스 접근할 수 없어야 함
1] 중요한 파일 혹은 폴더에 대한 접근은 개발자, 배포자만 접근
2] 신입 사원이 접근해 허가 없이 수정한다면 그 동안 개발된 소스 버전이 수정될 위험이 존재
3) 동일한 프로젝트 파일에 대해서 여러 개발자가 동시 개발할 수 있어야 함
1] 여러 개발자가 동일한 파일, 폴더에 접근 시 동시에 파일 수정이 일어나더라도 개발자의 수정 내역이 통합될 수 있어야 함
4) 에러발생 시 최대한 빠른 시간 내에 복구 필요
1] 오류 발생 시 개발자가 신속하게 알고 최대한 빠르게 복구
2] 과거 버전의 소스를 가지고 신속하게 원복 가능해야 함
5. 버전관리 도구 활용방안
1) 공동 개발 및 작업 관리
1] 동일 버전의 소스 코드를 두 명 이상의 개발자가 수정할 수 있도록
2] 분산환경에서 두 명 이상의 개발자가 동일한 버전의 소스를 수정할 경우 향후 소스 누락없이 통합 가능해야
2) 버전 백업 및 복구
1] 이전 버전으로 복구 필요시 혹은 이전 버전의 기능을 재활용 시 버전 관리 도구를 활용
3) 여러 버전 솔루션 작업
1] 하나의 솔루션을 기반으로 여러 버전의 제품을 동시 개발할 경우 활용
6. 백업
1) 백업 정책
1] 버전 관리 라이브러리에 대한 백업파일은 버전 관리 라이브러리가 저장된 디스크와 분리된 디스크에 저장
2] 디스크 백업은 1일 1회
3] 시디 백업은 1주 1회
4] 실수에 의한 삭제 예방을 위해 백업은 최소 2일분 이상 보관
2) 백업 방법
1] 변경된 부분만 백업하는 중분백업이 편리해보이나 복구 시 복잡
2] 가급적 풀 백업
3] 백업 결과는 버전 관리를 담당하는 CMO가 주이적으로 점검하여 그 결과를 버전 관리 정기 보고시 함게 보고
전체 백업 : 전체 백업
중분 백업 : 변경, 증가된 데이터만 백업
차등 백업 : 풀 백업 이후 변경 사항을 모두 백업
7. 빌드 자동화 도구
1) 실행파일 생성을 자동화하기 위해서 저장소에 있는 소스를 자동으로 읽어 빌드를 진행해 실행 파일을 만드는 도구
2) 지속적인 빌드 및 배포를 통해 보다 빠른 문제의 해결 및 보다 강력하고 진보된 자동화 환경 제공
3) 지속적인 통합CI 과도 일맥상통
4) 수없이 반복해서 최종 결과물을 만들어내야 하는 소프트웨어 개발 업무에서 빌드 자동화는 필수
5) CI 서버는 버전 관리 서버로부터 개발자들이 COMMIT한 소스 코드를 체크아웃 받아 CI 서버에 저장하고 그 코드를 바탕으로 빌드를 실행 후 동작하는 코드 산출물을 생산
8. CI 효과
1) 흔히 발생하는 일반적 위험 감소
2) 에러를 초기에 발견 가능하며 자주 통합 시 에러 발생범위가 좁아져 에러 확인이 수월
3) 잘 동작하고 에러가 거의 없는 소프트웨어 유지
4) 언제 어느 때라도 배포할 수 있는 소프트웨어 생성
5) 반복적 수작업 감소
6) 프로젝트 가시성 향상
7) 개발 팀이 소프트웨어에 큰 자신감을 지니게 함
9. CI 특징
1) 소스 코드 일관성 유지 : 소스 관리 시스템이 필요
2) 자동 빌드 : CI 툴에 의해 자동으로 이뤄져야 함
3) 자동 테스트 : 소스 검증과 함께 기능/비기능 테스팅을 매번 검증하여 코드의 품질을 높임
4) 일일 체크아웃과 빌드 : 빌드 주기가 길어질수록 소스 오류 발생 확률이 높아지고 시간 낭비가 발생
10. 온라인 빌드 자동화 도구 - 젠킨스
1) 가장 많이 활용
2) 지속적인 통합 및 배포를 위한 방법을 제공
3) JAVA 기반의 오픈 소스로 지속적 통합관리를 가능하게 함
4) 아파치-토캣과 같은 서블릿 컨테이너 서버 기반으로 구동되는 시스템으로, CVS, SVN, Git 등 다양한 버전관리 도구를 지원
5) ant, maven 기반의 프로젝트와 임의의 쉘 스크립트와 윈도우 배치 명령까지 실행 가능
6) 배치 파일 : 일련의 명령어들을 하나의 파일로 작성해 자동으로 연속적으로 실행시킬 때 사용
11. 젠킨스 특징
1) 쉬운 설치
2) 친숙한 GUI : 웹기반 gui
3) 저장소 부하 감소
4) 실시간 피드백
5) 분산 빌드 : 여러 대의 컴퓨터를 통해분산 빌드나 테스트가 가능
6) 써드 party 플러그인 : 타 도구의 통합을 지원하며 데이터베이스, 개발도구, 테스트 도구와 통합 가능
12. 안드로이드 환경게 적합한 도구 - 그래들
1) c나 c++ 언어는 보통 마크파일, 자바는 ant, marben, 스칼라는 sbt를 빌드 자동화 도구로 사용하지만 오픈소스인 그래들은 여러가지 연어의 빌드 환경을 구성 가능
2) 주로 안드로이드 개발 환경에서 빌드 자동화 도구로 사용하며 다른 언어도 플러그인을 설정하면 빌드가 가능
3) 그래들 스크립트는 groovy를 사용해서 만든 DSL
4) 그래들 스크립트는 progects와 tasks라는 두 개념으로 구성
5) 모든 그래들 빌드는 하나 이상의 프로젝트로 구성되며 각 프로젝트는 하나 이상의 태스크들로 구성
6) 태스크는 어떤 클래스를 컴파일하거나 jar를 생성하거나 javadoc을 만드는 작업들을 의미
그루비 : 객체 지향 언어
DSL : 특정 도메인에 특화된 언어
JAR : 여러 개의 자바 클래스 파일과 클래스들이 이용하는 관련 리소스 및 메타데이터를 하나의 파일에 모은 것
