블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

Bazel 빌드툴


Tensorflow Serving을 살펴보다보니, Serving Server는 C++기반에 gRPC 인터페이스 기반이라는 것을 알았는데,

빌드 환경이 bazel이라는 것을 사용한다. 그래서 Bazel이 무엇인가 찾아봤는데. 쉽게 말하면 빌드 툴이다





위키에 설명이 가장 잘나와 있는데, 구글에서 만든 빌드 시스템으로, 구글의 경우 큰 소스코드를 빌드하기 때문에, 이를 위해서 만들어진 빌드 시스템을 오픈소스화 한것으로, 분산 빌드등을 제공하고 빠른 성능을 제공한다.


쉽게 말해서 make,ant,gradle,maven과 같은 빌드 시스템으로 보면 된다.

Java,C,C++,Python,Object C등의 언어를 지원한다.


https://en.wikipedia.org/wiki/Bazel_(software)

In software developmentBazel is an open source tool that allows for the automation of building and testing of software.[2] The company Google uses the build tool Blaze internally[3] and released and open-sourced part of the Blaze tool as Bazel, named as an anagram of Blaze.[4] Bazel was first released in March 2015 and achieved beta status by September 2015.[5]

Similar to build tools like MakeApache Ant, or Apache Maven,[2][4] Bazel builds software applications from source code using a set of rules. Rules and macros are created in the Skylark language, a subset of Python.[4] There are built-in rules for building software written in the programming languages of JavaCC++PythonObjective-C and Bourne shell scripts.[4][5] Bazel can produce software application packages suitable for deployment for the Android and iOS operating systems.[6]

In designing Bazel, emphasis has been placed on build speed, correctness, and reproducibility.[2][4] The tools uses parallelization to speed up parts of the build process.[4] It includes a Bazel Query language that can be used to analyze build dependencies in complex build graphs.[4]


아무래도 개발 환경 설정이 쉽지 않은 만큼, Bazel C++ 빌드 환경이 패키징된 도커 환경을 알아보는것이 더 좋겠다.

저작자 표시 비영리
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

애자일 스크럼과 JIRA를 이용한 구현 방법


근래에 강의했던 스크럼 방법론과 JIRA를 통한 구현 방법에 대한 교육 자료 입니다.

상업적 용도가 아닌 사내 교육이나 스터디등으로 자유롭게 사용이 가능합니다.



저작자 표시 비영리
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

Feature team에서 길드 모델을 이용한, 기술 거버넌스의 확보방안


