슬라이드 1

Transcription

1 Agile 기반 ALM 프로세스따라하기 오픈소스컨설팅정명훈이사

2 Agile 개발방법론

3 기존폭포수개발방법론과애자일방법론의특징 폭포수 (Waterfall) 방법론 전통적인대규모프로젝트에적합 프로젝트기간을 " 분석 설계 구현 테스트 " 의주요단계로구분하여각시기별로해당작업수행 이프로세스의전제조건은다음프로세스로넘어가기위해이전단계가완벽하게끝나야한다는것이다 실제로는고객과개발자모두프로젝트진행과정에끊임없이학습하고, 학습의결과로 " 요구사항변화 " 애자일 (Agile) 방법론 제품 / 솔루션개발프로젝트에적합 프로젝트중에요구사항의변경이나개발자의능력진화 ( 발전 ) 를전제로한변화를수용하는실용주의방법론 개발과정을짧은조각 (2~4 주 ) 으로나누어반복적으로개발 반복적 (Iterative) 개발방법론 협업과커뮤니케이션에비중 스프린트계획회의, 일일스크럼회의및리뷰 ( 데모 ) 회의 자동화도구 협업, 개발, 빌드, 테스트과정을통합된환경 (Application Lifecycle Management) 에서자동화 폭포수방법론 애자일방법론 3

4 스크럼애자일 (Scrum Agile) 개발방법론 1990 년대초반부터복잡한제품개발을관리하기위해사용된반복적이며점진적인개발방법론 스크럼은몇개의반복 (Iteration) 으로구성 ( 스프린트, Sprint 라고함 ) 각스프린트에는 1~4 주정도의기간이소요 ( 보통 2 주정도가적당 ) 역할자 (roles) 산출물 (Artifacts) 행위 (Activity) 4

5 ALM 프로세스

6 ALM 환경사례 Project Manager 소스리뷰 Reviewer QA/Test 전체프로젝트관리 소스변경추적 소스형상관리 개발서버 프로젝트포탈 ( 이슈및일정관리 ) 실행 / 테스트코드 요구사항산출물 빌드및배포 문서관리 고객 이슈에따른소스수정 변경내용저장 라이브러리관리 코드정적분석 코드품질관리 개발툴 개발자 코드동적분석 6

7 ALM(Application Lifecycle Management) 기반품질관리방안 일관된프로젝트산출물 ( 요구사항, 문서, 코드, 협업내용등 ) 관리 소스코드품질보장 개발과정, 코드품질, 이슈및위험도에대한가시성제공 7

8 ALM 시스템소개 개발자 View 주요프로젝트공지사항 각종프로젝트활동로그 주요이슈들의진행상황 각개발자에게할당된이슈 8

9 ALM(Application Lifecycle Management) 기반품질관리방안 개발툴 ( 이클립스 ) 에서소스수정후 Commit 변경된소스에대한자동빌드 소스수정및 Commit 이력 소스증가추이 9

10 ALM(Application Lifecycle Management) 기반품질관리방안 개발자별이슈진행상황 프로젝트주요릴리즈일정 주요이슈들의진행상황 이슈생성 / 해결상황그래프 10

11 ALM 시스템소개 소스에대한품질관리 소스에대한정적분석, 동적분석, 복잡도등에대한자동관리및시각화 중복률 소스정적분석결과 테스트커버리지 단위테스트성공률 복잡도 ( 중복의존성등 ) 관리 11

12 ALM 시스템소개 소스리뷰 소스에대한상호리뷰와커뮤니케이션을통해소스의품질관리및리스크제거 소스에대한리뷰및커멘트 수정권고사항을바로이슈로등록 12

13 Agile/ALM 프로젝트에서산출물전략 스크럼애자일기법과 ALM 환경기반일관성있는산출물 ALM 시스템 (Wiki, Jira, SVN, Jenkins 등 ) 을통해이루어지는개발작업과커뮤니케이션을산출물화함으로써 " 요구사항 산출물 " 화하는과정의일관성유지 프로젝트의원활한커뮤니케이션도구로활용 각컴포넌트별일정및체크포인트에따른산출물작성을통해커뮤니케이션의수단으로활용 리스크제거및프로젝트가시성확보를위한수단 지속적인보완 애자일기법의특징처럼산출물을통해프로젝트의리스크를발견하고, 반대로해결된문제를산출물에반영함으로써지속적인보완 13

