4 posts tagged with "scm"

Google의 code review tool인 Gerrit 사용시 기존의 label인 Code-Review, Verified 이외에 사용자 정의 label이 필요한 경우가 있다.

내 경험으로는 CI를 위해 custom label이 필요했었는데 특정 label의 point로 build 여부를 결정짓는데 사용했다.

Custom label이 필요한지 여부를 판단하는 것은 어디까지나 SCM 정책에 따라 달라질 수 있고 그 설정과 관리는 대부분의 사용자들과는 관계가 없는 부분이다.

 

1. Project clone​

Custom label을 적용하고자 하는 특정 project (저장소)를 clone 한다.

Gerrit의 branches 메뉴를 보면 refs/meta/config 라는 reference가 존재하는데 일반적으로 master branch가 항상 있는 경우 refs/meta/config를 checkout 하지 않으면 보이지 않는다.

비어있는 project를 대상으로 하면 (branch가 없음) clone 하면 바로 유일한 reference인 refs/meta/config의 내용이 나타난다.

 

2. project.config 수정​

refs/meta/config에는 project.config와 groups 파일이 있는데 (모든 경우를 살펴본 것은 아니라서 다른 파일이 추가되어 있을 수도 있음)

groups 파일에는 access control에 추가되어 있는 관계된 group 정보가 포함되어 있고 custom label 설정과는 관계가 없다.

project.config 파일을 열어보면 access control에 대한 내용과 project 일반적인 설정들이 포함되어 있는데 (description 등) 추가할 label에 대한 내용을 정의한다.

보통 이런 형태로 작성하면 되는데

[label "test label"]

function = NoOp

value = 0 Do Not Build

value = +1 Build Now

추가 상세 설정은 Gerrit 문서를 참조해서 진행한다.

function을 NoOp으로 설정한 경우 submit 여부를 결정하는데 test label이 영향을 미치지 않는다. (기존 정책에 따라 submit 여부가 결정됨)

value는 설정한대로 부여할 point의 범위가 결정되는 역할을 한다.

 

3. Commit / Push​

소스코드와 동일하게 저장소 변경사항이 발생했으므로 commit을 하고 push를 한다. (Push 할 때 refs/meta/config를 지정하는 것은 기본)

Gerrit의 branches 에서 refs/meta/config의 내용을 확인해 변경사항이 제대로 반영되었는지 확인이 되면 Access Control 메뉴에서 설정할 때 내가 추가한 test label 설정이 가능한 것을 확인할 수 있다.

 

4. 결론​

일반 개발자들이나 사용자들은 어쩌면 알 필요가 없는 기능이다.

하지만 이런 것도 Gerrit이 제공한다.

알아두면 CI 구성이나 SCM 정책을 좀 더 유연하거나 강화시키는데 도움이 될것이라고 본다.

국내에서는 이런 custom label 사용보다 사실 Gerrit이 제공하는 기본 기능, 정책들만이라도 잘 지킬 수 있기를 희망한다.

Test Framework 개발 프로젝트를 하면서 Agile 방법론과 여러가지 새로운 도구와 Process를 도입하는 중이다.

처음 시도해보는 것들이기도 하지만 잘해두면 우리 내부에서도 좋은 개발환경과 프로세스, 괜찮은 분위기와 조직문화 비슷한 것도 만들어질 것이라고 생각한다. 또 이 부분에 대한 know-how 같은 것도 쌓일테니 나중에 개선이 필요하다고 생각하고 있는 외부조직이나 업체에 assist 하기도 좋을거고.

현재 Test Framework 설계를 진행하면서 대부분의 업무 할당은 JIRA로 진행되고 있다. 그리고 설계 단계에서 나오는 산출물 (설계 문서들)은 Confluence에서 공동작업에 의해 만들어지고 또 읽혀지고 있다.