조대협 (http://bcho.tistory.com)


지난번에 고민했던,  Feature team model에 대해서 조금더 리서치를 해보니, 음원 서비스를 제공중인 Spotify가 이 모델을 조금 더 발전 시켜서 Squad & Tribe 라는 모델을 사용하고 있다. 


Feature team 모델의 문제점 중의 하나가, Feature 단위로 팀을 나누다 보니 발생하는 문제가, 같은 기술을 쓰는 엔지니어가 다른 팀에 속하기 때문에, 기술에 대한 통제(거버넌스)나 기술 교류가 약해질 수 있는 문제가 있다. 




이러한 문제를 해결하는 방법으로는 길드의 개념을 사용한다.

길드는 같은 기술을 사용하는 사람들의 모임으로, 기술적인 리더쉽을 위해서 각 길드에는 길드 마스터가 있다.


다시 쉽게 이야기 하면 백앤드 개발팀에 기술 리드가 있고, 이 인원들이 각각의 기능팀으로 묶여 있는 모델로 보면 된다. 보통 Functional 팀 모델이 백앤드, 프론트 앤드와 같이 기술로 묶는데에 비해서 Feature 팀이 기능 단위로 묶었다면, 기능 단위 팀을 횡적으로 다시 기술 단위로 묶는 모델이다.


기존의 팀 모델 중에서 Matrix 모델이나 Pool 모델과 유사한 성격을 가지고 있다.

저작자 표시 비영리
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

애자일 팀 모델에 대하여

ALM/애자일 | 2015.09.08 23:50 | Posted by 조대협

애자일 팀 발전 모델에 대하여

Functional team, Product Team, Feature Team

조대협 (http://bcho.tistory.com)

 

개요

 

관리자(CTO)역할을 맏으면서 가장 고민중에 있는 것 중 하나는 팀을 어떻게 모델하여 최적화된 개발팀 구조를 가지느냐 이다.

근래의 개발팀의 모델은 애자일 사상에 영향을 받아서 작고, 독립적인 팀의 모델로 진화하고 있으며 대략적인 특징은 다음과 같다.

·             Self organized

·             Cross functional

·             2 pizza team


Cross functional 모델은, 하나의 팀 내에서 기획부터 디자인,개발 및 테스트를 모두 진행할 수 있는 팀 모델로 팀 안에 앱,프론트,백앤드 개발, 기획,테스터와 같은 모든 역할을 하나의 팀내에 모두 가지고 모델이다. 이런 모델을 기반을 Self organized라는 팀 모델을 가질 수 있는데, 이는 팀내의 모든 기능 유닛들이 다 있기 때문에 팀이 독립적으로 제품에 대한 기획에서 부터 개발 및 출시가 가능하게 되는 모델이다. 이러한 팀 모델은 원할한 커뮤니케이션을 전제로 하기 때문에 팀의 구조가 커지면 원할한 커뮤니케이션이 어려운 이유로 팀의 규모는 두개의 피자를 먹을 수 있는 정도의 팀구조 즉 7~8명 정도의 2 pizza team 정도의 구조를 가지게 된다

 

팀 모델과 더불어 이러한 모델을 효과적으로 적용할 수 있는 Devops와 같은 서비스 운영 모델이나, MSA (Micro Service Architecture)와 같은 아키텍쳐 모델이 발전되고 있다. 이 부분은 오늘 다루고자 하는 부분이외의 부분이기 때문에 넘어가도록 한다.

 

이렇게 Cross functional team model로 이동을 함에 있어서도 몇가지 문제들이 발생하는데, 이러한 문제를 해결하기 위한 다음 모델이 Featured team model 이다. 이 글에서는 전통적인 functional team model에서 부터, 현대 애자일이나 MSA와 함께 대두 되고 있는 Component based team model 그리고 최근에 소개되고 있는 Featured team model에 대해서 알아보고자 한다.

 

이해를 돕기 위해서 아래와 같은 일반적인 앱/웹 서비스를 예를 들어서, 이러한 서비스를 개발하기 위한 각 팀모델에 대해서 설명하도록 하겠다.

이 서비스는 뉴스에 대한 포스팅과 함께 포스팅에 대한 댓글 기능을 제공하는 서비스이고,

모바일앱과 HTML 웹 페이지를 이용하여 사용자에게 서비스를 제공하고,

운영 시스템으로는 관리도구를 이용하여 댓글과 포스팅을 관리할 수 있다.”

 



Functional vs Cross functional team


이러한 팀 모델을 이해하기 위해서는 Functional team modelCross functional team model에 대해서 먼저 이해할 필요가 있다.

 

Functional team

먼저Functional team 모델은 가장 흔하게 존재하는 팀 모델중의 하나로, 개발 기술이나 역할 별로 팀을 나누는 방식이다. 예를 들어 프론트앤드 웹 개발, 앱 개발, 백앤드 개발, QA, 운영팀등으로 나눠서 팀을 관리하는 방식이다.

이 팀 모델을 앞에서 언급한 서비스에 적용하게 되면 다음과 같은 팀 모델이 나오게 된다.

 



이 모델의 장점은 기술을 각팀이 잘 통제하여 각 레이어(계층)별로 일관된 아키텍쳐와 기술 통제 모델을 가지고 갈 수 있지만, 일종의 풀(Pool)모델 처럼 각 기능이나 제품을 개발할때 마다 개발자를 그때 그때 마다 순환 배치하기 때문에 제품(프로덕트)에 대한 일관성을 가지고 가기가 힘들고, 각팀간의 인터페이스를 맞추기 위해서 커뮤니케이션 작업이 추가로 많이 소요된다.

 

Cross functional team

그래서 이러한 기술 중심의 Functional team 모델에서 발전한 것이 근래에 유행하고 있는 Cross functional team 모델이다.

Cross functional team 모델은 앞에서도 언급하였지만, 하나의 팀 안에서 기획에서 부터 프론트앤드, , 백앤드 개발, 테스트 및 운영까지 모두 할 수 있는 조직 모델이다.

 

Component Team & Featured Team in Cross functional team model


Cross functional 팀은 모든 기능(역할)구조를 가지고 있는 구조라는 기본을 가지고 있는데, 이를 세부적으로 살펴보면 크게 Component team (Product Team)Featured team 이라는 두가지 모델로 나눠볼 수 있다.

 

근래에 가장 많이 언급되는 Cross functional team modelcomponent team (product team) 모델이다. 모든 역할을 가지고 있는 하나의 팀이 하나의 제품을 맞는 형태이다. 앞서 언급한 서비스 예제에 맞추어 보면 다음과 같은 구조를 따르게 된다.

 



 

특히나 근래에 마이크로 서비스 아키텍쳐 (aka. MSA)와 함께 가장 많이 언급되는 모델로, 하나의 팀이 하나의 제품을 장기간 맏아서 진행하는 형태이다.  이 경우 기획에서 부터 운영 및 기술 셋까지 완벽하게 독립적으로 운영할 수 있기 때문에, 독립성이 매우 뛰어나서 기동성이 나올 수 있기 때문에 이론적으로는 참 이상적이다.

 

이상적이기는 하지만 이 모델에는 단점이 존재하는데, 일반적으로 하나의 서비스는 하나의 제품이로만 구성되지 않으며, 서비스를 구성하는 제품간에는 유기적인 연동이 반드시 필요하다는 것이다.

위의 예를 들어보면 새로운 댓글 기능이 들어간다고 가정했을때, 이 댓글 기능은 단순히 앱 개발팀이 혼자 단독적으로 수행할 수 있는 것이 아니라, 웹 개발팀도 댓글을 개발해야 하고, 관리도구 개발팀도 이 댓글을 관리 하는 지원 시스템을 개발해야 한다.

그러면 댓글이란 기능을 개발하려면 요구 사항이 3개의 팀으로 전파되어야 하고, 3개의 팀의 연계 아키텍쳐가 같이 설계되어야 한다.

즉 단일 요구 사항을 분석하고, 아키텍트가 기능에 대한 전체 컴포넌트에 대한 큰 설계를 마무리 한후 각 프로덕트팀으로 설계를 내려 보내서 개발을 진행해야 한다.



<그림. Component(Product) 기반 개발팀의 개발 프로세스 >

출처 : http://www.featureteams.org/feature_team_primer12.pdf

 

실제로 필자가 몇년전에 운영했던 팀운용 방식인데, 여러 프로덕트팀을 조율하는 Chief 아키텍트의 역할이 필요하고, 또한 각 팀의 개발 역량이나 개발 분량이 다르기 때문에 개발 스케쥴이 서로 맞지 않는 일이 발생하고 결국에는 이를 조율하기 위한 Program manager와 같은 역할이 필요하다.

 

새로운 팀에서도 이러한 방식의 팀 모델링을 하려고 시도를 했으나 벽에 부딪혔다. 기획이 각 기능 단위로 나오기 때문에, 각각의 프로덕트 오너(기획자)를 팀마다 묶을 수 도 없었을 뿐더러, 그렇게 팀을 나누기에 팀의 크기에 팀원간의 역량에도 차이가 있었다.

할 수 없이 전통적인 Functional Team 모델을 사용하면서 운용을 하면서 적절한 팀 모델을 찾기 시작했다http://bcho.tistory.com/1040

 키는 기능 단위의 팀 모델을 찾았는데, Feature Driven Development (FDD)와 같은 개발 방법론을 찾았으나, 실용적인 개발팀 모델은 찾지는 못했고, 어설프게나마 기능 우선의 개발팀 모델이 필요하다는 것을 느끼고 팀구조를 그렇게 차차 전환하던중에, Craig LarmanBas Vode가 작성한 “Feature Team Primer” 라는 문서를 찾게 되었다. http://www.featureteams.org/feature_team_primer12.pdf

 

잠깐 옆으로 빠지자면, Craig Larman을 처음 접한것은 1996Applying UML 이라는 책을 접하면서였다. 그 당시만 해도 UML에 대한 서적들은 대부분 UML에 대한 Notation이나 다이어그래밍 방법에 포커스가 맞춰져 있었을뿐, 요구 사항에서 부터 UML기반의 잘 정리된 설계 문서까지를 만들어내는 프로세스나 실용적인 방법론이 없었기 때문에 나름 상당히 감명을 받고 읽은 책이었는데, 2010년대에, 큰 조직에서 일을 하면서 애자일 방법론을 엔터프라이즈 레벨까지 확장하고 싶다고 생각하면서 찾았던것이 Enterprise Agile 방법론이나 Scaled Agile 방법론이었는데, 그러던중에 “Scaled Lean & Agile Development” 라는 책에서 또 다시 Craig Larman을 만나게 되었다.




변함없이 실용적인 내용을 담고 있었고, 그 나이에도 그러한 안목과 실용성을 잃지 않는다는게 대단하다고 느끼게 하는 분이다.

그리고 이 “Feature team primer”의 공동 저작자인 Bas VodeOdd-e라는 애자일 컨설팅 회사의 컨설턴트로, 국내에서 일년에 몇번 애자일 교육을 여는 분인데, 팀원들에게 애자일 스크럼 공인 자격증을 받게 하기 위해서 교육 프로그램을 찾던중에 접하게 되었다. 노키아 애자일 방법론등에 영향을 줬고, Craig Larman과 이 문서를 만들었는데, 국내에 20159월달에 교육이 있었고, 오프모임까지 있었지만 (신청해놓고 못나갔다.) 못 만난게 아쉽다. 30분이라도 이야기할 시간이 있었다면 아마도 또 다른 배움이 있지 않았을까?

 

다시 본론으로 돌아와서, 이러한 제품 기반의 Cross functional team의 문제점을 해결하고자 제안된 방법론이 Feature Team 모델이다. 이 모델은 Cross functional team을 조직하고, 이 팀이 제품(프로덕트) 단위가 아니라 기능 단위로 여러 프로덕트에 걸쳐서 개발을 진행하는 모델이다.




 

이 팀 모델을 앞에서 제시한 예시 서비스에 대입해보면 위와 같은 그림이 된다.

각팀에는 기획, 프론트,백앤드,,QA등의 모든 역할의 사람이 들어가 있고, 각 팀은 댓글이나 포스팅과 같은 기능 단위로 전체 컴포넌트(프로덕트)에 걸쳐서 개발을 진행한다.

 

지금까지 생각에는 이게 조금 더 실리적인 방법이 아닌가 하는 결론에는 도달해 있으나, Feature team 모델 역시 많은 단점과 제약 사항을 가지고 있다. 예를 들어 백앤드 개발자는 전체 백앤드에 기능을 녹여놔야 하기 때문에, 전체 백앤드의 구조를 모두 알고 있어야 한다. 프론트앤드도 웹과 관리도구에 대한 프론트엔드 개발을 해야 하기 때문에, 전체를 다 알아야 한다. 즉 개인 개발자나 기획자가 커버해야 하는 영역이 늘어나고, 손대야 하는 코드가 많아지기 때문에, 코드를 개발한 후 머지도 여러 컴포넌트에 걸쳐서 해야 하고, 손이 많이 가지만 하나의 서비스 기능에 대해서 일관성을 가질 수 있는 장점은 있다.

또 다른 문제로는 중앙 통제적으로 아키텍쳐를 드라이브하지 않기 때문에 기능별로 각각의 변종 아키텍쳐가 생겨날 수 있는 문제가 생기고 결국은 기술에 대한 통제 (Technology governance)문제가 발생한다.

 

기술적으로 한명의 엔지니어가 전체 영역을 이해하고, 거기에 각각 코드를 넣기 위해서는 많은 시간이 필요한데, 이를 줄이려면, 새로운 기능을 넣는 컴포넌트(프로덕트)가 새로운 기능을 붙이기에 잘되어 있다면 가능하다. 여기서 프레임웍과 플랫폼에 대한 니즈(needs)가 발생하는데, 새로운 기능을 쉽게 꼽아 넣을 수 있는 형태로 시스템이 개발되어 있으면 된다. 새로운 API를 넣기 위해서는 Spring REST + JPA를 레퍼런스에 따라서 개발을 쉽게할 수 있고, DB 정규화 없이도 탄력적으로 DB모델링을 할 수 있는 Document based NoSQL (eg. MongoDB, CouchBase etc)들로 잘 구성되어 있으며 가이드가 잘되어 있다면, 새로운 기능을 기존 컴포넌트에 추가하는데 크게 문제가 없다. Feature team 모델을 운영하려면, 시스템 아키텍쳐가 쉽게 이해하고 확장할 수 있는 구조로 설계되어 있어야 하고, 새로운 기능을 추가하기 쉬운 가이드나 레퍼런스 구현이 잘되어 있어야 하며, 여러 컴포넌트에 걸쳐 한명의 개발자가 기능을 추가할 수 있어야 하기 때문에, 테크놀로지(프로그래밍 언어나 프레임웍)들이 한정(표준화)되어 있고, 각 엔지니어들에게 교육되어 있어야 한다.

 

그렇다면 결론은 Feature Team 모델인가?

그렇다면 이 Feature team 모델이 모든 개발에 있어서 만병 통치약인가? 결론은 당연히 No이고, 모범 답안은 역시 “Case by case” 이다.

조직에 따라서 프로덕트 단위로 개발을 하는게 더 효율적일 수 도 있고 이런 경우에는 프로덕트(Component) 중심의 cross functional team 모델이 적합할 수 도 있다. 프로덕트에 따라서 빠르고 생산적인 개발 기술이 필요할 경우에는 Ruby on railsnode.js 로 그 제품(프로덕트)를 개발하는 모델을 사용할 수 있다.

또는 한 조직내에서 어떤 제품은 독립성이 높고, 계속해서 기능 추가가 독립적으로 가능하다면 제품 기반의 cross functional team으로 독립 운영하고, 나머지 부분은 Feature team 모델로 운영할 수 도 있다.

즉 개발하고자 하는 서비스나 팀의 상황, 조직의 성숙도, 개발 스피드, 기술 수준, 관리 역량등 다양한 요인에 맞춰서 팀 모델을 점차적으로 변화시켜 나가고 최적의 모델을 찾는게 답이 아닌가 싶다.

 

참고 : http://www.featureteams.org/feature_team_primer12.pdf

저작자 표시 비영리
신고
크리에이티브 커먼즈 라이선스
Creative Commons License


플래닝 포커를 이용한 프로젝트 일정 산정

조대협 (http://bcho.tistory.com)


프로젝트 진행을 하거나, 애자일 방법론 기반으로 스프린트 기반의 프로젝트를 진행할때도 항상 문제가 되는 것이, 일정 산정이다. 먼저 정확한 일정 산정이 어려울 뿐더러, 프로젝트를 진행하는 외부의 인원이 보기에 일정 산정의 근거가 약해서 “왜 저일이 왜 그렇게 오래 걸려요?” 라는 등의 비난을 받을 수 가 있다.


그래서 정확한 일정 산정 프로젝트 일정 관리와 함께, 팀의 일정 산정에 대한 정당성을 확보하는 것 두 가지의 목적을 가지고 있다. 


그러나 이러한 일정 산정은 불확실한 미래를 예측하는 작업이기 때문에 매우 어려운데, 이러한 일정 산정의 좋은 기법의 하나로 “플래닝포커(Planning Poker)”라는 기법을 소개하고자 한다.


플래닝 포커는 애자일 기법으로 대략적인 방식은 다음과 같다.

먼저 다음과 같은 역할이 필요하다.


  • 기획자(Product Owner) : 요구 사항을 정의하는 사람
  • 진행자 : 플래닝 포커를 진행하는 사람
  • 참석자 : 실제 개발을 진행하는 사람


그리고, 그 스프린트에서 개발을 진행할 요구 사항 목록이 필요하다.  (User story backlog)

준비가 되었으면 다음과 같은 순서로 진행한다.


기획자가 먼저 사용자 스토리를 전체적으로 쭈욱 훝어가면서 설명한다. 이를 통해서 참석자들이 무엇을 개발할것인지 사용자 관점에서 이해를 하게 된다. (전체 그림을 이해하는 단계.) 이때 가급적이면 사용자 스토리는 사용자가  사용하는 시간순으로 나열되는게 좋다.

예를 들어 다음과 같은 스토리가 있다고 하자


  • 글쓰기
  • 글목록보기
  • 로그인


사용자 시나리오 순서는 사용자가 로그인 한후, 글 목록을 본후에, 새로운 글을 글쓰기로 올린다. 라고 했을때 위의 백로그는 시간 순서에 맞지 않는다.

그래서 백로그를 정리하면 다음과 같이 정리가 되는게 좋다. 


  • 로그인
  • 글 목록 보기
  • 글쓰기


(참고. 이렇게 시간 순서대로 사용자 스토리를 배치하는 기법을 사용자 스토리 맵핑이라고 한다.)


전체 컨택스트(문맥)을 이해했으면 각각의 스토리에 대해서 걸리는 시간을 Estimation (산정)한다.

하나의 스토리를 올리고, 기획자가 기능에 대해서 다시 설명을 한다. 참석자는 기능에 대해서 궁금한점이 있으면 기획자에게 물어보고 설명을 듣는다. 어느정도 기능이 이해가 되면 그 스토리에 대해서 참석자들이 구현에 걸릴 시간을 투표한다. 기간은 디자인, 구현 과 “테스트”를 포함한 시간을 예측해서 투표한다.

이 기간은 전체 구현기간이다. 예를 들어 “로그인”이라는 기능을 앱에 구현할 경우, 앱 개발 기간, 뒷단의 API 서버 백앤드 개발 기간을 예측 산정해야 한다. 참석자가 당연히 풀스택은 아니겠지만 그간의 경험을 기반으로 예측 산정을 한다. (정확하지 않을거 같은데.. 직접 해보면 생각보다 정확도가 높다.)


예측치를 상대방에게 보이지 않고 포커에서 카드를 뒤집듯이 한꺼번에 뒤집기 때문에, 플래닝 포커라고 이야기 하고, 이렇게 함으로써 상대방의 예측에 관여하지 않고 각 참석자의 의견을 객관적으로 들을 수 있다.


요즘은 시스템이 발전해서 이러한 플래닝포커를 실제 카드로 하지 않고 웹/앱의 온라인 시스템을 사용할 수 있다.


 


<그림. http://www.planitpoker.com/ >


본인의 경우http://www.planitpoker.com/을 이용해서 실제 플래닝 포커를 수행했는데, 사용하기가 그다지 어렵지 않다. 


단, 여러개의 스토리를 손으로 일일이 입력해야 하고(액셀 업로드가 있었으면 좋았을듯..) 반대로 끝나고 나서 결과를 액셀로 다운로드가 불가하다. (수기로 적었다.)


(혹시나 더 좋은 툴을 발견하면 알려주시기를..)


투표가 끝났으면 제일 낮은 점수와 제일 높은 점수의 사람으로 부터 그렇게 점수를 준 이유를 설명을 듣는다.

낮은 점수를 준 사람은 몬가 빠른 해결책을 가지고 있을 수 있고, 반대로 높은 점수를 준 사람은 다른 사람이 놓치고 있는 것을 알고 있을 가능성이 많다. 충분히 의견을 듣고, 같은 스토리에 대해서 투표를 재 진행한다.

주의할점은 투표를 하기전에 얼마의 일정이 걸릴지를 다른 사람에게 절대 이야기 하지 않는다. (아이고 이장님~~~!! 이 뜻을 아시는분은 있을듯..). 그러면 그쪽으로 의견이 쏠리기 때문에 객관적인 일정 산정이 어렵다.





이 과정이 중요한것이, 일정 산정시 내가 놓치고 있는 부분에 대한 의견 교환이 가능하다는 것이다.

재 투표는 대략적으로 포인트가 비슷한 포인트로 수렴할때 까지 계속해서 반복한다. (8번까지도 해봤다는..)


여기에 몇가지 팁이 있는데, 스토리가 복잡할 경우, 먼저 스토리를 구현하기 위한 대략적인 아키텍쳐를 설계 해보는 것이 좋다. (종이에… 본인의 경우에는 3M 에서 나오는 테이프가 달린 4절지를 애용하는데..) 이 과정에서 전체 팀원이 대략적인 아키텍쳐에 대한 협의가 이루어지고 같은 컨택스트에 들어오는 효과가 있다.


아래 그림의 뒤의 벽에 붙어 있는 사진이 각 스토리를 구현하기 위한 아키텍쳐 흐름이다.






이렇게 모든 과정이 끝나면, 전체 스토리 포인트를 합산하여 걸리는 시간을 예측한다. 본인의 경우 1포인트를 “한사람이 하루에 할 수 있는 양”으로 정하는데, 60포인트가 산정이되고 팀원이 4명이라면 총 15포인트. 워킹데이로 3주가 소요되고, 스토리가 빠질 수 있는 가능성이나 버퍼를 감안해서 20~30% (야근을 피하고 싶다면 50%)를 곱해서 전체 기간으로 산정한다. 


20개 내외의 스토리에 대한 일정 산정은 전체 스토리 설명 (1시간) 투표 (1~1.5시간) 정도가 소요된다.


몇가지  경험을 공유하면

내가 구현하지 않는 부분에 대해서 상대방에게 가혹하게 짧은 일정을 줄 수 있다.

수평적인 커뮤니케이션이 가능해야 한다. 아니면 주니어 엔지니어가 시니어 엔지니어 의견에 밀려서 객관적인 산정이 깨질 수 있다.

그리고 생각보다 잼있다. 

:)


저작자 표시 비영리
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

스크럼 모델에 대한 고민


요즘 애자일 스크럼 방법론에 대한 회의를 느끼고 있습니다.

가장 널리 사용된다는 스크럼 방법론이고, 예전 몇몇 회사에서도 톡톡히 재미를 봤던 방법론이기 때문에 새로운 팀에 스크럼 방법론을 적용하기 위한 시도를 하고 있습니다.


그런데, 이 스크럼 방법론이 동작하지를 않습니다.

스크럼의 전제 조건인 즉슨, 스크럼팀이 Product(상품/서비스) 단위로 움직인다는 개념을 가지고 있습니다.

즉 특정 기능이나 모듈에 대해서 특정 팀이 계속해서 오너쉽을 가지고 개발을 진행하는 모델로, 이렇게 하면, 상품에 대한 경험이 지속적으로 쌓인다는 장점이 있습니다. 그리고 기획자 (Product Owner : PO)가 팀 내에 있기 때문에 궁극적으로는 각 서비스가 독립적으로 스스로 기획 부터 개발, 테스트까지 같이 될 수 있는 장점이 있습니다.

결과적으로는 팀이 무진장 빨라지고, 타 팀에 대한 의존성이 없이 개발을 나갈 수 있기 때문에 상당히 효율적이기 때문에 많은 개발팀이 택하는 방법론입니다.


그런데 이 방법론에는 몇가지 문제가 있습니다.

일단 서비스나 상품별로 쪼겔 수 있는 만큼의 팀 규모가 되야 하며

각 기획 인원과 개발팀으로 이루어진 팀이 그에 맞는 실력을 가지고 있어야 한다는 전제가 있습니다.

특히나 각 서비스가 서로 의존성을 가지고 있다면 전체 팀의 스피드에 문제가 될 수 있습니다.


간단하게 신문사 서비스가 있다고 가정하져. 시스템은 저작도구, 앱 그리고 웹 등으로 구성되어 있다고 합시다.

이때 어떤 새로운 기능을 넣으려고 하면, 저작도구 팀, 앱팀, 웹팀이 스피드를 같이 맞춰서 나가야 합니다.

근데 한팀의 역량이 안 따라와 주면, 전체 서비스 개발에 진도가 맞지 않게 됩니다.


예전에. 모 회사에서 새로운 서비스를 개발할때가 있었는데, 여러 시스템이 많이 얽혀 있었고, 스크럼 방법론으로 PO 기반의 개발을 하고 있었습니다. 이러다 보니, 중앙에 있는 웹 포탈 시스템이 요건에 대한 부하를 많이 받게 되더군요. 새로운 요건이 들어왔을때, 각 개별 서비스는 그 기능만 개발하면 되지만 반대로 포탈은, 포탈 자체의 개선 이외에 신규 서비스에 대한 기능 개선 요건을 처리해줘야 하기 때문에 어려운 점이 종종 있었습니다. 그나마 상품이 잘 나눠져 있는 상태라서 잘 Working을 했는데, 이번에는 상황이 좀 다른것 같습니다


내부에 시스템 종류는 아직 크게 많지는 않으며, 팀 규모가 스크럼 팀 형태로 운영하기에는 애매한 사이즈이고.

기획이 각 프로덕 기반으로 나오는게 아니라, 기능 기반으로 나오고 있기 때문입니다. (사실 이게 지금은 맞는 모델 같네요.)


그러다 보니, 여러 기능을 한 스프린트에 동시 개발하다 보면, 여러 서비스 컴포넌트들이 동시에 여러 기능에 대한 요건을 여러 기획자로 부터 받게 되서 개발팀이 혼란이 생기는 경우가 있습니다.


예를 들어 이런거져, 앞의 신문사 서비스의 예를 계속해서 이야기 해보면, 네이버 연동 서비스 기능, 로그 수집 기능 추가, 새로운 신문 기사 컨텐츠 타입 추가 라는 기능들이 각각의 기획자로 부터 나왔다고 봅시다. 그런데 각 기능을 정의한 기획자가 각각이다 보니, 스크럼 모델과는, 다르게 PO가 상품 별로 있는 것이 아니기 때문에, 저작도구,앱팀,웹팀과 같은 개발팀이 이 여러가지 요건에 대해서 우선 순위를 정하기가 매우 어려워집니다. 아울러 안 좋은 경우 각 기획자를 개발팀이 코디네이션 해야 하는 문제까지 생길 수 가 있습니다. 결국은 개발팀내의 새로운 PO나 PM이 필요할 수 도 있고, 이런 역할이 없을 경우, 오히려 개발자가 이런 역할을 겸임해야 하기 때문에 오버로드가 생길 수 있게 됩니다. 그렇다고 작은 조직안에서 기능 기획 이외에, 각 상품(서비스)별로 기획자를 넣는 것은 새로운 오버로드가 될 수 있습니다


그러면 어떻게 이 문제를 해결해야 할까?

기능 위주로 개발을 하는 애자일 개발 방법론이 있는데, 이를 FDD (Feature Driven Development)라고 합니다.

이름은 있는데, 그렇게 크게 유행하는 방법론이 아니라서, 덮어 두고 있다가 요즘 들어서 주의 깊게 살펴보고 있습니다.

개발을 상품이나 서비스 단위가 아니라 신규 기능 단위로 하는 개발 방법론입니다.


이 방법론을 선택할 경우에는 각 개발 컴포넌트별 코디네이션이 대단히 중요합니다. 신문사 시스템 예제의 웹/앱,저작도구 와 같은 개발팀이 있을 경우, 하나의 신규 기능을 개발하기 위해서 전체 팀에서 필요한 내용을 중재하기 위한 프로젝트(또는 프로그램 관리자)와 전체 시스템 흐름을 정의할 수 있는 아키텍트의 역할이 필요하게 됩니다.


아울러 개발하고자 하는 피쳐의 크기가 작을때, 동시에 몇개의 피쳐를 더 개발하고자 하면, 각 팀의 개발 속도가 어느정도 맞아야 하느넫 이를 조율하는게 큰 문제로 다가옵니다. 단순하게 각 개발팀의 역량이나 사이즈의 문제가 아니라, 기능에 따라서, 각 팀이 개발해야 하는 개발량이 매번 다를 수 있다는 것입니다. 그러면 어떤 개발팀은 놀고 어떤 개발팀은 항상 바쁜 현상이 발생하게 됩니다.


이를 해결 하려면, 크로스 앤지니어링을 통하여 리소스를 유연하게 운용할 수 있는 방법이 필요하게 됩니다.

즉, 어떤 기능에 대해서 개발할 양이 앱팀이 적고, 웹팀이 많으면, 앱팀의 리소스를 웹팀으로 그 기능을 개발하는 동안만 배치해서 개발을 하고 빠지는 운영 방식이 필요합니다. 이를 위해서는 팀간의 개발 도메인 뿐만 아니라 각 시스템에 대한 이해도가 높아야 하기 때문에 대단히 어려운 방식이지만, 반대로 요즘 같은 풀스택을 기본으로 하는 스타트업에는 적절한 방식이 될수 있습다. 


내지는 서비스별로 개발팀을 나누는 게 아니라 (앱,웹팀, 저작도구 팀), 기술별로 팀을 나눠서 운용을 하고, 각 기능별로 임시 팀을 만들어서 운용하는 방법이 있을 수 있습니다. 예를 들어 안드로이드, 웹 프론트, 백앤드 팀이 있다고 하고 각 팀이 특정 기능을 개발하고자 할 때, 기능을 개발할 인원을 착출해서 개발을 진행하고 끝내는 방식입니다. 이렇게 하려면, 각 팀의 개발 인원이 각 서비스에 대해서 잘 알고 있어야 한다는 전제를 가지고 있습니다. 즉 웹 프론트 앤지니어가 저작도구, 웹을 동시에 건들 수 있어야 합니다. 이 경우, 각 서비스에 대한 도메인 지식 수준이 높아야 하기 때문에 개발자가 여기저기 서비스에 컨택스트 스위칭을 해야 하는 부담이 생기기 때문에 큰 서비스에서는 사용을 하기 어려운 모델이라고 볼 수 있습니다.


팀에 대한 리더쉽을 잃지 않기 위해서 각 기능별로 PM 역할을 하는 사람이 정의되어야 합니다.

또한 각 기술별로 리더쉽을 유지하기 위해서는 앱,웹 등 기술별로 팀장을 둬서 역량 개발이나 일반적인 관리 업무를 수행하고, 개발 업무는 기능별 PM이 관리해야 합니다. 즉 하나의 개발자에 두명의 메니져가 생기는 모델인데 이를 매트릭스 팀 모델이라고 합니다. 


요즘은 개발 프로세스와, 팀 모델링 방법론에 관심이 많습니다. 관심도 가져야 하구요.

대기업 만큼 풍부한 리소스를 쓸 수 없으니, 최적화를 통한 기동성 확보 방법에 대한 고민중인데, 좋은 방법이 없을까요?














저작자 표시 비영리
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

애자일에서 문서화가 필요할까?

ALM/애자일 | 2015.01.24 19:37 | Posted by 조대협

애자일에 문서 작성이 필요할까요?

조대협 (http://bcho.tistory.com)


일본에 계신 정도현님과, 마이크로서비스 아키텍쳐에 대해서 이야기 하다가, 팀이 분할이 되어 있어서, 서로 디자인등에 대한 싱크업(서로 사상과 내용을 공유해서 모두 디자인을 이해하도록 하는것)을 하기가 어렵다는 이야기를 하던중에, 정도현님이 추천해준 글을 보니, 문서화에 대한 이야기가 나옵니다.

http://www.infoq.com/articles/kenji-modeling-agile

이 글인데, 생각해볼만한 가치가 있어서 몇가지생각을 정리해서 남겨봅니다.

마이크로 서비스 아키텍쳐의 장점은 각 서비스를 개발하는 개발자가, 자신이 개발하는 서비스에 대해서 알기가 편하다는 겁니다. 서비스가 작게 쪼게져 있으니 빠르게 이해할 수 있지만, 반대로 전체 시스템에 대한 구조나 사상을 이해하기 어려운 문제가 생깁니다.

실제로 제 경험상, 여러 팀에 서비스를 쪼게주고, 각 서비스에 대한 기능만을 이야기 해주고 서비스를 모아보면, 전체 시스템 사상에 맞지 않는 설계들이 많이 나옵니다.

서비스를 나눠서 개발한다하더라도 전체 팀이 같은 목표와 같은 큰 맥락의 디자인을 공유해야할 필요가 있는데, 제 경우를 먼저 예를 들어보면, 먼저 요구사항을 수집하고 요구사항에 있는 주요 시나리오를 기반으로 전체 컴포넌트와 주요 시스템 흐름을 문서로 정의합니다. 그후에, 분산되어 있는 각팀에 있는 아키텍트들과 싱크업(공유를) 합니다. 주로 전화나 화상회의를 통해서 문서를 화면 공유해서 보면서, 이 시스템의 전체적인 기능은 OO가 있고, 각 기능에 대한 흐름을 컴포넌트들간의 인터렉션 다이어그램을 보면서 쭈욱 같이 따라갑니다. 팀이 많고 분산되어 있다보니, 시간이 많이 걸립니다. (시간대도 틀리기 때문에.)

그러면 전체적인 사상적 공유가 이루어지고, 각 세부 서비스에 대해서 디자인을 각팀에 요청합니다. 그후에,   컴포넌트에 대한 디자인이 오게 되면, 검토를 해서 전체 흐름에 문제가 없는지를 검증합니다

개인적으로 문서 작업을 썩 좋아 하는 편은 아니지만, 그래도 최소한의 문서작업은 꼭 필요하다는 생각을 가지고 있었고, 마이크로 서비스 아키텍쳐에 대해서 고민하던중, 실제로 팀간에 디자인에 대한 이해가 틀려서 문제가 생기는 경험도 많이 했고, 문서를 놔두고 설명을 하면 서로 싱크업이 잘못되거나 서로 잘못 이해 하는 경우를 많이 줄일 수 있었습니다.

특히나 영어로 커뮤니케이션을 해야하기 때문에 상대방이 OK 알아들었다고 하더라도, 이해의 수준이 다릅니다.  또는 잘못 이해하고 이해했다고 하는 경우도 많구요. 이해를 확인하기 위해서 문서화를 하면 이 사람이 제대로 이해했는지 못했는지를 확인할 수 있습니다.


문서 작성 원칙

 

애자일 사상은 문서화 방법이나 문서화를 하라 말라에 대해서는 정확하게 가이드 하지 않습니다. 문서화를 최소화 하라고는 합니다만, 하지말라고도 않합니다.

자칫 이해가 잘못되면, 애자일에서는 문서화를 하지 말라는 것으로 이해될 수 있습니다.

지금까지 대략적으로 문서화의 필요성에 대해서 이야기 했는데, 그렇다면 효율적인 문서화 원칙에 대해서 생각해봅시다.

첫번째. “커뮤니케이션을 위한 문서화를 하라는 겁니다.

애자일에서 효율적인 문서화는 최소한으로 문서화를 하되, 잘못된 문서 관행을 만들어 낸 이유는 보지도 않는 문서를 프로세스에 맞추기 위해서 산더미 같은 문서를 만들어내기 때문에, 문서화를 기피하게 되는데, 대화를 시작하기 위한 문서는 효율성이 높습니다. 그냥 대화를 시작하면 원래 주제를 잃거나 서로 다른 기준점에서 출발해서 이해에 더 많은 시간이 소요될 수 있는데 문서는 같은 기준점을 줄 수 있습니다.

이때 문서를 만들고 그냥 주고..읽어보세요 라고 하면 절대 안되고, 문서를 보고 설명을 해야 합니다.


두번째. “문서는 계속해서 업데이트 되어야 한다

리뷰나 디자인 변경, 요구 사항 변경에 따라 계속해서 변경되기 때문에 문서는 계속해서 업데이트 되어야 합니다. 이때 중요한것이 변경 관리 인데, 변경된 내용은 문서 배포시 같이 함께 변경 내용을 공시 해서 배포 해야 합니다. 이때는 문서 히스토리 (Revision history) 페이지를 맨 앞장에 추가해서 무엇이 누구에 의해서 언제 어떻게 변했는지 기록해야 합니다. 수십 페이지 문서중에서 어떤 부분이 변화 되었는지를 이야기 하기 힘드니까요.

그래서, 앞에서도 설명했듯이 문서가 변경이 된 후에는 반드시 문서만 전달하는게 아니라 바로 또는 주기적으로 전체 흐름을 리뷰해서 공유를 해야 합니다.


세번째. “업데이트된 문서는 쉬운 방법으로 공유되어야 한다.

문서를 개인 PC에 저장하고 이메일을 통해서 배포하면 문제되는 점중의 하나가 이메일을 제대로 체크하지 않은 사람은 예전 버전의 문서를 계속 보고 있을 가능성이 매우 높다는 겁니다. 그래서 공유된 문서 저장소 개념이 필요한데, 이는 마이크로 소프트의 쉐어 포인트등을 이용하는 것도 하나의 방법이될 수 있고, 드롭박스와 같은 온라인 클라우드 스토리지를 이용하는 방법도 있습니다.

조금 더 진보적인 방법으로는 파일로 문서를 만들지 않고, 아예 위키에 작성해서 온라인으로 실시간으로 공유하는 방법도 있습니다. (아틀라시안 社의 Confluence 위키의 경우, MS-WORD 플러그인을 이용하면, 워드에서 저장하면 자동으로 Confluence에 저장되도록 하는 것도 가능합니다.)


문서에 들어가야 하는 내용

 

그러면 효율적인 문서 작성을 위해서 문서에 들어가야 할 내용을 알아보자. 꼭 문서화 되어야 하는 내용은 크게 3가지 인데,

  • ·         주요 사용자 시나리오

  • ·         아키텍쳐

  • ·         도메인 모델

를 들 수 있습니다. 이를 모두 묶어서 큰그림(Big picture)라고 부르도록 하겠습니다.


3가지 모델을 문서화하는 가장 큰 이유는 이 3가지 요소가 전체 시스템을 이해 하는데 가장 핵심 적인 요소가 됩니다.

기존의 전통적인 소프트웨어 개발 방법론은 divide & conquer 식의 접근 방법, 즉 전체 시스템을 조각조각 나눠서 설계 하는 접근 방식을 사용했으나, 근래에는 conquer & divide식의 역행된 방법이 권장됩니다.

“Rather than divide and conquer, an XP team conquers and divides. - Kent Beck”

이러한 접근 방식은 구성원에게 전체의 숲을 보여주고, 각각의 나무를 보게 하는 방식으로.

예를 들어 보면, 큰 도시를 계획하고 만들려고 했을 때 각각 건물을 먼저 디자인한 후에 배치하는 것이 아니라, 전체 도시에 대한 커다란 구도를 잡고 각 구역에 맞는 건물을 디자인하는 것과 같은 이치가 됩니다.

이런 접근을 구체화 하려면 ,전체 시스템에 대한 기능이나 주요 사용자 시나리오를 기술하고, 그 후에, 아키텍쳐를 서술하는데, 아키텍쳐는 주요 기능을 구현하기 위해 필요한 컴포넌트와 그에 대한 관계를 기술하고, 그 다음에는 각 시나리오를 실행하기 위한 컴포넌트간의 플로우(UML에서 activity diagram또는 sequence diagram)를 서술하는 구조가 됩니다.

이와 아울러 시스템을 구성하기 위한 도메인 (개체)들에 대한 모델을 정의하는 것이 필요한데, 데이타 베이스의 ERD등이 대표적인 예에 속한다. 이를 통해서 전체 시나리오가 어떤 개체에 의해서 이루어지는지 그리고 각 시나리오를 구현하기 위해서 어떤 컴포넌트들이 필요하며 컴포넌트들이 어떻게 순서대로 상호 작용을 하는지 이해할 수 있습니다.


공유 방식


자아 그러면 이쯤에서 Infoq.com에 있는 Kenji님의 글중에 있는 내용을 몇가지 살펴봅시다.

문서 공유 방식에 대해서, 좋은 방법을 제시하고 있는 데, “타이거 팀이라는 개념이 잘 정리된 개념이라서 이 개념을 기반으로 설명해보겠습니다.

먼저 전체적인 개념을 요약하자면,각 서브 개발팀의 리드들이 타이거 팀이라는 형태로 모이고 큰그림(아키텍쳐,주요 시나리오,도메인 모델)등을 정의하고 이를 같이 리뷰하여 공유 합니다.



<그림. 각 서비스 개발팀에서 타이거팀에 모여서 큰 그림을 공유>


타이거 팀 멤버들이 이해가 다 되면 각 팀으로 돌아가서 큰그림 문서를 가지고 다시 전체 팀에 전파 하는 방식입니다.


<그림. 타이거팀 멤버들이 각팀으로 돌아가서 큰 그림을 각 팀원에게 전파>


이때 타이거팀의 멤버는 각 서브 개발팀에서 기술과 커뮤니케이션에 뛰어난 사람이 되어야 한다.

실제 예를 들어 보면, 여러개의 서비스 컴포넌트 개발팀이 있을때, 각 서비스 컴포넌트 개발팀의 아키텍트가 모여서 치프 아키텍트 아래에서 전체 시스템을 설계하고 토론한 후에, 큰그림 문서를 만들고 나서, 공유 합니다. 이해가 되면 각 팀으로 돌아가서 각 서비스 개발팀의 아키텍트가 큰그림 문서로 모든 팀원에게 전체 시스템 사상과 기능,구조등을 설명하게 됩니다.

각 팀에서 나온 피드백은 아키텍트가 수집해서 검토하고 팀내의 토론을 거쳐서 아키텍트 모임에 의견을 제시 하여 전체에 반영되게 하고, 다시 큰 그림 문서를 업데이트한 후에, 다시 각 팀에 전파를 합니다.

처음 전체 큰그림을 이해하고 전파하는데는 시간이 걸리지만, 큰 그림이 정의된 후에, 세부 조정은 그다지 많지 않은 문서 수정과 공유 시간만으로 가능합니다.

이때 팁은 전체 주요 시나리오를 먼저 설명한 다음에 각 시나리오별로 아키텍쳐 흐름을 따라가는 방법이 효과적입니다.


Kenji님의 문서에서는 이러한 형태의 중앙팀을 타이거팀이라고 소개하였는데, 인터넷을 찾아보니 타이거팀에 대한 정의는 갖가지라서 자세한 정의는 찾아보기 바랍니다.

일반적으로 타이거팀은 뛰어난 사람들을 모아서 프로젝트에서의 문제를 해결하는 소방수와 같은 역할을 하는 개념이나, 또는 프로젝트 초반에 구조와 기술을 잡아내는 선행 개발팀과 같은 개념으로 설명이 되는 경우가 많습니다. 이러한 개념은 예전에도 COE (Center Of Excellence)팀이라는 개념으로 있었고, 애자일 모델에서 각 스크럼팀간의 공유를 위한 스크럼위의 스크럼을 타이거팀으로 정의할 경우에는 예전에 PMO (Project Management Office : 프로젝트 관리 모임. 그러나 PMO는 별도의 분리된 팀 모델을 가짐. 스크럼의 스크럼은 각 멤버들이 각 스크럼에 속해 있고 공유를 위할때만 만나는 형태), 커미티 등으로 정의할 수 있습니다.  어쨌거나 애자일에서 COE 팀과 같은 개념이 언급되는것도 재미있는 부분 같습니다. 시간 나시면 꼭 찾아보시기를 권장합니다.

 

제가 개발하고 커뮤니케이션을 하면서 가장 자주 쓰는 말이 있습니다. "Bring all into same page."

모든 참여한 사람들이 같은 컨셉과 같은 이해를 가지고 개발을 할 수 있도록 한다는 말입니다. 이의 중점은 커뮤니케이션이고 이 글에서는 그 방법중의 하나로 최소한의 문서를 이용한 커뮤니케이션 방법에 대해서 설명하였습니다

 

문서는 커뮤니케이션을 돕기 위한 하나의 도구입니다. 도구는 절대 목적이 되면 안됩니다. “문서는 단지 거들뿐..”



 

 

 

 

저작자 표시 비영리
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

프로젝트 인셉션에 대해서

ALM/애자일 | 2014.08.13 15:09 | Posted by 조대협


프로젝트 인셉션에 대해서 

원글 : http://www.infoq.com/articles/project-inception-meeting


프로젝트 시작전에, 프로젝트 팀에 대한 alignment를 하기가 어렵다.

alignment란 팀이 같은 프로젝트에 대한 배경과 목표를 이해하고, 주요 기능과 일정, 그리고 인원별 역할등 전체적인 프로젝트의 컨텍스를 이해하는 것인데,

일반 개발자들은 비지니스쪽 인원을 만나기 힘들 뿐만아니라, 상위 임원들의 방향과 생각을 중간 메니져를 통해서 듣기 때문에, 내용 전달이 부족하거나 오역 되었을때, 팀의 alignment가 제대로 되지 않는 경우가 많다.

이런 문제를 해결하기 위해서, 하루 full day로 프로젝트 시작하기 전에 공유하는 회의를 갖는데 이를 프로젝트 inception meeting이라고 한다. 미팅에서 얻고자 하는 것은 "Knowing what to build and where to start" 로 무엇을 만들것이고, 어디부터 시작할것인가를 공유하고 정의하는 것을 목표로한다.



※ Kick off 미팅과 유사하다.


미팅에서는 

  • 프로젝트에 대한 개요
  • 비전과 목표
  • 위험요소
  • 주요 인원과 역할에 대한 소개
  • 프로세스
  • 주요 기능 스토리
  • 소요 자원(시간)
  • 우선순위
  • 회고

등의 순서로 진행된다.


원글에서 인셉션의 목적과, 이유,누가 어떻게 언제 진행해야 하는지등이 잘 정리 되어 있어서 꼭 한번 참고해볼만하다.



저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

github 연동 방식 메모

ALM/SCM/VCS | 2014.01.12 12:35 | Posted by 조대협
  • github에 remote repository를 생성한후에
  • local에서 git init으로 현재 디렉토리를 git 디렉토리로 만든후
  • 현재 변경된 내용을 git commit으로 local에 저장하고
  • git remote add origin master https://github.com/bwcho75/JavaScriptTraining.git 를 해서, 현재 디렉토리를 github의 디렉토리와 연결한후
  • git push를 통해서 remote로 밀어넣으면 됨

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'ALM > SCM/VCS' 카테고리의 다른 글

github 연동 방식 메모  (0) 2014.01.12
git 사용법과 소스 관리  (5) 2013.07.28
Git branch reference  (0) 2013.06.25
git 기본 command  (0) 2013.06.24
VCS 브렌치 관리 전략  (0) 2013.05.27
git 노트  (0) 2013.05.27

SOAPUI로 유명한 SmartBear의 ALM 툴들

ALM | 2013.12.31 01:35 | Posted by 조대협

SOAPUI로 유명한 SmartBear(http://smartbear.com가 얼마전에 LoadUI라는 부하 테스트 툴을 내놓더니

요즘들어 보니 정말 많은 툴들을 내놓고 있다.


Selenium과 같은 웹 테스트 자동화 툴인 TestComplete

- 웹뿐 아니라 테스트 탑 및 Flash까지 테스트가 가능하다.


Requirement 관리, 애자일 Sprint관리, Test Case관리 까지 가능한 ALMComplete

JIRA + GreenHopper + TestLink 이런 느낌?


코드리뷰 툴에서 부터, 자동 빌드 툴 그리고 시스템 모니터링 툴까지 갖추고 있다.

Atlassian과 비슷한 느낌?


Atlassian이 자유도가 높은 형태라면, SmartBear는 딱 프로세스가 잡혀진 느낌 각각의 장단점은 있겠으나..

둘다 쓸만한 툴인듯.



저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'ALM' 카테고리의 다른 글

SOAPUI로 유명한 SmartBear의 ALM 툴들  (0) 2013.12.31
Vagrant를 이용한 개발환경 관리(간단한 VM관리)  (1) 2013.10.24
Docker 소개  (5) 2013.10.22
관심가는 ALM툴  (2) 2009.08.18
Oracle ALM 솔루션  (0) 2009.07.24
ALM 에서 각 기능들은 필수인가?  (2) 2009.07.03

TestLink를 이용한 Test Case 관리

조대협 (http://bcho.tistory.com)


테스트 케이스가 어떻게 요구 사항에 맵핑이 되는지, 테스트 케이스의 시나리오는 어떻게 되고 요구 되는 결과 (Expected Result)는 어떻게 되는지, 테스트 결과는 어떻게 되는지, 그리고 Version 별 릴리즈에 따른 테스트 계획과 결과는 어떻게 되는지를 관리할 수 있는 도구가 필요하다.

 대부분 테스트 엔지니어나 개발팀들이 위의 테스트 도구 자체에는 관심이 많은 것 처럼 보이지만, 정작 테스트 프로세스나 테스트 케이스 전체를 관리하기 위한 관리도구에는 그다지 집중하지 않는 것 처럼 보인다. 테스트 케이스 자체를 구현하는 것도 중요하지만, 전체 시스템에 대해 어떻게 테스트를 하고, 테스트에 대한 내용을 어떻게 관리할 것인가도 상당히 중요한 일이라고 본다.

그렇다고 거창하고 복잡한 프로세스가 필요하다는 이야기가 아니라 최소한의 테스트 조직에서 테스트 케이스에 대한 관리를 할 수 있는 툴이 필요하다는 것이다.

조금 쉽게 설명하면 테스트 케이스를 액셀로 만들어서 그 액셀 문서를 여러 사람이 나눠서 테스트를 진행하고 결과를 기입하던 절차를 자동화 했다고 생각하면 된다.

Test Link

오픈소스 도구중에서 널리 사용되고, Learning Curve가 낮은 도구중의 하나가 TestLink 라는 도구이다. http://testlink.org/

먼저 TestLink에서 사용되는 개념에 대해서 먼저 알아보자



Test Project

테스트 프로젝트는 테스트를 수행하는 프로젝트 자체를 이야기 한다. 블로그 서비스를 만들었을때 블로그 서비스 프로젝트”; 와 같은 단일 테스트 프로젝트로도 만들 수 있고, 내지는 블로그 서비스 모바일 클라이언트 테스트”, “블로그 서비스 웹 서비스 테스트와 같이 하나의 서비스에 대해서도 특성에 따라서 여러가지 프로젝트로 분할해서 테스트를 진행할 수 있다. 분할의 기준은 자유롭지만, 테스트 팀 단위로 분할 하는 것이 관리에 용이하다. (클라이언트 테스트 팀, 웹 테스트 팀 또는 미국 테스트 팀, 한국 테스트팀 등)

Test Specification

Test Spec은 테스트를 진행하고자 하는 테스트 케이스들의 집합이다.

Test Spec Test Suite, Test Case로 나뉘어져 있는데, Test Suite은 대분류, Teste Suite의 소분류의 테스트 케이스라고 보면 된다.

흥미로운 점중의 하나는 TestLink에서는 이 Test Case에 대한 버전 관리가 가능하다는 것이다. 예를 들어, “로그인이라는 Test Case, 예전에는 Facebook 계정을 이용한 로그인만을 테스트하는 케이스였는데, 향후에, 케이스가 추가 되서, Google 계정 로그인도 지원한다면, Test Case의 버전을 새로운 버전으로 정의할 수 있다.

Test Plan

테스트 플랜은 실제 진행하는 테스트를 의미한다. Test Project내에서, 테스트 대상 시스템의 특정 버전을 테스트 하기 위해서 Test Spec내의 Test Suite/Case를 모아 놓은 것을 Test Plan이라고 한다. Test Spec이 전체 테스트 케이스의 집합이라면, Test Plan에서는 실제로 이번에 테스트 할 Test Suite/Case들을 모아 놓은 subset이다. Test Plan Test Case를 맵핑할때, 실제 어느 Test Engineer가 테스트를 진행할지 Test Engineer assign할 수 있다.

Test Execution

Test Plan을 세웠으면, 실제로 각 Test Engineer가 자기에게 할당된 테스트를 수행하고, 테스트 결과 Pass/Fail 여부를 체크한다. 만약에 실패한 케이스일 경우에는 재 테스트를 하는데, 그 간 Minor Release가 되었을 경우에는 Minor Release 버전으로 테스트를 다시 해서 Pass 여부를 결정한다.

Test Report

마지막으로, 테스트 결과를 리포팅한다. 테스트 실패,성공 여부, 주요 Test Category (TestSuite)별 성공 실패 여부등을 리포팅 한다.

Test Link 사용 예제

그러면 이 흐름에 따라서 Test Link에서 실제로 어떻게 Test를 수행하는지를 알아보자. 먼저 TestLink를 인스톨하고

1.     Test Project 생성

먼저 Create New Project에서 테스트 프로젝트를 생성한다.

프로젝트 명과, 테스트 케이스에 적용할 prefix를 정의한다.



몇가지 옵션들이 있는데, TestLink BugZilla,Mantis,JIRA와 같은 버그 트랙킹 도구와 연동이 가능하다. “Issue Track Integration”을 선택하면, 버그 트랙킹도구를 연결할 수 있다. (별도의 Configuration이 필요하다.)

          • Ÿ   - Enable Requirement Feature : Requirement TestLink에 정의해서, Requirement à Test Case까지의 추적성을 부여할 수 있다.

          • Ÿ   - Enable Testing Priority : Test Case에 가중치를 부여할 수 있다.

          • Ÿ   - Enable Test Automation : 수동으로 테스트 하는 것이 아니라, Test Case SOAP UI Selenium과 같은 다른 테스트 도구를 연동하도록 설정할 수 있다. 

자 이제 테스트 프로젝트가 위의 그림처럼 생성되었다.


2.     Test Spec 작성

상단 메뉴에서 “Test Specification” 이라는 곳으로 들어가면 Test Suite/Case를 정의할 수 있다. 해당 메뉴로 들어가면 Test Suite/Case를 넣을 수 있는 화면이 나온다. 여기서 좌측 아래에 있는 트리를 선택한 후 오른쪽 버튼을 눌러서 Test Suite을 생성한다. Test Suite 이름과 간단하게, Test Suite에 대한 내용을 “Detail” 부분에 기술한다. 본인의 경우에는 이 Test Suite Scrum Epic 1:1 맵핑을 시키고, Epic에 있는 Description을 그대로 사용한다.

Test Suite Test Case의 집합으로, Test Case에 대한 대분류 정도로 생각하면 되고, 생성된 Test Suite들은 아래 그림과 같이 폴더 형태로 생성된다.


다음으로, 생성된 TestSuite (폴더)에서 오른쪽 버튼을 눌러서 Test Case를 생성한다.



Test Case는 개개별 테스트 시나리오로, 먼저 Summary 부분에 어떤 내용을 테스트 하는지 기술 하고, PreCondition을 입력한다. 예를 들어 Facebook 계정을 이용해서 로그인하는 시나리오를 테스트 한다면, Precondition사용자는 Facebook 계정을 가지고 있어야 한다.” 로 정의할 수 있다.

다음으로 구체적인 테스트 절차를 입력한다.

Step을 입력하는 버튼을 누르면, 아래와 같이 Step을 입력할 수 있는 부분이 나온다. 쉽게 이야기해서 테스트 절차가 된다. 각 단계별로 필요한 Action“Step actions”에 적어놓고, 우측에는 “Expected results”에 정상적으로 Action을 수행했을때 기대되는 결과를 기록한다.


위와 같이 Step by Step으로 action을 정의할 수 도 있지만 굳이 필요하지 않다면,아래 그립과 같이 하나의 action안에 전체 Step을 기술할 수 도 있다.



여기 까지 진행하면, Test Project Test 시나리오를 담은 Test Specification이 모두 완성되었다.


3.     Test Plan 작성

이제 실제로 테스트를 진행하기 위해서 Test Plan을 작성해보자. Home 메뉴에서 Test Plan Management를 선택한후에, 아래와 같이 Test Plan을 생성한다.



4.     Build Version 생성

다음으로 Test Plan내에서 사용할 Build Version을 정의한다.



처음에는 1.0과 같은 Major 버전을 정의하고, 개발팀에서 Minor 버전을 Release할때 마다 1.1, 1.2 식으로 Minor Version도 같이 생성한다. 그리고 각 버전에는 아래 그림과 같이 Release date를 선택해놓으면 관리하기가 편리하다.



5.     Test Suite/Case Test Plan Assign

이제 Test Plan Test Specification에 정의된 Test Case들을 맵핑해보자 메인화면에서 Test Plan Contents 라는 메뉴에서 “Add Remove Test Cases”를 선택한다.

아래와 같이 Test Case를 선택할 수 있는 창이 나오는데, 좌측 아래에서 Test Case를 골라서, 우측 상단에서 처럼 Test Engineer Test Taget Version을 선택한 후에, “Add Selected”를 선택하여, 테스트 케이스를 Test Engineer에게 할당한다.



이제 테스트 수행을 위한 준비가 다 되었다. 개별 Test Engineer에게 상세한 Test Scenario들이 모두 배정 되었다.


6.     Test Execution

이제 테스트를 수행하는데, Test Engineer들은 할당된 Test Spec Step action에 따라서 테스트를 수행하고, 성공/실패 여부를 아래 그림과 같이 선택한다.


위의 그림은 테스트가 성공했을때의 케이스이다. 만약에 Test가 실패하면, Failed라고 나타나는데, 이때 BUG management의 벌레 모양 버튼을 누르면 아래와 같이 버그 트랙킹 시스템에 등록된 버그 번호를 입력할 수 있다.



이렇게 버그 번호를 입력하면, Relevant bugs에 해당 버그에 대한 링크가 생성되고, 이 링크를 누르면, 해당 버그 트랙킹 시스템으로 이동한다. Relvant bugs 항목을 보면 이 Bug의 현재 처리 상태가 나온다. 위의 그림에서는 “Testing” 상태로 나타나는데, 이 상태는 버그 트랙킹 시스템의 상태를 그대로 출력해준다. Open이나 In Progress 처럼 개발자가 버그 수정을 하다가 수정이 끝나서 위의 그림처럼 “Testing”상태로 상태를 바꿔 놓으면, Test Engineer가 버그가 수정되었음을 인지하고, 버그 트랙킹 시스템에서 수정 결과와 버전을 확인한 후에, 그 버전(Minor 버전)을 선택하여 다시 Test를 수행한후 Pass/Fail 여부를 결정한다.

이 과정에서 TestLink와 버그 트랙킹 시스템간의 프로세스 연계가 중요하다.

테스트가 실패한 경우, Test engineer가 버그 트랙킹 시스템에 Bug를 등록해야 하고, Bug가 수정되면 개발자가 해당 Bug를 다시 Test Engineer에게 assign한후에, Test Engineer가 테스트를 확인하면, 버그 트랙킹 시스템에서 해당 Bug Close 처리하도록 하는 것이 권장되는 프로세스 이다.

Test Execution 시에, 1.0에서 발견된 버그라도 수정이 1.2 버전에서 수정되었다면, Test Execution에서 테스트 수행전에 “Build to Execute” 리스트박스에서 수정된 버전을 선택해서 테스트를 진행해줘야 한다.


7.     Reporting

테스트가 종료되었으면, 상단 메뉴의 “Test Reports”에서, 여러 형태의 테스트 리포트를 생성할 수 있다.



위의 그림은 Test Suite 별로 성공/실패 율과 전체 Test Case 수를 리포팅해주는 화면이다.

Test Link 향상된 기능

이외에도 Test Link는 앞에서 잠깐 언급한 바와 같이 Selenium,SOAPUI와 같은 테스트 도구 뿐만 아니라, JUnit과 같은 다양한 테스트 프레임웍 연동은 물론이거니와, Jenkins까지 같이 연계가 가능해진다.

기존에 테스트 도구만을 사용했을 때는 전체 테스트 현황이나 History, 상세한 테스트 케이스 특히 JUnit과 같은 코드가 아니라, Human readable한 형태로 테스트 케이스를 관리할 수 있게 해주며, 요구 사항에서 부터 Test Case 및 결과에 까지의 추적성을 보장해주기 때문에 매우 편리한 도구이다. Learning Curve도 상당히 낮은 도구이기 때문에 반드시 사용해보기를 권장한다.

그리고 누가 강조하지만, 도구는 도구일뿐이다. 어떻게 테스트팀의 구조를 잘 세팅하고, 프로세스를 잘 정의하느냐가 가장 중요한 항목이다.

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'ALM > Test Automation' 카테고리의 다른 글

TestLink를 이용한 Test Case 관리 자동화  (2) 2013.12.31
Selenium Test Suite 수행  (0) 2013.12.29
Selenium WebDriver와 RC 차이  (0) 2013.12.24
Selenium 테스트 메모  (0) 2013.12.24
테스트 팀의 조직 구조  (1) 2012.08.21
JUnit Max  (1) 2009.05.06

Selenium Test Suite 수행

ALM/Test Automation | 2013.12.29 01:50 | Posted by 조대협

Selenium IDE로 만든 Test Case는 Test Suite로 저장해서, command line 상에서 테스트를 수행할 수 있다.


먼저 작성했던, Test cae를 IDE에서 Test Suite로 저장한다.

다음 Command line에서 selenium server를 수행하여, Suite를 실행한다.

java -jar selenium-server-standalone-2.39.0.jar -multiwindow -htmlSuite "{브라우져종류}" "{테스트하고자하는URL}" "{테스트SUITE HTML 파일 경로-절대경로}" "{테스트 결과가 저장될 HTML 파일명"} 으로 수행하면 된다

이때 브라우져 종류는 *chrome으로하면 firefox가, *explorer로 하면, IE를 수행해서 테스트를 수행한다.


예) C:\dev\tools\selenium>java -jar selenium-server-standalone-2.39.0.jar -multiwindow -htmlSuite "*chrome" "http://www.naver.com" "c:\dev\tools\selenium\naver_selenium_sample_suite" "C:\dev\tools\selenium\result.html"


아래는 테스트 결과 생성된 리포트 이다.




저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'ALM > Test Automation' 카테고리의 다른 글

TestLink를 이용한 Test Case 관리 자동화  (2) 2013.12.31
Selenium Test Suite 수행  (0) 2013.12.29
Selenium WebDriver와 RC 차이  (0) 2013.12.24
Selenium 테스트 메모  (0) 2013.12.24
테스트 팀의 조직 구조  (1) 2012.08.21
JUnit Max  (1) 2009.05.06

Selenium WebDriver와 RC 차이

ALM/Test Automation | 2013.12.24 00:20 | Posted by 조대협

How Does WebDriver ‘Drive’ the Browser Compared to Selenium-RC?

Selenium-WebDriver makes direct calls to the browser using each browser’s native support for automation. How these direct calls are made, and the features they support depends on the browser you are using. Information on each ‘browser driver’ is provided later in this chapter.

For those familiar with Selenium-RC, this is quite different from what you are used to. Selenium-RC worked the same way for each supported browser. It ‘injected’ javascript functions into the browser when the browser was loaded and then used its javascript to drive the AUT within the browser. WebDriver does not use this technique. Again, it drives the browser directly using the browser’s built in support for automation


출처 : http://docs.seleniumhq.org/docs/03_webdriver.jsp


저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'ALM > Test Automation' 카테고리의 다른 글

TestLink를 이용한 Test Case 관리 자동화  (2) 2013.12.31
Selenium Test Suite 수행  (0) 2013.12.29
Selenium WebDriver와 RC 차이  (0) 2013.12.24
Selenium 테스트 메모  (0) 2013.12.24
테스트 팀의 조직 구조  (1) 2012.08.21
JUnit Max  (1) 2009.05.06

Selenium 테스트 메모

ALM/Test Automation | 2013.12.24 00:11 | Posted by 조대협

Firefox selenium IDE를 이용하여 Record 가능. 간단하게 IDE내에서 Command 추가등도 가능

아래는 네이버에서 "조대협" 으로 검색하여, 검색 결과에 "조대협의 블로그" 문자열이 나오면 성공하는 테스트 케이스 




작성 완료후 Export하면

Java/JUnit 3,4 , Test NG

Ruby,Python,C# 등으로 TG Export 가능


아래는 JUnit4로 Export한 소스 코드

package com.example.tests;


import com.thoughtworks.selenium.*;

import org.junit.After;

import org.junit.Before;

import org.junit.Test;

import static org.junit.Assert.*;

import java.util.regex.Pattern;


public class selenium_TC_naver {

private Selenium selenium;


@Before

public void setUp() throws Exception {

selenium = new DefaultSelenium("localhost", 4444, "*chrome", "http://www.naver.com/");

selenium.start();

}


@Test

public void testSelenium_TC_naver() throws Exception {

selenium.open("/");

selenium.click("id=query");

selenium.type("id=query", "조대협");

selenium.click("id=search_btn");

selenium.waitForPageToLoad("30000");

assertTrue(selenium.isTextPresent("조대협의 블로그"));

}


@After

public void tearDown() throws Exception {

selenium.stop();

}

}

다음은 Junit 4/Web Driver용으로 Export한 소스
package com.example.tests;

import java.util.regex.Pattern;
import java.util.concurrent.TimeUnit;
import org.junit.*;
import static org.junit.Assert.*;
import static org.hamcrest.CoreMatchers.*;
import org.openqa.selenium.*;
import org.openqa.selenium.firefox.FirefoxDriver;
import org.openqa.selenium.support.ui.Select;

public class SeleniumTCNaverWebdriver {
  private WebDriver driver;
  private String baseUrl;
  private boolean acceptNextAlert = true;
  private StringBuffer verificationErrors = new StringBuffer();

  @Before
  public void setUp() throws Exception {
    driver = new FirefoxDriver();
    baseUrl = "http://www.naver.com/";
    driver.manage().timeouts().implicitlyWait(30, TimeUnit.SECONDS);
  }

  @Test
  public void testSeleniumTCNaverWebdriver() throws Exception {
    driver.get(baseUrl + "/");
    driver.findElement(By.id("query")).click();
    driver.findElement(By.id("query")).clear();
    driver.findElement(By.id("query")).sendKeys("조대협");
    driver.findElement(By.id("search_btn")).click();
    // Warning: assertTextPresent may require manual changes
    assertTrue(driver.findElement(By.cssSelector("BODY")).getText().matches("^[\\s\\S]*조대협의 블로그[\\s\\S]*$"));
  }

  @After
  public void tearDown() throws Exception {
    driver.quit();
    String verificationErrorString = verificationErrors.toString();
    if (!"".equals(verificationErrorString)) {
      fail(verificationErrorString);
    }
  }

  private boolean isElementPresent(By by) {
    try {
      driver.findElement(by);
      return true;
    } catch (NoSuchElementException e) {
      return false;
    }
  }

  private boolean isAlertPresent() {
    try {
      driver.switchTo().alert();
      return true;
    } catch (NoAlertPresentException e) {
      return false;
    }
  }

  private String closeAlertAndGetItsText() {
    try {
      Alert alert = driver.switchTo().alert();
      String alertText = alert.getText();
      if (acceptNextAlert) {
        alert.accept();
      } else {
        alert.dismiss();
      }
      return alertText;
    } finally {
      acceptNextAlert = true;
    }
  }
}


저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'ALM > Test Automation' 카테고리의 다른 글

Selenium Test Suite 수행  (0) 2013.12.29
Selenium WebDriver와 RC 차이  (0) 2013.12.24
Selenium 테스트 메모  (0) 2013.12.24
테스트 팀의 조직 구조  (1) 2012.08.21
JUnit Max  (1) 2009.05.06
Software Testing Proces  (0) 2009.04.09

왠만큼 바쁘더라도 새로운 것을 공부하거나, 기존에 해왔던 기술들이 어느정도 성숙했다고 느끼면 꼭 글을 써서 블로그에 정리하고는 했는데, 이번달에는 정말 바뻤나 봅니다. 12월인데, 포스팅한 글이 하나도 없네요. 안되겠다 싶어서, 예전부터 프로젝트 사용에 주로 사용하던 jira에 대한 글을 몇일간 정리해서 올립니다. 좀 길기는 하지만 jira를 이용하는 사람들에게 도움이 될거라 생각합니다.




JIRA에 대한 소개

http://bcho.tistory.com

조대협

Atlassian jira는 버그 트랙킹 시스템에서 시작해서, issueIssue 기반의 전체적인 프로젝트 관리를 할 수 있게 하는 툴이다. 클라우드를 이용한 호스팅 서비스와, 설치형 서비스 양쪽을 모두 지원하며, 10 사용자의 경우 설치형의 경우 10$를 지불하면 라이센스를 받을 수 있고, 호스팅형의 경우 매달 10$ 정도면 서비스를 사용할 수 있다. 100 사용자 라이센스를 구매하더라도 4,000$ 밖에 되지 않는다. 다른 상용 프로젝트 관리 시스템과 비교해보면 상당히 저렴한 가격임에도 불구하고, 실제 사용해보면 그 기능과 편의성에 놀라지 않을 수 없다. Jira에 대한 선전성글로 보일 수 있겠지만, 선전을 해줘도 될만큼 훌륭한 제품이고 가격또한 적절하다. 이외에도 소스코드 관리나 CI를 위한 자동빌드 툴, 팀 채팅 서비스,코드리뷰 도구등 개발에 필요한 많은 도구들을 제공하고 있다. 아직까지 써보지 않았다면 꼭 둘러보기를 바란다.

그러면 jira로 어떻게 프로젝트를 관리할 수 있을까? 먼저 가상의 서비스를 생각해보고 시나리오를 정의해보자.


가상의 프로젝트

Facebook Server Side Architecture (이하 SSAG) 그룹을 별도의 웹사이트에서 운영할 수 있게 하는 사이트를 개발한다고 해보자 이 사이트를 통해서 해당 그룹의 멤버들은 글을 읽을 수 도 있고, 올리거나, 삭제 편집 그리고 검색을 할 수 있다. 이 서비스의 이름을 Yurry라고 하자


주요 기능

먼저 서비스의 주요 기능을 정의하고 액셀로 먼저 정리를 해보자

바로 Jira에 등록하지 않고 먼저 액셀로 정리를 하는 이유는, 기능을 정의하고 나면, 빠진 것이 많을 수 도 있고, 요구사항이 잘못 기술 되었을 수 도 있기 때문에, 먼저 액셀로 만들어 놓고 다른 팀원 (특히 개발,기획,UX)들과 함께 리뷰하면서 수정하기 위함이다. 아래는 초기 버전정도의 기능 정의서로 생각하면 되고, 개발이나 기획 그리고 UX 사람들과 몇번의 리뷰를 거치면서 조금더 상세화 되어야 한다.



이때, 두 단계 정도로 나눠서 Feature를 기술 하는데, Feature Level 1의 경우에는 일반적으로 생각할 수 있는 기능으로 보면 된다. (누구나 이해할 수 있는 레벨) 통상 20개 정도가 적절하다. Feature Level 2는 상세 기능을 정의하는데, 이때는 Scrum Story 기술 방법을 사용한다

“as a {user}, I want to do {something}”

의 형태를 취하는데, 어떠한 사용자가 시스템을 통해서 어떠한 기능을 한다는 것을 서술하는 것으로, 마치 UML Use Case와 같은 개념을 내포하고 있다.

기타 자세한 사항은 Description에 서술한다.

이런 Feature list를 정의할 때 중요한것은 크게 3가지 정도로 들 수 있다.

- Story (Flow or sequence) : 먼저 가장 중요한 것은 전체적인 Feature가 스토리 형태로 흐름을 가져야 한다. Level 1 Feature들을 순서대로 이어 놓으면 사용자가 서비스를 사용하는 흐름 형태가 되어야 한다. 예를 들어 위의 경우 사용자 로그인 > 글 읽기 > {글쓰기 | 좋아요 선택하기 | 검색하기} 와 같이 흐름이 되어야 한다. 위의 예에서는 Level 2 Feature는 나열식이 되기는 하였지만 조금 더 디테일한 경우에는 마찬가지로 순서성을 지키면 이해하기가 편하다.
나중에 이 Feature들을 리뷰 할때, 위에서 부터 Feature를 순서대로 리뷰를 하면 사용자 스토리에 따라서 리뷰를 하기 때문에 조금 더 빠짐없이 리뷰가 가능하다.

- Testable : Feature는 테스팅이 가능한 수준으로 디테일하게 서술되어야 한다.앞서 설명한 바와 같이, 스토리대로 각 기능등이 정의 되어 있으면, 스토리를 따라서 테스트 케이스로 만들 수 있다

- Designable : 마친가지로 디자이너가 기능에 있는 스토리에 따라서 UX를 만들 수 있는 정도로 충분히 기술되어야 하며, 특히 입력이나 출력을 받을 수 있는 필드가 충분히 기술되어야 한다.


UX Prototyping

다음으로, UX에 대한 프로토타입을 구현한다. 필수과정은 아니지만, 기능을 명확하게 하고 빠진 부분이 없는지 흐름이 잘못된곳은 없는지를 체크하기 위해서 UX 프로토타입을 구현해보는 것이 좋다. 이러한 UX 프로토타입을 wireframe이라고 한다.

다음은 balsamiq라는 프로토타입 디자인 도구이다.



Figure 1.http://balsamiq.com/ 의 프로토타입 툴

http://mashable.com/2012/06/07/mockup-tools/ 에 보면 몇가지 유용한 프로토타입 툴들이 소개 되어 있다.

또는 UX 자바스크립트를 사용할 예정인 경우 예를 들어, Bootstrap등을 이용할 경우에는 자바스크립트 디자인 툴을 사용해서 프로토타입을 만들어보는 것도 좋다 이 경우에는 만들어진 프로토타입을 거의 구현단계에 그대로 사용할 수 있기 때문에 구현 기간을 줄일 수 있다. 복잡한 UX가 아닌 경우에는 이러한 방법도 효과적이다.

다음은 layoutit이라는 bootstrap 디자인 도구 이다.



Figure 2. Layoutit 서비스 화면

http://mashable.com/2013/10/20/bootstrap-editors/ 를 보면 bootstrap 디자인툴이 소개되어 있다. 아래는 실제로 layoutit 도구를 사용하여 Yurry 서비스를 프로토타입핑을 한 예이다.




여기까지 진행됬으면 Feature list가 어느정도 필터링되고 다음어져서 완성이 되었을 것이다.


jira agile board

자아 준비가 끝났으면 이제 jira feature들을 등록해보자. Feature를 등록하기 전에 jiraagile board에 대해서 알아볼 필요가 있다.

스크럼 애자일 방법론을 보면 스크럼 보드라는 것이 소개되는데, 해야할일 (To do 또는 Backlog), 진행중인 일 (in progress), 완료된 일 (Complete)로 나눠서, 각 일(Issue)를 포스트잇으로 만든 후, 진행 단계에 따라서 각 단계로 포스트잇을 이동해서 붙이는 방법이다.




[1]

Figure 3. 스크럼 보드

이런 스크럼 보드를 웹으로 만들어 놓은 것이 jira agile board라는 기능이다. 이 기능을 사용하면 같은 장소에 있는 팀원 뿐만 아니라 원격지에 있는 팀원까지 같이 스크럼 보드를 공유할 수 있는 장점을 가지며, 각 해야할 일(Issue)에 대해서 디테일한 내용을 description에 서술함으로써 조금 더 자세한 Issue 관리가 가능하다.


[2]

Figure 4. jira agile 보드.

jira의 상단 메뉴에서 Project > Create Project 메뉴를 이용해서 프로젝트를 생성한다.



다음으로, 상단 메뉴의 Agile 메뉴에서 Mange board를 이용하여 Agile 보드를 생성한다. 여기서는 Scrum 방법론을 사용할 것이기 때문에, Scrum board를 선택하고 프로젝트를 선택한다.



여기까지 수행하였으면, agile board가 생성되었다.




Issue 종류

자 그럼 이제 앞서 정의한 Feature들을 jira agile 보드에 입력하기전에. Issue를 입력할때, 어떤 필드들을 입력해야 하는지 먼저 알아보자.

Jira에 입력되는 해야할일 feature들을 “Issue”라고 정의하는데, Issue에는 몇가지 타입이 있다.

    Epic

하나의 Sprint에 걸쳐서 끝나지 않고, 여러 Sprint에 걸쳐서 종료되며, 여러 Story들의 집합이다. 주로 Major Feature들을 중심으로 정의한다. Level 1 Feature가 적절하다.

Epic을 정의할때, 하나의 팁중의 하나는 꼭 User Story 단위로만 할것이 아니라, 사용자가 직접적으로 관계가 없는 일에 대해서도 정의할 필요가 있는데, 예를 들어, Infrastructure Set up이나, 디자인 작업,문서 작업등이 이에 해당한다.

    Story

“as a {user}, I want to {do something}”에 해당하는 사용자 직접적으로 사용하는 기능이다. 이 때 Story Point라는 것을 입력할 수 있는데, Story Point는 개발에 걸리는 시간 또는 난이도 등으로 지정할 수 있는데, 필자의 경우에는 “1=개발자 한명이 개발할 수 있는 분량으로 정의하고, 0.5,1,2,3.. 등의 단위를 사용한다.

    Chore

Chore는 개발을 해야 하는 부분이지만 사용자와 직접적으로 관계되지 않는 개발 내용을 정의한다. 예를 들어 “Server Logging 구현”, “데이타 베이스 분리와 같은 작업등을 정의한다. Chore 역시 Story와 마찬가지고 Story Point를 부여할 수 있다.

    Task (Optional)

Task는 해야하는 일이지만, 구현에 관련되지 않으며, 일정이 없는 경우에 해당한다. 예를 들어 디자인 문서 작성, 기획과 업무 협의 등이 해당한다.

    Issue

Issue 는 말 그대로 Issue이다. 메니져들이 관리하는 Issue, 예를 들어서 클라우드 계약, 서버 Hang up, 솔루션 결정 들과 같이 메니져들이 관리해야 하는 항목이다.

    Bug

버그는 테스트 엔지니어에 의해서 테스팅 되고, 버그로 리포팅 된 타입이다.

    Sub Task

Sub Task가 중요한 내용인데, Story Chore를 개발하기 위해서는 여러 가지의 실제적인 개발 작업이 필요하다. 예를 들어 “as a user, I want to read posting”이라는 Story가 있을때, “OPEN API를 호출하여 최근글을 JSON으로 호출하여 출력한다.” “API 호출을 로깅한다와 같이 디테일한 개발 테스크로 나뉘어 지는데, 이를 Story Chore같은 Issue 아래 Child (Sub) Task로 등록할 수 있다.

이때 하나의 팁은 이 Sub Task는 각 개별 개발자에게 할당되며 0.5~2일 정도에 끝날 수 있는 테스크로 정의되어야 하며, 만약 2일 이상이 될 경우 다른 Sub Task로 나누어 주는 것이 좋다.

여기서 주의할점은 Story Chore과 실제 개발해야 하는 Issue이고 Story Point를 부여할 수 있으며, 테스트 엔지니어에 의해서 테스팅이 되는 부분이다.

jira는 자유도가 매우 높은 도구라서 이러한 Issue Type등을 지정할 수 있다. 아래는 jira Project > Administration 메뉴에서 Issue Type을 정의하는 부분이다. 위에서 설명한 Issue Type들에 맞춰서 Customize 하였다.




Epic 등록

Issue 타입에 대해서 이해를 했으면 이제 먼저 Epic을 등록해보자. 앞에서 등록한 Feature Level 1 Issue Epic으로 등록하면 좋다.  먼저 agile board Plan 모드(우측 상단에 모드가 있음)에서 Create Epic을 눌러서 아래와 같이 Epic을 등록한다.



여기서 한가지 주목할만한 점은 원래 Feature List에 있던 페이스 북 연동” Epic에 등록되지 않고 새롭게 “Infrastructure”라는 Epic이 등록되었다. “페이스북 연동이라는 Feature는 요구 사항이기는 하지만 다른 기능 개발에 전제사항으로 포함되는 기능이기 때문에 별도로 Epic으로 등록하지 않았으며 대신 개발과정에서 서버,데이타 베이스 셋업, 배포 환경 자동화와 같은 인프라 작업이 생길 수 가 있는데, 이러한 작업은 Feature List에는 정의되어 있지 않았기 때문에, Epic 정의 단계에서 새롭게 정의하였다.


Issue 등록 및 맵핑

다음으로 Issue (Story,Chore,Issue,Issue)등을 등록한다. 상단 메뉴의 Issues 메뉴의 Create Issue를 이용하면 된다. 만약에 등록해야 할 Issue가 많을 경우에는 Excel Import할 수 있다.

https://confluence.atlassian.com/display/JIRA/Importing+Data+from+CSV 를 보면 Excel CSV로 바꿔서 Import 하는 방법이 설명되어 있다.

이 때 몇 가지 필수 필드를 등록해야 한다.


1)   Component

Component는 시스템의 컴포넌트를 정의한다. Yurry 시스템의 구조가 서비스를 제공하는 앞단의 서비스 웹 사이트(Service Web Site), 시스템을 배포하는(Deployment System)으로 구성이 되어 있다면 Component Service Web Site Deployment System 두개로 구성된다. 이러한 컴포넌트 설계는 Feature가 다 정의된 후 아키텍쳐 설계를 거쳐서 시스템을 구성하는 컴포넌트를 정의한 후에 이 컴포넌트를 Component로 사용하면 좋다.

Component는 상단 메뉴의 Projects > 해당 프로젝트 선택 > Administration 메뉴 > Components 메뉴에서 추가할 수 있다.




2)   Priority

다음으로 Priority인데, 해당 Issue가 얼마나 중요한지를 나타내는 것으로 Blocker, Critical, Major, Minor, Trivial 식으로 나뉘어 진다. 일반적으로 Major를 선택하면 되고,

       Blocker의 경우 해결되지 않으면 프로젝트가 진행될 수 없는 경우

       Critical은 프로젝트 진행은 가능하나 해결하지 않으면 정상적인 서비스 개발이 어려운 경우

       Major 꼭 개발해야 하는 경우

       Minor 개발은 해야 하나 없어도 상관 없는 경우

       Trivial 있으나 없으나 크게 상관 없는 경우

 

식으로 중요도를 나눌 수 있다. 프로젝트에 따라서 의미를 정의해서 사용하면 되고, Blocker의 경우에는 공통적으로 프로젝트 진행을 할 수 없는 수준으로 사용하면 된다.




3)   Issue 생성