14 산출물관리목표예시 항목요구사항목표관리도구 일정관리 프로젝트내주요스케줄관리및공유 프로젝트내주요스케줄공유 Team Calendar 문서관리 요구사항, 설계, 이슈등에대한상세기술내용 상세내용을효과적으로기술하고멤버간공유 Wiki 이슈관리 요구사항, 작업내용, 문제점등에대한트래킹 이슈에대한체계적인트래킹과리스크확인 Jira/Redmine 소스관리소스형상관리소스와소스에대한리뷰 SVN 빌드관리 개발중인소스에대한자동빌드 일일빌드를통해소스완성도관리 Jenkins 코드커버리지 40% SonarQube 소스품질 주석률 30% SonarQube 중복률 0% SonarQube 제품릴리즈관리 릴리즈별산출물관리 각릴리즈별산출물 ( 코드, 패키지, 노트등 ) 버전관리 JIRA, SVN, FishEye, Jenkins 14

15 소스형상관리 Subversion vs Git

16 소스형상관리시스템용어 버전관리시스템에서일반적으로사용되는용어는아래와같음 용어 설명 중앙저장소 (Repository) 작업디렉토리 (Working Copy) 커밋 (Commit) 갱신 (Update) 리비전 (Revision) 롤백 (Roll Back) 원본소스를저장하고있는저장소 원본저장소로부터체크아웃을통해내려받은내로컬 PC 에있는작업사본디렉토리 작업디렉터리에서변경, 추가및삭제된파일을원본저장소인서버에적용하는것 체크아웃을받은작업디렉터리를원본저장소의가장최신커밋된버전까지업데이트하는명령어 소스파일을수정하여커밋하게되면일정한규칙에의해숫자가증가하며, 저장소에저장된각각의파일버전 작업디렉터리에저장되어있는사본을특정리비전또는특정시간으로복원할수있도록하는명령어 16

17 일반적인버전관리프로세스 중앙리포지토리내에서로컬복사후변경한사본을커밋하는방식으로진행 client 체크아웃 ( 최초 ) ( 작업및테스트 ) 상태체크업데이트 ( 충돌해결 ) 커밋 ( 작업및테스트 ) server 17 현재리비전전송 ( n ) 리비전 n 이후의변경사항이있는가? 리포지토리내의변경사항을로컬에반영 변경사항저장및로그기록

18 Subversion, Git 간략비교 구분 Subversion Git 시초 리파지토리모델 CVS 문제점 1) 을극복하기위해 CVS 개발자들에의해 2000 년에새롭게시작 클라이언트 - 서버모델 2005 년 4 월 BitKeeper 논쟁 2) 이후리눅스를만든리누스토발즈에의해시작 분산형 (Distributed) 동시성모델 Merge, Lock 병합 (Merge) 라이선스 Apache GNU GPL 라이선스 지원플랫폼윈도우, 유닉스, 리눅스윈도우, 유닉스, 리눅스 사용언어 C C, shell scripts, Perl 보안 Numbers SHA-1 hashes 1) 디렉토리, 파일이름변경이불가능하고, 속도가느리며커밋실패시롤백이지원되지않아소스관리의어려움 2) 2002 년에리눅스커널프로젝트는상용 DVCS 시스템인 bitkepper 를사용하기시작했다 년에는리눅스커널을개발하는커뮤니티와 BitKeeper 를개발하는커머셜회사간에관계에문제가생기면서, 툴의무료사용권이사라지게됨. 이사건으로 BitKeeper 기능을토대로새로운버전관리툴을만드는계기가됨 18