1차 설계가 종료되고 Prototype을 만드는건 Eclipse를 이용하지만 Source code 관리는 GIT으로 한다. CI를 위해서 Bamboo를 이용하며 현재는 Commit 시점에 항상 빌드하도록 설정되어 있다. 개발자가 Prototype을 만들고 Eclipse에서 빌드를 해보고 commit을 하겠지만, 그렇지 않은 경우가 있을 수 있고 저장소의 나머지 소스들과의 버전 차이로 빌드가 실패할 가능성이 있으니 작은 프로젝트라도 CI는 해봐야 한다고 본다. Eclipse project는 Eclipse 자체를 쓰면 별도의 build script가 굳이 필요없지만 Bamboo와 같은 CI tool에서 빌드 자동화를 하려면 별도의 build script가 필수적인데 예전에 약간 사용해봤던 Ant를 써서 만들어 두었다. 개발자가 소스코드도 개발해야 하고 빌드를 위해 수정이 필요하다면 Ant script까지 손을 봐야겠지만 사용이 어렵지 않고 수정할 부분이 많지 않을테니 큰 거부감은 없을 거라고 생각한다. 이제 Build 성공, 실패 여부를 개발자들이 메일로 받아볼 수 있다.

Code Review를 위해서는 FishEye와 Crucible에 우리의 저장소를 연결해 두었다. 언제 code review를 할 것이냐는 내부적으로 협의가 되어야 하겠지만 언제 어느 시점에 진행하더라도 code review의 문제점은 간단하게 Issue로 등록해서 담당자에게 할당할 수 있다.

이제 sprint1의 절반이 지났다. 다음주면 설계 문서와 spec을 기반으로 Testcase를 작성할 것이고, 테스트 자동화는 CI에 묶여서 역시 결과를 메일로 보내줄 것이다. 이 sprint가 계획대로 잘 끝나고 마지막에 retrospective를 진행하면 뭔가 그럴듯한 산출물이 만들어질 것 같다. 배움과 깨달음도 함께...

 개발되는 코드를 git으로 관리하기로 결정하면서 git public repository 설정 중.

리눅스 서버에서 구축해야 하나 여러가지 이유로 윈도우에서 확인하고 있다. ssh로 인증하게 되어있어서 몇가지 문제점이 있었으나 인증 문제는 해결되었다. 지금 남아있는 문제는 문자열 길이가 맞지 않는다는 오류 메세지인데 추측되는 원인은 있으나 아직 조치하지 못하고 있음.

내일은 완전히 해결할 수 있기를...아니 해결한다!

요즘 CI를 하면서 느끼는게 많다. 책에서 그려지는 과정은 상당히 단순한데 사실 형상관리 뿐만 아니라 바뀌어야 하는게 한두가지가 아니라 막상 파헤쳐보니 그리 단순하지 않다.

하지만 재밌는건 어려운 상황이다보니 더 재밌는 아이디어들이 떠오르고, 더 나은 생각과 비젼 같은게 생긴다. 많은 사람들이 흥미도 느끼지 못하고 관련 업체도 국내엔 전무하다시피한 상황(하긴 이것 뿐만이 아니라 SI를 제외하곤 거의 없다) 이지만 그래서 더 연구해볼만한 가치를 느낀다. 예전부터 중요하다 생각했던 부분이기도 하고 나름 흥미를 느껴와서 그런것 같기도 하다.

CI에서 빌드만 자동화를 하고 있지만 자동화의 맹점이기도 한게 사람이 손을 놔버리게 만드는 현상 혹은 습관이라는 생각이 든다. 자동화는 사람을 좀 더 편하게, 조직적으로 효율적으로 운영하고자 하는 수단일 뿐이지 그것 자체가 SW 프로세스 전체의 솔루션이 되어서는 안된다. 관심이 사라지는 순간 시스템 도입 이전으로 돌아가기 쉽고 결국은 비효율적이라며 비싼 돈을 투자한 것들을 버리게 될 가능성이 높다고 본다. 더구나 초기일수록 수작업으로 진행할 때 처럼 관심을...초기 시스템의 오류들은 손으로 잡고 이론과 가설을 수정한 후에 다시 재작업, 그리고 관찰하고 다시 발생하는 문제점들을 해결하는 과정들이 여러차례 반복되어야 나도 그 과정에서 더 배우는게 있겠지. 그나저나 EC2는 어떻게 공부해봐야할까?