이제 실제로 Issue를 생성해보자 상단 메뉴의 Issues > Create Issue 메뉴를 이용항 Issue를 등록한다. Summary 부분에 제목을 등록하고, 알맞은 Priority를 선택한 후, Issue에 해당하는 Component를 선택한다. 다음으로 Assignee 부분에 해당 Issue에 대한 Owner를 지정한다. 그리고 마지막으로 Description 부분에 앞의 Excel Sheet에서 만든 Detail Description을 채워 넣는다.




4)   Epic 맵핑

이제 모든 Story를 등록하였으면, agile board가 다음과 같은 형태가 될것이다.



EPCIS에서 맨아래 “Issues without epcis”를 클릭하면 우측 하단에 EPIC이 맵핑되지 않은 Issue들이 리스트업된다. Issue들을 drag & drop해서 좌측에 표시된 EPIC과 맵핑 시킨다.

    만약에 Issue를 등록했음에도 agile 보드의 back log에서 보이지 않는 경우 https://answers.atlassian.com/questions/102966/no-issues-displaying-in-scrum-backlog 를 참고하기 바란다.


Release Version 정의와 맵핑

릴리즈의 개념을 먼저 이해하자, 릴리즈는 작동 가능한 서비스 가능한 상태로 만드는 것이다. 정확하게 이야기 하면 Production 서비스로 올리는 것을 릴리즈라고 한다. 요즘의 애자일 방법에서는 Short Release라는 전략을 사용하는데, 아주 짧은 주기로 서비스나 소프트웨어를 릴리즈한다. 그렇다고 릴리즈마다 매번 Production에 배포 하는 것이 아니라 서비스로 배포가 가능한 형태로 만들거나, 어느 정도의 기능등이 마무리 되었을 때 릴리즈를 한다.

