Yonghwan's Blog

간판 시스템(kanban; 일본식 발음, 도요타에서 유래했다나? )은 말하자면 일종의 "상황판"같은 것이다. 소프트웨어 개발의 관점에서 말하자면, 넓은 판에 개발의 각 단계를 영역으로 구분하여 표시한 후(고정된 말판), 접착식 메모지 등에 적은 개발 요건(말)을 그 위에서 개발 진척도에 따라 이동시킴으로써 전반적인 개발 진척도를 한 눈에 파악할 수 있도록 한 것. 또는 그 이상이라고 말할 수 있겠다. 마치, 윷놀이 하듯 개발을 한다는 얘기다. :-)

Lean Software Engineering - Kanban

Kanban bootstrap | Lean Software Engineering

The goal of a kanban workflow system is to maximize the throughput of business-valued work orders into deployment. It achieves this by regulating the productivity of its component subprocesses.

Kanban systems for software development | Lean Software Engineering

The pipeline model shares a common problem with network model scheduling. Variation in product development activities is simply too hard to control. Pipelines and network models can be made to work by adding a lot of time padding, and indeed, we started to resort to Critical Chain methods to try to make the pipeline work.

프로젝트 관리 > 버전관리 > 서브버전 저장소 사본 만들기 (Repository Replication)

지금의 업무 환경이 마땅치 않아서 이기고 하고 또 한편으로는 작은 오픈소스 프로젝트를 열어보고자 하는 생각도 있고 하여, 요 얼마간 서브버전을 지원하는 공개 프로젝트 호스팅 서비스를 찾고 있었다. 실은 trac을 지원하는 무료 호스팅 서비스를 원했으나 적당한 것을 찾지 못했다. (도와주세요^[각주:1])

프로젝트 호스팅 서비스를 찾다보니 고민하게 되는 것이, 만약의 사태에 대한 대비 또는 써보니 서비스가 성에 차지 않는다든지 하여 이사하게 될 상황에 대한 대책 마련이다. (직접 운영하는 저장소는 단순히 저장소를 묶어 보관하는 것 만으로도 충분한 백업 또는 이전 대책이 서기 때문에 아직까지 이런 필요성을 느끼지는 않았었다.)

서브버전이 제공하는 기능 중에 저장소의 읽기 전용 사본을 만드는 기능이 있다. 기능의 본래 취지는 말 그대로 읽기 전용 사본을 만드는 것이지만 (대부분의 오픈소스 프로젝트를 보면, 커밋 권한을 가진 개발자에 비하여 엄청나게 많은 수의 사용자들이 읽기 전용 권한으로 소스를 받아가게 되는데, 이런 부하를 분산시킬 수 있는 또는 지역으로 미러링 할 수 있는 기능이 필요하다.) 이 기능이 나의 백업/이전 용도에도 적절히 사용될 수 있을 것 같다.

과정은 다음과 같다.

$ mkdir /svn-mirror
$ svnadmin create /svn-mirror/my-project
$ cd /svn-mirror/my-project/hooks
$ cp pre-revprop-change.tmpl pre-revprop-change
$ vi pre-revprop-change
$ chmod 755 pre-revprop-change
$ svnsync init file:///svn-mirror/my-project svn+ssh://repository/var/svn/my-project
sio4@repository's password: 
리비전 0의 복사된 속성
$ svnsync sync  file:///svn-mirror/my-project
sio4@repository's password: 
커밋된 리비전 1.
리비전 1의 복사된 속성
$ svn log file:///svn-mirror/my-project
------------------------------------------------------------------------
r1 | sio4 | 2008-04-08 23:02:46 +0900 (화, 08  4월 2008) | 2 lines

prepare project repository.

------------------------------------------------------------------------
$

1. 먼저 미러를 보관하기 위한 디렉토리를 만들고 그 안에 빈 저장소를 만든다. (저장소를 복사하는 것이 아니라 변경점을 동기화하는 것이 이 사본 만들기 기능의 방식이기 때문에 저장소 생성은 별도의 작업으로 진행된다.)
2. 만들어진 빈 저장소에 pre-revprop-change 후크를 설정해준다.
3. 프로젝트의 주 저장소와 연결하기 위하여 `svnsync init` 명령을 수행한다.
4. 연결된 사본을 `svnsync sync` 명령을 수행하여 동기화한다.
   

이상의 간단한 단계를 거쳐 이제 로컬에 저장된, 그리고 주 저장소와 동일한 복사본을 얻었다. 물론 읽기 전용 사본으로써 활용하기 위해서는 보다 정교한 설정이 필요하겠지만 나의 용도인 저장소 백업을 위해서는 이 정도면 충분하리라고 생각한다. 음... 글쎄... 정말 이사갈 일이 생기면 방 빼는 건 쉬웠는데... 다시 들여놓는 것도 그렇게 간단할까?

한참 전에 글을 시작했다가 덮어두고, 이제야 다시 써본다.

남에게 일을 맡겼다. 언제 검수해야 하는가?

요 근래 나를 눈코 뜰 새 없이 바쁘게 만들었던 이 프로젝트의 상당 부분이 다른 회사에 의하여 개발되고 있다. 그 중에는 자사 솔루션의 고객화 버전 제공 형식의 것도 있고 고객 요구사항에 의한 전면 개발 형식의 것도 있다. 괭장히 급한 일정으로 진행되었던 프로젝트였고, 초기 작업의 상당부분을 날림으로 또는 생략해버린 프로젝트였기에 시작부터 걱정이 태산이었던... 정말 슬픈 프로젝트였지만 프로젝트의 핵심 부분 중 하나를 맡은 그 회사는 그 시작부터 남 달리 믿음직한 인상을 줬었기에, 슬픈 프로젝트의 일부분이나마 믿음직한 구석이 있어서 다행스럽게 생각했었다.

오... 그런데 이게 왠 일인가! 믿던 도끼에 발등을 찍혔다. 나름대로 요구사항 분석부터 설계 문서 작성 등등... 나름의 형식과 절차에 맞는 초기 작업과 그 유명세까지 더해서 믿음을 줬던 그들이 왜 그런 결과물을 만들어낸 것일까...

결론은 하나! 내가 나쁜 놈이다. 더 꼼꼼해야 했고 더 의심했어야 했고 더 부지런했어야 했다. 그리고 시작부터 끝까지! 쉴 새 없이 확인했어야 했다. 프로토타입 단계에서의 느슨함도, 구조의 작은 미흡함도 시험용 코드라고 눈감아주고 결과물은 아니라고 양보해서는 안되는 것이었다.

이제와 후회하면 무엇하리... 검수는 머리 끝에서 발 끝까지, 시작부터 끝까지!

재밌네. 누군가 번역하여 둔 것을 먼저 봤으나, 원본의 것을 붙인다. 역시 우리만의 문제는 아닌게다.

원본은 : (project.jpg 그림, JPEGx800 픽셀)