Continuous Integration

ContinuousIntegration

4월 27일 박재성(NHN)님의 CI Seminar Summary 입니다.

ContinuousIntegration

• A 라는 기능 개발 하고 싶다 그러면 관련된 정보가 다 있음.
• 사용자 스토리
  • 분석 설계 개발 이 아니라 기능 단위로 개발을 완료 하는 것.
  • 기능단위로 개발하는 것.
  • 개발자가 한 문서만 보면 개발이 가능하도록 함.
• 정보의 단위를 기능별로 쪼갠것 싸이클을 짧게 가져감.
  • 바로 구현 바로 테스트 후 마일스톤을 종료하는 매커니즘..
• 하루에 일하는 시간이 4시간이 되도록 목표를 세우고 진행중.
• 어떤 기능을 개발해야 될지를 윗선에서 푸쉬하는 방식이었는데 그렇게 하지 않고 자기가 결정하여 진행
• Assign 된 티켓들 중 내가 하고 싶은 일을 땡겨와서 진행하는 방식으로 스케쥴링을 하고 있다.

• 우선순위 Assgin 후 Start -> work-> Resolve -> bug 시 재등록 -> 완료

• 42개의 기능을 개발하겠다고 해서 진행
• 추가 요구 분석 진행
• 요구 분석 완료 됬다는 것에 대해서 먼저 진행하는 형태 (효율적)
• 디자이너도 자신이 이것이 됬구나 확인하여 자신에게 task를 땡겨와서 진행.
• 개발자는 html 코딩 후 개발작업이 가능하므로 각각 진행
• 최종적으로 QA가 완료된 것들이 생기면 각각을 테스트 함.
• 상당히 유기적으로 진행된다.
  • 기능단위로 관리가 가능한데 포털이나 에이전시는 기능단위로 안된다 전체 를 봐야겠다는 예기 나옴.
  • 이 경우 화면단위로 task를 던졌는데 비효율적인 부분이 있었다.
• 계속된 결과물을 보면서 디자인도 욕심이 생기기 마련. 언제든지 디자인 수정해라. 개발자도 처음에 설계하지 마라

• 와꾸만 추출하고 개발 시작함. (설계 없이) -> 결과적으로 유연하고 빠른 산출물 도출이 가능했다.

• 원할 때 Test할 수 있는 환경의 구축으로 바로 테스트 할 수 있게 되어 빠른 개발이 가능했다.
• XPlanner, Rally(상용 -강추), trac, bugzilla
• 설계 없는 진행 (스토리 산정시) 처음에 도메인 선정만 함.
• 안에 속성 정의도 안함. 일반적으로 나온 부분 요구 분석이라던지.. 그런 것들의 관계 정도만 만들어서 시작.
• 칠판에 놓고 사진 찍고 개념정의 후 끝내고 로그인 기능이 필요하다 하면 그때 진행.
• 앞부분에 시간을 너무 많이 투자하면 아까워서라도 버리기가 어렵지만 확장의 개념을 가지면 더 쉽다.
• 기존은 앞부분에 너무 많은 결정으로 인해 예외의 사항이 올때 어려웠는데 이러한 것을 Task 단위로 가져감으로 더 빠른 진행이 되었다.
• 스토리 포인트 산정시의 기준은?
• 경험 별로 없더라도 의견을 내어서 주변이 고려해 주는 분위기를 만들어 가야함 (관계, 신뢰)
• 편한 의사 발언을 할 수 있는 분위기를 만들어 가야함.

통합 개발 환경

• Ant 를 이용하여 Project의 .setting(WTP)를 내려 받게 하여 Eclipse 환경을 통합 할 수 있다.
• maven의 sql 플러그인 기능 활용.하여 데이터 베이스를 로컬에 깔아서 구현.
  • Data 구조가 자주 바뀌기 때문. 언제든지 스키마 바꾸다가 문제 없이 되었을때 개발서버에 배포 하도록 함.
  • 빌드하면서 개발서버의 데이타베이스를 초기화 하도록 하였다.
  • Maven IDE, Q4E 백기선.
  • Maven의 Goal 이라는 개념.
  • pom.xml Maven의 설정 파일.
  • 프로젝트 dependancy 가 자동으로 적용된 eclipse.

  • document> settings 아래에서 함.

  • 라이브러리 많이 사용하는 곳에서는 maven의 dependancy 가 아주 유용하다.
  • 하나의 빌드 파일로 여러 군데의 설정파일 설정 가능