보통 이상적인 경우 매 Sprint가 끝날 때 마다 Release 되는 것이 좋지만, 하나의 Sprint 내에서도 긴급 Release가 될 수 도 있고 (버그 수정, 긴급 반영등) 또는 개발하는 기능이 클 경우 여러 Sprint에 걸쳐서 Release를 할 수 도 있다.



어떠한 기능을 언제 Release 할것인가를 정의하는 것을 “Release Planning” 이라고 한다. jira에서는 이러한 release의 개념을 지원하는데, 애자일 보다 좌측에 “Version”이라는 탭을 클릭하면 아래와 같이 출력된다.



여기서 “Create Version” 이라는 버튼을 누르면 Version을 생성할 수 있고, 이 때 해당 버전을 개발하는 기간 “From-To” 을 명시 할 수 있다

이렇게 버전 정보를 생성한후, 아래 그림과 같이 agile board에서 Issue들을 drag&drop하여release 버전에 맵핑할 수 있다. 개발 목표 완료일을 맵핑할 수 있다.즉 어떤 기능들이 어느 Release 버전에 포함될 것인가를 맵핑할 수 있다는 것이다. 이는 product 관리 관점에서 매우 중요한데, 1.0에서는 어느기능까지 지원하고 2.0에서는 어느 기능 까지 지원하겠다는 것을 명시적으로 지정하는 것이다. 이러한 release 계획에 따라 테스팅, 마케팅, 영업등 다른 조직이 함께 움직인다.

 