19 Subversion 개요 CVS 를개발하던개발자들이 CVS 가가지고있던문제를해결하고자완전히새로운아키텍처를적용하여새롭게만든솔루션 커밋단위가파일이아니라체인지셋 CVS 에서라면여러개의파일을한꺼번에커밋하더라도각각의파일마다리비전이다름 Subversion 에서는파일별리비전이없고한번커밋할때마다변경사항별로리비전이하나씩증가 CVS 에비해엄청나게빠른업데이트 / 브랜칭 / 태깅시간 CVS 와거의동일한사용법으로기존사용자유도 파일이름변경, 이동, 디렉터리버전관리도지원 원자적 (atomic) 커밋 CVS 에서는여러파일을커밋하다가어느한파일에서커밋이실패했을경우앞의파일만커밋이적용되고뒤의파일들은그대로남음 Subversion 은여러개의파일을커밋하더라도커밋이실패하면모두이전상태로회귀 양방향데이터전송으로네트워크트래픽최소화 트리별, 파일별접근제어리스트. 저장소쓰기접근을가진개발자라도소스변경제어가능 저장소 / 프로젝트별환경설정가능 19

20 Subversion 리포지토리구조 여러가지방식의리포지토리구조를생성하여사용하는것이가능함 One repository, many projects Root Project 1 Project 2 trunk tags branches trunk tags branches One project per repository Repository parent dir Project 1 Project 2 trunk tags branches trunk tags branches 20

21 Subversion 작업유형 중앙리포지토리내에서로컬복사후변경한사본을커밋하는방식으로진행 Create a local copy Submit your changes svn checkout svn update Make changes svn add svn move svn delete 100 Subversion Repository svn commit Resolve conflicts (Merge your changes) svn diff svn resolved See what was changed in the repository in the meantime svn status -u Update your local copy svn update 21

22 Subversion 아키텍처 다양한클라이언트인터페이스를통해각리포지토리에접근하여작업가능 Client Interface Repository Interface FSFS Apache GUI clients Cmd line clients Client Library Access Protocol DAV SVN SSH Intranetwork mod_dav mod_dav _svn svnserve sshd Subversion Repository Working Copy Management Library Local "file" protocol Berkley DB 22

23 Git 개요 리눅스커널커뮤니티와 BitKeeper 를개발하는커머셜회사간에관계에문제가발생하면서리누스토발즈에의해새롭게만들어버전관리솔루션 Branching and Merging 새로운패치, 아이디어를위해브랜치를생성하고커밋후다시메인코드로병합이가능 Small and Fast 모든동작들을우선적으로로컬에서실시하게된다. 따라서, 이것은서버와연동하기위해네트워크를타지않아도되기때문에속도면에서여러가지로엄청난장점분산형개발모델 각각의작업환경에서별도로작업한소스들은언제든지메인서버로업로드하고 merge 가가능데이터안전 모든파일은체크썸검사를하고, 다운을받을때에도다시실시를하여 Git 에서모든 bit 까지보장스테이징모드 모든파일은스테이징 ( 로컬 ) 영역에추가되고서버의리포지토리에커밋되는두단계로구성 23

24 Git 작업유형 기존의버전관리시스템과는다른로컬영역의저장소의 2 단계를가짐 명령어들을로컬에서실시하고나중에서버에올리는방식을사용 기존의 svn 에서 commit 이 1. 소스를수정하고, 2. 저장소로업로드하는 2 단계를각각의명령어로분리하여중간에로컬에서일하다가저장소에적용하기전의잠재적인한번의단계를거침 한번의명령으로바로적용되는 SVN 과는달리 2 번의명령을실행해야마침내서버에있는저장소로업로드 "git commit -a" 의명령을통해서다른버전관리프로그램들과같이이용하는것도가능 24

25 분산형개발아키텍처 각팀원의역할을분담해서한명은통합을전담으로수행 다른개발자는각자부분개발에집중을하는식으로역할분담 < 통합관리워크플로우모델 > 팀이커질수록복수의 repository 를쉽게구성가능 하위팀들을묶어주는통합관리자, 그리고전체를통합하는관리자로더세분화해서구성하는것이가능 25

26 ALM 실습