• Eclipse에서 Jira의 모든 기능 가능.
  • Task 만 잘 관리 되었다면 자동으로 Comment 도 달림.

지속적인 통합

• wattj
• teamcity
• 우리의 목표
  • 소스를 SVN에 올리면 가장 빠른 시간에 빌드가 완료 되어 가장 빠른 시간에 테스트 하는 것이 목표
  • 이렇게 가장 빠르게 결과를 보는 것은 개발자의 개발 흐름을 깨지 않는 장점이 있다.
• wattj 를 이용하여 테스트가 통과되고 난 후 build 까지 활용.
• 자바지기 svn에서 소스는 다 받을 수 있다.
• CI를 사용하면 단위 테스트를 더 잘 만들 수 있다.
• CI 에서 fail이 나면 1순위는 직전 Commit 한 사람이 해결하는 방법.
• 배포 디비 초기화 등등의 자동화 모두 CI에 접목하여 하라.
• 한번에 너무 많은 걸 하지 말고 조금씩..하라.
• 디비 날렸다가 생성하는거 하고 배포하는 것 하고 단계적으로 하라.
• 하나씩 하나씩 그리고 그 것의 장점이 뭔지 진행하고 유도하라.
• 프로젝트 시작 전에 이것을 기반으로 잡아야 한다.
• 프로젝트 시작전에 이런 기반을 만들어 놓으면 후에 몇배 더 쉬워진다.
• 지속적 통합을 할때는 자주 커밋하고(적어도 하루에 한번 이상)
• 단위 테스트만 성공하면 바로 커밋하고 깨진 테스트를 먼저 고치고 빌드 깨지만 일순위로 고친다.
• 단위 테스트 코드 만들어야 효과가 극대화 된다.
• 반드시 자동화 해야 한다. 항상 같은 결과가 나오는 환경을 만들어야 한다.

• 테스트와 inspection - c&p 한 코드나 코드 내부의 결함 내포시 검사하는 로직도 넣는다 (품질)

• (상용) Bamboo, Anthill
• (무료) hudson
• CI 가 매번 repoting 할 수 있다.

• Maven 의 site generate 를 이용.-> maven site가 만들어짐.

• Maven의 경우 플러그인 하나 설치 해 놓으면 플러그인 한줄로 다 jar 들 긁어와서 자동 테스트 가능
• 툴을 통해서 현재의 소스 코드의 test coverage 가 나온다 현재 목표는 80%인데 70% 유지 하고 있다.
• 이걸 통해 현재 어느곳에 테스트가 잘되는지 안되는지도 리포팅 가능

• CPD - 중복 되는 소스코드 검사. -> 리펙토링의 대상이 됨.

• FindBug - 널포인트 가능한 부분 등 소스의 어떤 에러가 있는지 어떤 문제가 생길 수 있는지 guidence 까지 해준다.

  • getmethod를 만들었는데 어떤 개발자가 getblogid 이렇게 나옴 이 둘중에 하나만 사용해라 라는 comment를 줌 독같은 역할을 하는 부분을 개선하도록 함.
• jdepend - 소스 코드의 복잡도 분석 cycle dependacy 가 없도록 함.
• 플러그인으로 다 있지만 하려면 부담이지만 밤마다 사이트에서 이런것들이 자동 리포팅을 해준다면 빌드 순간에 필드 fail 이 나는 것 처럼 연동이 가능하다.
  • 이로인해 빠른 피드백을 제공하여 좀더 빠른 수정이 가능하다.
• 자꾸 하다 보니 점진적으로 방법이 덧붙여지게 되고 있음 SVN의 Trunk Tag 등 발전 시켜 더 낳은 개발 환경을 구축하도록 함.
• wattj
  • 화면 테스트의 자동화가 가능 하다. (IE 만 가능)
• 셀레니움이라는 것도 있다. - 테이블에 값을 입력하여 테스트 코드를 만들 수 있다. (프로그래밍 몰라도 할 수 있다.)
• nhn이 엄청나게 많은 도메인이 엮여 있는데 크로스 브라우징을 해결하기 어려워서 시작했다.
• 시간 부분을 밖으로 빼서 Test를 용이 하게 할 수 있다.