Sprint Planning

여기까지 진행했으면, Story 들이 어떤 기능 개발에 (EPIC)에 맵핑이 되는지 그룹핑이 되었고, 각 기능들이 어느 버전에 (언제) 완료될지가 맵핑 되었다. 그러면 이제 각 Story들을 개발하는데, 얼마의 노력(resource / time)이 필요한지를 측정해보자.


1)   스토리 포인트 부여

앞에서 이미 Story Chore에 대해서 설명하면서 스토리 포인트의 개념에 대해서 설명하였다. 여기서 이 단계에서 스토리 포인트를 부여하는데, BackLog에 있는 Issue를 클릭하면 오른쪽에 “Estimate” 라는 항목이 나온다. 여기에서 스토리 포인트를 부여하면 된다.




2)   Sprint 생성 및 Issue 맵핑

이제 Backlog가 완성되었다. 이제 Sprint를 생성하고 Backlog에 있는 Issue들 중에, 이번 Sprint에 진행할 Issue들을 맵핑해보자.

아래 그림 처럼 애자일 스크럼 보드에서 “Create Sprint”를 선택하면 Sprint가 생성된다. 이때 Sprint 이름에 기간 “(Dec.16~Dec.27)”과 같은 식으로 지정해놓으면 기간을 파악하는데 도움이 된다.



다음으로 Backlog에 있는 Issue들을 drag&drop으로 Sprint로 이동하여 Sprint로 에 맵핑한다.

그 후에 팀원들이 모여서 해당 Store Chore들을 구현하는데 필요한 Sub Task들이 있으면 정의 한다. (Issue에서 More > Create SubTask 메뉴를 사용하면 된다.)



다음으로 해당 Issue SubTask를 수행할 사람을 Assign 메뉴를 이용하여 개발자에게 할당한다.



이작업이 끝나면 해당 Sprint에 할당된 Story Chore (Story Point들이 있는 Issue)에 대한 스토리포인트의 Sprint Issue들 아래 “Estimate”로 나타난다. 이를 통해서 해당 Sprint에서 처리할 Story Chore들의 양이 적절한지 판단할 수 있다. 위의 그림의 경우 총 Estimate 7, 한사람이 working day 기준 1주반 정도면 구현 가능한 양이다. 만약 팀이 4명 정도고, Sprint 10일이라면 40정도가 MAX가 된다. 버퍼를 20~30%로 생각하면, 28~30 정도의 스토리포인트가 적절하다고 볼 수 있다. 이 버퍼는 팀의 업무 스타일에 따라서 유동적으로 설정한다. Sprint를 대략 3번 정도 해보면 어느정도의 버퍼가 필요한지 산정할 수 있다.


Sprint 시작

이제 Sprint 계획도 다 끝났고, 드디어 Sprint를 시작할 준비가 되었다. 애자일 스크럼 보드/Plan 메뉴에서 “Start Sprint” 버튼을 누르면 Sprint가 시작된다.

Sprint가 시작되면 agile board에서 Work 메뉴를 들어가 보면 변화가 생긴 것을 볼 수 있다.



앞에서 설명한 포스트잇 기반의 스크럼 보드 처럼 TO DO/In Progress/Done 형태로 3개의 영역으로 나뉘어 지고, 모든 Issue들은 TO DO에 위치한다. Sub Task(그림에서 YU-21) 의 경우 위의 그림과 같이 YU-12와 같은 Story Chore등 다른 Issue 아래에 다른 색으로 표시된다.


Sprint 진행

Issue 처리


1)   Issue의 상태 업데이트

지정된 담당자는 Issue에 대한 작업을 시작했으면, 작업의 상태를 “To Do”에서 “In Progress”로 변경한다. agile board / Work 모드에서 해당 Issue drag & drop을 이용하여 In Progress로 옮기거나 Issue 디테일에 들어가서 “Start Progress” (사용하는 워크 플로우에 따라 다를 수 있음) 을 눌러서 상태를 바꿔 준다.



마찬가지로, In Progress에서 작업이 끝나면 Done (또는 Close. 사용하는 워크플로우에 따라 다름)을 눌러서, 상태를 옮겨준다.


2)   Comment를 이용한 진행 상태 추가

Jira에 각 Issue에는 comment를 달 수 있는 기능이 있는데, 해당 Issue를 해결하는 데 필요한 내용이나 다른 사람과 커뮤니케이션한 내용(이메일/전화/메신져) 내용들을 붙인다.

이유는, 해당 Issue를 해당하는데 담당자가 무슨일을 했는지에 대한 로그를 남기는 것이다. 향후 다른 사람이 해당 업무를 받거나 또는 비슷한 문제를 해결하고자 할 때 선임자가 어떤식으로 업무를 해결했는지를 찾아볼 수 있도록 하는 것이다.

기술적인 질문을 하는 경우에도 이메일 보다는 Comment에 내용을 달아놓고, 질문을 하고자 하는 사람에게 Issue assign 시켜서 jira를 통해서 커뮤니케이션을 하면 별도로 이메일 내용을 jira에 붙일 필요가 없이 커뮤니케이션이 가능하다. (Comment가 붙으면, watching하는 사람이나 또는 assign된 사람,owner에게 자동으로 이메일 notification이 간다.)

경험상 코드 수정이나 기능에 대한 comment 내용들은 대단히 도움이 되는데, comment를 자세히 적도록 팀의 문화를 바꾸는 것은 대단한 노력이 필요하다. 필자의 경우에는 미국계 미들웨어 회사에서 일을 할 때, enhancement bug 수정에 대한 communication에 대해서 본사 개발자가 jira와 유사한 Issue 트랙킹 도구를 통해서만 communication을 하도록 프로세스가 잡혀있었다. 그래서 자연히 접하게 되었는데, 향후에 비슷한 문제가 생겼을 때 Issue 트랙킹 도구만 검색해도 유사한 문제와 현상 그리고 해결 방법을 다른 사람들의 커뮤니케이션 쓰레드를 통해서 많은 힌트를 경험이 있다. (실제로 다른 사람들도 그렇게 사용하였다.)

이런 경험 때문에 컨설팅을 할때나 또는 실제 개발에 적용할 때 이런 문화를 적용하고자 노력을 많이 했었는데, 엔지니어적인 특성들 때문인지 보고서처럼 몬가 적고 기록하는데 익숙하지 않은 탓인지 적응이 상당히 힘들었던 경험이 많다. (소스코드에 주석 많이 안다는 것과 같은 원리)

Issue comment를 적을 때에는, “내가 휴가를 가더라도 다른 사람이 Issue에 기록된 Comment만 보고도 업무를 인수받을 수 있는 정도의 수준적어 주는 정도의 디테일로 기록하는 것이 좋다.


3)   Resolve 처리

처리가 끝난 Issue“Done” 처리 할 때 사용중인 워크플로우에 따라서, “Resolution” 을 수동으로 입력해줘야 하는 경우가 있다. “Resolution”을 명시적으로 Complete나 다른 완료 상태로 바꿔 주지 않고, Unresolved 상태로 놔두게 되면 jira에서 해당 task를 제대로 끝나지 않은 상태로 인식하는 경우가 있다.

Jira 에는 팀이 가지고 있는 전체 Issue 대비 끝난 Issue를 추적하는 기능이 있다. 이 기능을 이용하면 전체 프로젝트 팀의 진행 상태를 알 수 있다.



그림과 같이 위의 붉은색 그래프가 열려 있는 Issue 이고, 아래 초록색이 해결한 Issue의 수이다. 이 해결한 Issue는 상태를 “In Progressà Resolved(Testing)”으로 변환할대 초록색으로 변하게 되는데, 이때 반드시 Resolution을 선택해주지 않으면 아래 초록색 그래프에 반영되지 않는다. 앞서 설명했듯이 워크플로우에 따라 Done이나 Resolve를 선택하면 자동으로 Resolution이 선택되는 경우가 있는데, 만약 현재 사용하는 워크플로우가 자동으로 Resolution을 선택해주지 않는 경우 이렇게 반드시 설정해줘야 한다.





여기서 Resolution을 선택해주지 않으면 Resolved 또는 Close가 되었다 하더라도, 실제 시스템에서는 해결하지 않은 것으로 인식해서 “Resolved”카운터가 증가하지 않는다. (위의 그래프에서 녹색 그래프가 올라가지 않는다.)

그리고 ResolveIssue Agile 보드에서 아래와 같이 Issue #에 선이 그어진 상태로 표시된다



만약에 현재 Resolved 처리하거나 Close 처리한 Issue중에서 위와 같이 Issue #에 줄이 쳐져 있지 않다면, 반드시 Resolution을 확인하고, UnResolved 상태로 되어 있다면, 해당 Issue Reopen 하신후, 다시 Resolve하고 이때 반드시 Resolution을 입력해줘야 한다.


4)   워크 플로우

Jira의 가장 큰 특징 중의 하나가 상당히 많은 부분에 대해서 Customization이 가능하다는 것이다. 그 중에서 강력한 기능중의 하나가 워크 플로우 기능이다. 지금까지 설명한 프로세스는 To do/In progress/Closed와 같은 일반적인 스크럼 기반의 워크 플로우지만, bug feature, test case와 같은 Issue 타입에 따라서 워크 플로우가 다를 수 있다. jira에서는 이렇게 각각 다른 Issue 타입에 대해서 다른 워크 플로우를 정의 및 정의할 수 있도록 지원한다.




5)    Version Control System 연동을 이용한 Issue(Task)별 코드 변경 추적

Jira Issue들 즉 Story Chore를 개발 내용이 어느 소스코드에 반영되었는지 까지 추적할 수 있는 기능을 제공한다. SVN이나 git commit을 할 때 해당 Issue #를 넣어서 Commit을 하게 되면 아래와 같이 해당 Issue에 관련된 소스코드 변경 부분을 jira에서 링크로 해서 직접 코드 변경(또는 반영) 부분을 보여준다.

설정 방법

https://confluence.atlassian.com/display/JIRA/Integrating+with+a+Source+Control+System


[3]

특히 버그 수정을 했을 때, 버그 수정을 위해서 어떤 부분을 변경했는지를 추적할 수 있기 때문에 대단히 편리하다. 이 기능이 유용하기는 하지만, 개발한 코드를 commit할 때 마다 Issue 번호를 넣는 건 습관화 되지 않으면 상당히 귀찮은 일이다. Issue Comment를 부지런히 남기는 것처럼, 코드 commit시 마다, Issue #를 넣도록 습관을 변경하는 것이 중요하다.

이런 방식으로 Issue를 진행 및 해결하면서 Sprint를 진행한다. 만약에 중간 중간에 필요한 Issue Task가 나오게 되면 추가를 하고 앞서 진행한 방식과 같은 방법으로  Sprint에 추가하여 진행하되, Sub Task들은 Story Chore를 구현하기 위한 것이기 때문에, Sprint에 추가하는 것이 것이 타당하지만, 새로운 Story Chore등은 Planning때 정의한 것이 아니기 때문에 추가 요구 사항이 된다. 처음 Planning 당시 팀의 사이즈에 맞는 분량의 양만 정했기 때문에, 마구잡이로 현재 진행중인 Sprint에 넣게 되면, 야근(?)이 발생하게 된다.

그렇다고 딱 StoryChore Freeze해서 무조건 한다는 것은 맞지 않을 수 있다. 초기에 Sprint 설계시 요구사항 분석을 잘못했을 가능성이 있기 때문에 빠진 Story Chore가 있을 수 있다.

일단 Sprint 진행중, 새로운 Story Chore가 생긴다면 넣고 빼는 것에 상관 없이 생성해서 BackLog에 넣어 놓는다. 그리고 꼭 먼저 진행해야 하는 경우 현재 Sprint에 넣고, 현재 Sprint에 포함된 다른 덜 중요한 내용을 빼내서 다시 Backlog로 내려놓는 방법이 타당하다.

그렇다고 부담없이 넣다 뺐다 하라는 것이 아니라, 꼭 필요한 경우에만 융통성을 발휘해서 유동적으로 진행을 하라는 것이다. 만약 Sprint에 들어가 있는 Story Chore를 자주 변경하게 되면 전체 팀의 프로젝트 진행에 있어서 혼선을 줄 수 있고 특히나 여러 지역에 분산된 팀의 경우에는 여파가 크다.


6)    몇가지 팁

agile board / Plan 모드에서 상단의 sprint 제목 우측을 보면, 아래와 같이 To do / In progress / Done 상태별 Issue들의 Story Point 들을 합산해서 보여준다. 이 값을 보면 현재 Sprint를 진행하면서 해야할일, 하고 있는 일, 끝난 일의 비중을 쉽게 알 수 있다.



agile board / Plan 모드에서 진행중인 Sprint Issue들과 Backlog Issue들은 drag&drop을 이용해서 순서 조정이 가능하다. 중요한 Issue들을 위로 놓아서 관리하는 것이 편리하다.



agile board 상단을 보면 Quick Filter가 있는데, 이는 Configure 메뉴를 이용하여 Customization이 가능하다. Filter를 잘 정의해 놓으면 검색이나 진행 중인 Issue들을 필터린 해서 보는데 매우 편리하다.



일반적으로 특정 Component , 이슈별, 사람별 Filter를 미리 정의해놓고 사용하면 편리하다.


Sprint 종료

이렇게 Issue들을 진행하고 Sprint가 끝나는 기간이 되면 해당 Sprint를 종료해야 한다. Sprint를 종료하는 방법은 agile board > Work에서 좌측 상단의 Sprint 명을 클릭하면 아래와 같이 Complete Sprint라는 버튼이 나타나고 이 버튼을 누르면 해당 Sprint가 종료된다.



이때 종료되지 않은 Issue들은 다시 모두 Backlog로 내려가게된다.


새로운 Sprint 시작

다음 새로운 Sprint를 바로 시작할 수 있는데 권장 사항은 이 시기에 스크럼 회고(Retrospective)를 진행하면서 지난 Sprint에서 잘한 것, 못한것 그리고 개선해야 할 것을 논의하면서 프로세스를 개선해나가는 것이 좋다.

경험상 팀장급 (Scrum이나 애자일에서는 Chicken이라고들 부르던데.)은 빠진 자리에서 회고를 하는 것이 좋다. 일반 개발자나 팀원들이 눈치를 보느냐고 제대로 된 토론이 이루지지 않을 수 있기 때문이다. 반드시 프로세스 개선을 위한 의견들을 논의하고 다음번에 반영하는 것이 좋다. 또는 회고중에 나온 내용을 간단히 메모해서 이메일로 Chicken에게 보내서 향후 개선을 요청할 수도 있다.

Chicken들도, 회고에는 Chicken 끼리의 자체적인 회고를 하면서 자체적인 개선 작업을 수행하는 것이 좋다.

회고가 끝난후에, 앞서 진행했던 Sprint Planning 작업부터 다시 수행한다.


Jira의 확장


Dashboard

Jira Home 화면을 개인별 또는 프로젝트별로 dashboard를 구성할 수 있다. 여기서 여러가지 현황을 볼 수 있도록 만들 수 있는데, 몇가지 추천할만한 항목으로는

    사용자별 Issue 할당 현황 : 팀원별로 할당된 Issue의 수를 모니터링 하면, 어느 팀원에게 일이 몰리는지를 알 수 있고, 이를 바탕으로 적절하게 Issue를 분산해서 배치할 수 있다.

    Block,Critical,Major 이슈 개수 : Blocker Critical 이슈들은 프로젝트를 진행하는 데 문제가 될 수 있으므로 항상 모니터링 하는 것이 좋다.

    Created vs Resolved Graph : 이슈가 생성되는 추이 vs Resolve되는 추이인데, Sprint 끝으로 갈 수 록 Resolved Graph가 생성되는 그래프를 쫓아 가야 한다. 팀의 Velocity를 측정할 수 있는 부분으로, 만약에 생성되는 그래프가 올라가는 속도가 Resolved 속도 보다 빠르게 증가한다면 해당 Sprint내에 일을 끝낼 수 없다는 의미이고 Resolved Graph가 완만하게 증가하고, Created Graph가 증가 속도가 둔화되면 프로젝트가 제대로 되고 있다는 의미가 된다.

    나에게 할당된 이슈 : 당연히 나한테 할당된 이슈는 모니터링되고 봐야 하고.

    내가 Watching하고 있는 이슈 : 또한 내가 Watcher List에 들어가 있는 이슈도 모니터링 되어야 한다.

    다른 프로젝트의 Progress : 몇 개의 프로젝트를 동시에 진행하는 PM의 경우에는 여러개의 프로젝트에 대한 progress를 모니터링 하는 것이 좋다.



Figure 5. jira dashboard 예제

[4]

jira에서 dashboard gadget등을 이용해서 얼마던지 Customization이 가능하다. 별도의 규칙은 없고 각 업무에 맞게 잘 만들어서 사용하면 되는데, 참고할만한 팁은, Dashboard를 만들 때 팀내의 역할에 따라서 다른 형태의 Dashboard를 만들어서 사용하면 효과적이다. PM의 경우 여러 개여 프로젝트의 Progress Issue에 대해서 집중적으로 관리가 필요할 것이고, 개발자의 경우에는 자기에게 할당된 Issue, 자신이 Watching하는 Issue들을 집중적으로 관리할 필요가 있다. 운영팀의 Incident dash board에 장애 이력을 장애가 발생한 시스템의 분포도, 장애의 원인 분포도 (네트워크 에러, 사람 실수, 설정 오류), 달력으로 장애 발생 횟수를 표시 하는 등을 할 수 있다.


모바일 클라이언트

아무래도 시대가 모바일 & 스마트폰 시대이다 보니, 당연히 jira도 스마트폰용 애플리케이션이 있다. 단순하게 스마트폰에서 이슈를 보거나 Comment를 다는 정도로 생각할 수 있겠지만, 생각보다 재미있는 기능들이 많다.


[5]

그림에서 가운데 처럼 채팅 형태로 Comment를 달 수 있는 기능도 있고, Issue를 등록했을 때 맨 오른쪽 그림처럼 이슈가 등록된 위치는 구글 맵을 통해서 나타내 줄 수 도 있다.

당연히 기본적인 리스트를 보여주는 기능도 제공한다. 외부이동이 많은 세일즈 엔지니어나 컨설턴트 또는 장애 처리를 해야 하는 Operation 엔지니어들에 매우 편리하다. 특히 채팅 기능의 경우 SMS와 같이 문자를 받는 형태로 Comment를 붙일 수 있기 때문에 이메일로 Notification을 받는 것 보다 훨씬 빠르게 해당 issue에 대한 Communication이 가능하다.


Add ons

Jira는 다양한 확장 플러그인을 제공한다. https://marketplace.atlassian.com/ 에 가면 유/무료 플러그인을 구매하여 jira를 확장할 수 있다. 또는 jira admin 메뉴에서 add on을 검색해서 자동으로 다운로드 및 설치를 하게할 수 있다. (정말 쉽다.)


[6]

Figure 6. Tempo Timesheets for JIRA 플러그인

위의 그림처럼 우리가 이 장의 앞에서 소개한 Excel 기반의 Tracking 시스템 형태로 jira를 운영하는 플러그인이나 Gantt chart 플러그인등 다양한 플러그인 조합을 통해서 팀의 스타일에 맞는 형태의 jira Customization이 가능하다.


정리

필자의 경우 애자일 팀을 운영하면서 IBM Jazz, Mantis,Bugzilla Trac, Redmine 등 많은 툴을 사용해봤는데, jira가 저렴한 가격대에 정말 실용적인 기능들을 많이 제공한다.

적절한 수준의 복잡도와 Customization을 통한 유연성을 제공하는데, 무엇보다 중요한 것은 툴  보다는 프로세스이다. 어떤 개발 프로세스를 정립하고 팀이 적응하느냐가 문제이지 어떤 툴을 사용하느냐는 그 다음 문제이다.

흔히 이런형태의 툴을 도입하는 과정을 보면 도입하는 당사자만 재미있어 하고, 구축에만 힘을 쏟다가 정작 팀 전체의 프로세스를 바꾸고 적용하는데 실패하는 경우를 많이 봤다.

툴을 구축하는 것보다 단순한 프로세스로 먼저 팀 전체가 움직일 수 있도록 적용하고, 다음 점점 툴과 프로세스를 고도화해 나가는 것을 고려해보자. 본인의 경험상 툴 셋업과 프로세스 정의가 끝난후 최소한 2~3개월은 지속적으로 노력해야 팀에 적용이 된다. 그 전까지 Issue를 제대로 close하지 않거나 내용을 제대로 적지 않거나 등의 여러가지 프로세스를 따르지 않는 경우가 많이 발생한다. 그래서 초기 2~3개월 동안은 Scrum Master Issue들을 관리하면서 일일이 개인들에게 mentoring을 하면서 프로세스를 따르도록 해야 한다.

 


저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'ALM > JIRA' 카테고리의 다른 글

Atlassian JIRA를 이용한 애자일 Scrum 프로젝트 관리  (12) 2013.12.20
JIRA 클라이언트  (0) 2008.11.07
Atlassian JIRA를 이용한 프로젝트 관리 (기초편)  (0) 2008.04.04
JIRA와 SVN 연동  (1) 2008.03.03

Vagrant를 이용한 개발환경 관리(간단한 VM관리)

ALM | 2013.10.24 00:48 | Posted by 조대협

Vagrant

시작하기

Vagrant는 한마디로 이야기 하면, “간소화된, VM 관리 서비스이다”. 이미 Virtual Machine 환경은 보편화 되서 사용되고 있고, VMWare Oracle Virtual Box등을 이용하면 PC에서도 손쉽게 VM 환경을 구축할 수 있다. 그러나 문제점은, Virtual Box와 같은 Hypervisor가 있다고 해도, VM을 생성하는 것 자체가 번거로운 작업이라는 것이다.

 Hypervisor에서 논리적인 가상 하드웨어 머신을 생성하고 가상머신에 OS를 설치하고, 일일이 설정을 해줘야 한다. 이런 반복적인 작업을 조금더 손쉽게 자동화 할 수 없을까? 하는 아이디어에서 시작한 것이 Vagrant이다.

먼저 이해를 돕기 위해서 예제를 실행해보자.

Vagrant VM 관리도구 이기 때문에, 먼저 Hypervisor 부터 인스톨을 해야 한다.

https://www.virtualbox.org/ 에서 Virtual Box를 다운로드 받아서 설치하자.

다음으로 http://www.vagrantup.com/ 에서 vagrant를 받아서 인스톨한다. 이제 준비가 끝났다.

아래와 같이 vagrant init precise32 http://files.vagrantup.com/precise32.box 를 실행하면, Ubuntu Linux VM의 실행하기 위한 설정들을 자동으로 가지고 온다. 그리고 vagrant up 명령어를 실행하면 해당 설정에 따른 VM 을 자동으로 다운받아서 설치하고 Virtual Box를 통해서 해당 VM을 기동 시킨다. Putty를 이용하여 SSH localhost:2222 번으로 접속 (id:vagrant, passwd:vagrant)를 입력하면, 생성된 VM에 로그인할 수 있다. 또는 간단하게 “vagrant ssh”라고 실행하면, 현재 생성된 VM에 자동으로 SSH로 연결된다.



Vagrant 없이 Virtual Box에서 직접 Ubuntu VM을 설치하려면 VM을 만들고, Ubuntu OS를 설치해야 한다. 그러나 Vagrant가 있으면 이렇게 간단하게 두줄의 명령어로 VM을 만들고 실행시킬 수 있다.

Box 개념 이해하기

앞에서 vagrant init 명령을 실행할때, preceise32.box라는 파일을 지정하였다. box 파일은 VM을 만들기 위한 기본 OS 이미지를 포함한 VM 설정(CPU,메모리 사이즈등)에 대한 기본 템플릿이다. (사이즈가 보통 수백 메가가 나간다.)

http://www.vagrantbox.es/ 에 보면 공개된 box 파일들이 있다. Ubuntu, Debian 등 다양한 Linux OS 버전의 VM 들에 대한 box 파일들이 있다.

Vagrant file

Vagrant init을 하면, 해당 디렉토리에 “Vagrantfile” 이라는 이름으로 생성되는 파일인데, Box VM 생성을 위한 기본 템플릿이라면, Vagrant file은 생성될 VM에 대한 세부 설정을 정의한다. VM을 생성할때, 어떤 box 파일을 사용할 것인지, VM에 대한 하드웨어 설정 예를 들어 CPU,메모리 사이즈,네트워크, 네트워크 포트포워딩 설정등을 여기서 재정의 할 수 있다.

아래는 Oracle Virtual Box실행시 preceise32 box 이미지를

http://files.vagrantup.com/precise32.box 에서 읽어와서, CPU 2, 512M를 가진 “Terry_vargrant0”이라는 VM을 생성하는 Vagrantfile이다. 아래와 같이 파일을 생성한후에, vagrant up 명령을 수행시키면 설정한 정보 대로 VM이 생성된다.

VAGRANTFILE_API_VERSION = "2"

 

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  config.vm.box = "precise32"

  config.vm.box_url = "http://files.vagrantup.com/precise32.box"

  # config.vm.network :forwarded_port, guest: 80, host: 8080

  # config.vm.network :private_network, ip: "192.168.33.10"

  # config.vm.network :public_network

  # config.ssh.forward_agent = true

  config.vm.provider "virtualbox" do |vm|

        vm.customize [

               "modifyvm",:id,

               "--memory","512",

               "--name","Terry_vagrant0",

               "--cpus","2",

                       ]

  end

end

 

Vagrant + Provisioning

Vagrant를 이용하면, VM을 쉽게 만들 수 있다. 그런데 개발환경을 구축하자면, OS가 인스톨된 VM 뿐만 아니라, 그위에 웹서버,DB등 미들웨어들을 설치해야 하고, 그리고 거기에 맞는 Configuration을 해야 한다. 물론 미리 VM 이미지에 웹서버등을 설치해놓고, 필요에 따라서 vagrant를 이용해서 해당 VM들을 설치해서 사용해야 하지만 그 경우에는 설정마다 매번 다른 VM이미지를 만들어놔야 하기 때문에 번거롭다. 만약에 OS 만 설치된 VM에다가, 설정에 따라서 소프트웨어와 설정을 하는 부분을 분리한다면?

이런 접근을 지원하는 기능이 Vagrant provisioning이라는 기능이 있다. VM을 기동한 후에, vagrantfile에 정의된 provisioning script를 수행해준다. 다음 예제를 보자. 다음 예제는 VM이 기동된 후에, apt-get 명령을 이용해서 apache2 (웹서버)를 자동으로 설치하는 설정이다.

VAGRANTFILE_API_VERSION = "2"

 

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  config.vm.box = "precise32"

  config.vm.box_url = "http://files.vagrantup.com/precise32.box"

config.vm.provision :shell, :inline => "sudo apt-get install -y apache2"

 

end

위의 예제는 VM이 기동될때 마다 shell 명령어를 수행하도록 한것인데, 명령어말고도 shell스크립트를 수행하게 할 수 도 있고, puppet이나 chef와 같은 configuration management 도구를 이용해서, 제품을 설치하게 할 수 도 있다.

한 가지 주의할점은 Vagrantfile provision 부분에 정의된 명령어는 vagrant up, reload, provision 3개의 명령어가 실행될때 마다 매번 실행된다. up에서도 매번 실행되기 때문에, 스크립트내에, 해당 소프트웨어가 미리 설치되었는지 확인한 후에, 설치가 안되어 있을 경우에만 설치하도록 스크립트를 짜는 것이 좋다.

Provisioning에 대한 자세한 방법은 http://docs.vagrantup.com/v2/provisioning/index.html 를 참고하면 된다.

Vagrant를 이용한 개발 환경 구축

그러면 Vagrant를 이용해서 개발환경을 어떻게 구축할 수 있는지 살펴보도록 하자



크게 그림과 같이 2개의 repository가 필요하다. Box image repository에는 기본 이미지가 인스톨된 box image들을 저장해놓는다.

그리고 svn이나 git와 같은 VCS 툴에 vagrantfile을 저장해놓는다. (아니면 간단하게 웹서버에 저장해놔도 된다.) Vagrantfile에는 box 파일들을 저장해놓은 repository pointing 하도록 하고, 필요에 따라서

1.  Ubuntu + Apache

2.  Ubuntu + MySQL

3.  Ubuntu + Tomcat

와 같이 다양한 설정을 만들어 놓고, 필요에 따라서 Vagrantfile이 받은 후에, 간단하게 “vagrant up” 명령어만 수행하면 간단하게 개발환경에 필요한 VM을 만들어낼 수 있다.

지금까지 간략하게 Vagrant에 개념과 사용법에 대해서 알아보았다.Vagrant는 그외에도, Vagrant는 단일 VM 뿐만 아니라 multi vm을 단일 vagrantfile에서 설정이 가능하고, Oracle Virtual Box뿐만 아니라,VMWare Amazon EC2 클라우드 까지 지원한다. 간단하게는 개발환경에서 부터,응용하면, QA,스테이징,운영환경 배포용으로도 활용할 수 있다.

자세한 내용들은 http://docs.vagrantup.com/ 를 참고하기 바란다

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'ALM' 카테고리의 다른 글

SOAPUI로 유명한 SmartBear의 ALM 툴들  (0) 2013.12.31
Vagrant를 이용한 개발환경 관리(간단한 VM관리)  (1) 2013.10.24
Docker 소개  (5) 2013.10.22
관심가는 ALM툴  (2) 2009.08.18
Oracle ALM 솔루션  (0) 2009.07.24
ALM 에서 각 기능들은 필수인가?  (2) 2009.07.03

Docker 소개

ALM | 2013.10.22 01:23 | Posted by 조대협

Docker란 무엇인가?

개념 잡기

Docker Linux 기반의 Container RunTime 오픈소스이다. 처음 개념을 잡기가 조금 어려운데, Virtual Machine과 상당히 유사한 기능을 가지면서, Virtual Machine보다 훨씬 가벼운 형태로 배포가 가능하다. 정확한 이해를 돕기 위해서, VM Docker Container의 차이를 살펴보자.

아래는 VM 에 대한 컨셉이다. Host OS가 깔리고, 그 위에 Hypervisor (VMWare,KVM,Xen etc)가 깔린 후에, 그위에, Virtual Machine이 만들어진다. Virtual Machine은 일종의 x86 하드웨어를 가상화 한 것이라고 보면된다. 그래서 VM위에 다양한 종류의 Linux, Windows등의 OS를 설치할 수 있다.



DockerContainer 컨셉은 비슷하지만 약간 다르다. Docker VM 처럼 Docker Engine Host위에서 수행된다. 그리고, Container Linux 기반의 OS만 수행이 가능하다.

Docker VM처럼 Hardware를 가상화 해주는 것이 아니라, Guest OS (Container) Isolation해준다.무슨 말인가 하면, Container OS는 기본적으로 Linux OS만 지원하는데, Container 자체에는 Kernel등의 OS 이미지가 들어가 있지 않다. Kernel Host OS를 그대로 사용하되, Host OS Container OS의 다른 부분만 Container 내에 같이 Packing된다. 예를 들어 Host OS Ubuntu version X이고, Container OS CentOS version Y라고 했을때, Container에는 CentOS version Y full image가 들어가 있는 것이 아니라, Ubuntu version X CentOS version Y의 차이가 되는 부분만 패키징이 된다. Container 내에서 명령어를 수행하면 실제로는 Host OS에서 그 명령어가 수행된다. Host OS Process 공간을 공유한다.



실제로 Container에서 App을 수행하고 ps –ef 를 이용하여 process를 보면, “lxc”라는 이름으로 해당 App이 수행됨을 확인할 수 있다. 아래는 docker를 이용해서 container에서 bash 를 수행했을때는 ps 정보이다. lxc 프로세스로 bash 명령어가 수행되었음을 확인할 수 있다.

root      4641   954  0 15:07 pts/1    00:00:00 lxc-start -n 161c56b9284ffbad0477bd04875c4277be976e2032f3ffa35395950ea05f9bd6 -f /var/lib/docker/containers/161c56b9284ffbad0477bd04875c4277be976e2032f3ffa35395950ea05f9bd6/config.lxc -- /.dockerinit -g 172.17.42.1 -e TERM=xterm -e HOME=/ -e PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin -e container=lxc -e HOSTNAME=161c56b9284f -- /bin/bash

LXC (LinuX Container), 자세한 정보는 http://linuxcontainers.org/ 에서 얻을 수 있다.

lxc container를 실행시켜주는 runtime으로, 앞에서 설명한것과 같이 VM과 비슷한 기능을 제공하지만, 실제 수행에 있어서, guest os (container)를 마치 VM처럼 isolate해서 수행해주는 기능을 제공한다.

이와 같이 Docker LXC라는 Linux에 특화된 feature를 사용하기 때문에, 제약 사항을 가지고 있는데, 현재까지 Docker Ubuntu 12.04 이상(Host OS)에서만 사용이 가능하다.

Performance에 대해서는 당연히 Host OS에서 직접 application 을 돌리는 것보다 performance 감소가 있는데, 아래 표와 같이 performance 감소가 매우 적은 것을 볼 수 있다.



출처: http://www.slideshare.net/modestjude/dockerat-deview-2013

Repository 연계

다음으로 Docker의 특징중의 하나는 repository 연계이다.Container Image를 중앙의 Repository에 저장했다가, 다른 환경에서 가져다가 사용할 수 있다. 마치 git와 같은 VCS (Version Control System)과 같은 개념인데, 이를 통해서 Application들을 Container로 패키징해서 다른 환경으로 쉽게 옮길 수 있다는 이야기다.



예를 들어 local pc에서 mysql, apache, tomcat등을 각 컨테이너에 넣어서 개발을 한 후에, 테스트 환경등으로 옮길때, Container repository에 저장했다가 테스트환경에서 pulling(당겨서) 똑같은 테스트환경을 꾸밀 수 있다는 것이다. Container에는 모든 application과 설치 파일, 환경 설정 정보 등이 들어 있기 때문에, 손쉽게 패키징 및 설치가 가능하다는 장점을 가지고 있다.

여기서 고려해야할점은 Docker는 아쉽게도 아직까지 개발중이고, 정식 릴리즈 버전이 아니다. 그래서, 아직까지는 production(운영환경)에 배포를 권장하고 있지 않다. 단 개발환경에서는 모든 개발자가 동일한 개발환경을 사용할 수 있게 할 수 있고, 또한 VM 보다 가볍기 때문에, 개발환경을 세팅하는데 적절하다고 볼 수 있다.

Base Image vs Dockerfile

Docker Container Image packing하기 위해서, Docker Base Image Docker file이라는 두가지 컨셉을 이용한다. 쉽게 설명하면, Base Image는 기본적인 인스톨 이미지, Docker file은 기본적인 인스톨 이미지와 그 위에 추가로 설치되는 스크립트를 정의한다.

예를 들어 Base Image Ubuntu OS 이미지라면, Docker FileUbuntu OS + Apache, MySQL을 인스톨하는 스크립트라고 보면 된다. 일반적으로 Docker Base Image는 기본 OS 인스톨 이미지라고 보면 된다. 만약에 직접 Base Image를 만들고 싶으면  http://docs.docker.io/en/latest/use/baseimages/ 를 참고하면 된다. docker에서는 미리 prebuilt in image들을 제공하는데, https://index.docker.io/ 를 보면 public repository를 통해서 제공되는 이미지들을 확인할 수 있다. 아직까지는 Ubuntu 많이 공식적으로 제공되고, 일반 contributor들이 배포한 centos 등의 이미지들을 검색할 수 있다. (2013.10.22 현재 redhat 등의 이미지는 없다.)

아래는 docker file 샘플이다. (출처 : http://docs.docker.io/en/latest/use/builder/)

# Nginx

#

# VERSION               0.0.1

 

FROM      ubuntu

MAINTAINER Guillaume J. Charmes <guillaume@dotcloud.com>

 

# make sure the package repository is up to date

RUN echo "deb http://archive.ubuntu.com/ubuntu precise main universe" > /etc/apt/sources.list

RUN apt-get update

 

RUN apt-get install -y inotify-tools nginx apache2 openssh-server

위의 이미지는 Ubuntu OS 베이스 이미지에 apt-get을 이용해서, inotify-tools nginx apache2 openssh-serverf 를 인스톨하는 스크립트이다.

Docker 실행해보기

그럼 간단하게 docker를 테스트해보자, 윈도우즈 환경을 가정한다. 앞서 말한바와 같이 Docker Unbuntu 위에서만 작동한다. (참고 : http://docs.docker.io/en/latest/installation/windows/)

그래서, 윈도우즈 위에서 Ubuntu VM을 설치한후, Ubuntu VM에서 Docker를 실행할 것이다. 이를 위해서 VM을 수행하기 위한 환경을 설치한다.

l  Hypervisor Virtual Box를 설치한다. https://www.virtualbox.org 

l  VM을 실행하기 위한 vagrant를 설치한다. http://www.vagrantup.com 

l  Docker 코드를 다운받기 위해서 git 클라이언트를 설치한다. http://git-scm.com/downloads 

여기까지 설치했으면, docker를 실행하기 위한 준비가 되었다.

다음 명령어를 수행해서, docker 코드를 git hub에서 다운로드 받은 후에, vagrant를 이용해서 Ubuntu host os를 구동한다.

git clone https://github.com/dotcloud/docker.git

cd docker

vagrant up

Virtual Box를 확인해보면, Docker Host OS가 될 Ubuntu OS가 기동되었음을 확인할 수 있다.



그러면, 기동된 Ubuntu OS SSH를 이용해서 log in을 해보자. Putty를 이용해서 127.0.0.1:2222 포트로, SSH를 통해서 로그인한다. (기본 id,passwd vagrant/vagrant 이다.)

이제 Docker를 이용해서, public repository에서 “busybox”라는 Ubuntu OS Container로 설치하고, Container에서 “echo hello world” 명령어를 수행해보자

sudo su

docker run busybox echo hello world

Docker public repository에서 busybox image를 다운로드 받아서 설치하고, 아래와 같이 명령어를 수행했음을 확인할 수 있다.



※ 참고 : 현재 docker에 설치된 이미지 리스트 docker images, 설치된 이미지를 삭제할려면 docker rmi {image id}. {image id} docker images에서 hexa로 나온 id를 사용하면 된다.

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

'ALM' 카테고리의 다른 글

SOAPUI로 유명한 SmartBear의 ALM 툴들  (0) 2013.12.31
Vagrant를 이용한 개발환경 관리(간단한 VM관리)  (1) 2013.10.24
Docker 소개  (5) 2013.10.22
관심가는 ALM툴  (2) 2009.08.18
Oracle ALM 솔루션  (0) 2009.07.24
ALM 에서 각 기능들은 필수인가?  (2) 2009.07.03

Vagrant를 이용한 개발환경 자동화

ALM/배포(Deployment) | 2013.10.15 17:53 | Posted by 조대협

참고 : http://ppiazi.tistory.com/m/post/view/id/230



1. vagrant 다운받아서 설치

2. virtual box 다운 받아서 설치

3. 우분트 precise32 버전을 설치 : vagrant box add "precise32" http://files.vagrantup.com/precise32.box 

4. vagrant init precise32

다음 vagrant up 으로 vm 실행 (virtual box에서 보면 실행된게 보인다.)

5. putty ssh에서 localhost:2222로 접속

6. default id/passwd는 vagrant/vagrant


다음에는 chef연동해보기.


저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

maven nexus 설치

ALM/Build Automation (빌드 자동화) | 2013.09.05 23:47 | Posted by 조대협

Nexus 설치 및 Maven 연동

조대협

Nexus maven에서 사용할 수 있는 가장 널리 사용되는 무료 repository 중의 하나이다. www.sonatype.com 에서 다운로드 받아서 설치할 수 있다.

Local nexus를 설치하게 되면, 외부로 부터 dependency를 끌어 오는 수고를 덜고, local nexus proxy (cache)로 사용함으로써 빠르게 라이브러리들을 끌어 올 수 도 있고, 반대로 개발팀내에서 사용하는 공통 라이브러리들을 local nexus에 배포해서 팀간에 공유할 수 있다.

또한 사용자 계정 지정을 통해서 repository에 대한 접근 정책을 정의할 수 도 있다.

Nexus repository의 용도와 목적에 따라서 몇 가지로 나눌 수 있는데, 대표적으로 다음과 같은 종류 들이 있다.

   Snapshots : 빌드등 수시로 릴리즈 되는 바이너리를 배포 하는 장소

   Releases : 정식 릴리즈를 통해서 배포되는 바이너리를 저장하는 저장소

   3rd party : 벤더등에서 배포하는 (Oracle,IBM) 바이너리를 저장해놓는 장소로 특정 솔루션등을 사용할때, 딸려 오는 라이브러리등을 여기에 놓고 사용한다

   Proxy Repository : 원격에 원본 repository가 있는 경우, Local에 캐쉬 용도로 사용한다.

   Virtual Repository : Repository Group은 몇 개의 repository를 하나의 repository로 묶어서 단일 접근 URL을 제공한다.

 

여기서는 가장 널리 사용하는 local repository로 설정 하는 시나리오와 함께, 외부 repository에 대한 proxy 시나리오로 사용하는 설정을 소개한다.

설치

http://www.sonatype.com 에서 nexus 무료 버전을 다운로드 받아서 설치한다. 초기 디폴트 로그인 계정과 비밀번호는 "admin/admin123"이다.


  

Public Repositories라는 repository 그룹에 local repository (Releases Snapshots, 3rd party) proxy repository를 포함시킨다.




 

다음으로 Proxy Repository Remote Repository의 내용들에 대한 라이브러리 목록(Index) Local Caching할 수 있도록 되어 있다. 이렇게 하면, nexus proxy repository에 실제 바이너리가 내려와 있지 않더라도 목록이 미리 내려와 있기 때문에, nexus search 기능을 통해서 검색이 가능하다.

"Maven Central Repository" "Central" repository 에 설정을 해보자 "Central repository"를 선택한 후, 메뉴에서 "Download Remote Indexes" 라는 Option "True"로 변경한다. 다음 SAVE 버튼으로 저장한 후, 상단 테이블 메뉴에서 "Central" repository를 선택한 후 오른쪽 버튼을 눌러서 팝업 메뉴에서 "update index"를 실행하면, 원격 maven repository에서 라이브러리 목록을 읽어서 업데이트가 된다.

 



 

업데이트가 끝나면 "Browse Index" 메뉴에서 라이브러리 목록이 새롭게 업데이트 되어 있는 것을 확인할 수 있다.

 



Maven에서 local nexus Proxy (Cache) repository로 설정하기

Nexus 설정이 끝났으면 다음으로 maven nexus rmirroring repository 설정해보자.

$MAVEN_HOME/.m2/setting.xml

파일에서 <mirrors> section에 아래 내용을 추가하자

 

<mirror>

      <id>nexus</id>

      <mirrorOf>*</mirrorOf>

      <name>Local nexus repository.</name>

      <url>http://localhost:8081/nexus/content/groups/public/</url>

    </mirror>

  </mirrors>

 

설정이 끝난후, maven 빌드를 수행하면 maven script가 원격지가 아닌 local에 있는 nexus repository를 통해서 라이브러리를 다운로드 하는 것을 확인할 수 있다.

 



또한 nexus console을 통해서 "Browse Storage" 메뉴를 통해서 "Central" repository storage 를 보면 빌드에 사용되었던 모든 라이브러리들이 local nexus에 다운로드 받아져 있음을 확인할 수 있다.

 


 



저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License

nexus pro에 대한 고급 기능소개


조대협 (bwcho75@지메일)


nexus는 maven repository로 매우 유명한 솔루션이다. 오픈 소스 버전은 maven을 사용하는 경우에는 거의 필수적으로 사용이 된다고 해도 과언이 아니다.

nexus의 상용 버전인 nexus pro의 경우 CLM (Component Life-cycle Management) 개념을 도입하여, 접근제어나 컴포넌트에 대한 security 나 license risk등을 관리 통제할 수 있다.

이 글에서는 nexus pro에 대한 몇 가지 고급 기능에 대해서 살펴보고, 이를 통해서 컴포넌트(라이브러리)의 관리가 단순한 중앙 집중형 공유만이 아닌 일종의 life cycle 개념이 있다는 것을 이해하도록 해보자


 

Nexus의 상용 버전인 Pro 버전에는 단순한 공유나 maven repository cache 용도뿐만이 아니라 조금 더 복잡한 기능의 라이브러리 관리 기능을 제공한다. Nexus에서는 이러한 개념을 CLM (Component Life-cycle Management)이라고 하는데, 라이브러리에 대한 접근 제어나 정책 관리등이 이에 해당한다. 몇가지 대표적인 오픈소스 정책 관리 기능을 살펴보자.

근래에 소프트웨어 개발 패러다임은 오픈소스를 이용한 소프트웨어 개발이 많다. 많은 오픈 소스 라이브러리를 사용하게 되는데, 문제는 각 오픈소스 컴포넌트들의 라이센스 정책이 다르다는 것이다. GPL,Apache,MIT,BSD 등 여러가지 라이센스 정책이 있는데, 라이센스 정책에 따라서, 어떤 오픈 소스는 사용에는 제약이 없지만 배포시 소스코드를 변경해야 하거나, 유료로 비용을 지불해야 하는 경우도 있고, 2.0 버전에서는 멀쩡하게 아무 제약없이 사용할 수 있었던 컴포넌트들이 3.0 버전으로 업그레이드 되면서 제약이 생기는 경우가 있다. (오라클이 인수한 MySQL의 경우 제품에 번들해서 재 배포할 경우 일정의 비용을 지불해야 한다.)  이러한 이유 때문에, 오픈소스 컴포넌트에 대한 라이센스 체크는 점점 필수적인 요건이 되어가는데 문제는 하나의 서비스나 소프트웨어 제품을 개발하는데, 수백개 이상의 라이브러리가 사용된다는 것이고, 각 버전마다 일일이 라이센스를 체크한다는 것은 보통일이 아니다. Nexus는 이런 오픈소스 라이브러리 정책을 repository 차원에서 관리해준다.

오픈소스 라이센스 정책 관리

Nexus proxy repository를 선택하고, Analysis 라는 버튼을 누르면, 현재 repository에 저장되어 있는 오픈 소스에 대한 라이센스 정책을 분석하여 다음과 같이 보여준다. 이 라이센스 정책에 대한 DB nexus 판매사인 sonatype으로 부터 제공된다.



각 라이브러리가 어떤 라이센스 정책을 사용하는지, 그리고 각 라이센스 정책이 문제가 없는 지등을 찾아준다.

Security 체크

또한, 보안에 위험이 있는 라이브러리등을 찾아서 보안 위험도등을 표시해준다. 2013년 기준으로 struts2에 대해서 아주 큰 보안 위험이 발생된 일이 있었다. 이렇게 중앙의 repository에서 회사내에서 사용하는 라이브러리에 대한 보안 위험성을 감지해서 중앙에서 통제하게 되면, 개별 개발자에 대한 수고도 덜 수 있을 뿐더러, 보안 위험에 대해서 피해갈 수 있는 장점을 가질 수 있다.



이렇게 체크만 할뿐만 아니라, 이렇게 검출된 문제 있는 라이브러리들을 접근하지 못하게 막을 수 있다.

Procurement

nexus pro에는 “artifact procurement” 라는 기능이 있는데, 이 기능을 사용하면 proxy repository를 만들고, 여기에 속해 있는 라이브러리에 대해서 white list 또는 black list 방식으로 접근을 제어할 수 있다. 아래 그림은 asm-parent 라이브러리에 대해서 모두 접근을 제어 하는 설정을 적용한 예이다.



 

Staging

또 다른 재미 있는 기능중에 하나는 staging 개념을 지원한다는 것이다.

즉 개발자가 컴포넌트나 라이브러리를 개발하여 nexus에 배포하면 다른 개발자나 사용자들이 바로 그 라이브러리를 사용하게 하는 것이 아니라, 일종의 워크플로우를 통해서 릴리즈 절차가 끝나면 일발 개발자들이 사용할 수 있도록 프로세스를 조정할 수 있다.

이를 위해서 staging repository라는 개념을 제공하는데, 설명하자면 다음과 같다.



개발자가 컴포넌트를 개발하고, 개발이 끝나면 staging repository로 배포를 진행한다. 배포된 repository QA 그룹 엔지니어만 접근이 가능하다. QA 엔지니어는 컴포넌트를 받아서 테스트를 진행하고, 문제가 없으면, 해당 컴포넌트를 베타 테스트 단계로 넘긴다.

베타 테스트 단계에 있는 컴포넌트는 베타 테스트 사용자에게만 접근이 허용되며, 테스트가 끝나면 일반 repository로 이동되어 일반 개발자도 접근이 가능하게 해준다.

이 워크플로우에서 단계별로 넘어갈때, 각 단계 이동별로 정책을 정할 수 있다. 예를 들어 앞서 설명한 security level이 낮은 경우 reject을 하거나, open source 라이센스가 문제가 있는 경우에, reject을 하는 중의 policy를 정의할 수 있다

< 출처 : http://www.sonatype.com/take-a-tour/nexus-pro-tour-start >

저작자 표시
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
 

티스토리 툴바