3 posts tagged with "bamboo"

사용중인 Bamboo가 3.2 버전이었는데 최신 버전인 4.1.1로 upgrade 할 일이 생겼다.

Upgrade 방법을 알기 위해 검색해보니 공식 매뉴얼이 있는데 하위 버전별로 upgrade 방법이 다른 것처럼 기술되어 있다.

https://confluence.atlassian.com/display/BAMBOO/Bamboo+4.1+Upgrade+Guide

몇 개 링크를 눌러보니 링크가 잘못 걸린건지 하위버전에서 4.1로의 upgrade가 아니라 하위 버전으로 upgrade 방법들이 나와있어서 Bamboo generic upgrade guide만 참조.

가이드 문서만 따라해도 문제없이 진행은 된다.

과정을 요약하면

1. export / data (bamboo-home) 백업

2. 최신버전으로 재설치

3. properties 파일을 설정에 따라 수정

4. start

새로 설치된 파일이 같은 data (bamboo-home) 경로를 참조하길래 혹시나 문제가 없을까 했는데 다행히 깨지거나 인식을 못하는 문제는 없어보인다.

3.2와는 다르게 4.1.1은 시작 주소를 http://ip:8085 가 기본이다. 3.2의 경우엔 뒤에 /bamboo란 path를 넣었었고 다른 Atlassian tool들이 해당 경로를 참조하도록 설정되어 있었기 때문에 ${bamboo_install_path}/conf/wrapper.conf 파일을 수정.

기타 LDAP 등의 설정도 해줘야 하지만 현재는 User 정보를 모두 JIRA에서 땡겨오도록 되어있기 때문에 skip 했다.

Atlassian의 Bamboo를 사용중인데 얼마전 서버의 root 계정 대신 특정 계정에 sudo 설정을 한 이후에 문제가 발생했다.

bamboo.sh 실행시 start 옵션을 주면 시작하게 되어있는데 시작했다는 로그와 pid 값은 뿌려지지만 실제 프로세스는 실행되지 않았다. 실행시에 기록되는 로그파일을 열어서 확인해보니 java 프로세스 자체를 시작하지 못하는 것으로 보였다. 그래서 bamboo.sh 파일을 열어 내용을 확인해보니

export JAVA_HOME

이라고 환경변수를 export 하고는 있었으나 실제 파일 어느 곳에도 JAVA_HOME이 설정된 부분은 없었다. 그래서 추가.

왜 이전엔 잘 되다가 갑자기 JAVA_HOME 설정이 빠진건지 이해가 되지 않는다.

어쩌면 file 자체는 변경사항이 없었으나 (원래 비어있는 상태) root 계정에서는 원래 서버에 환경변수로 잡혀있는 JAVA_HOME을 인식하는지도 모르겠다. 왜 그럴까?

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를 진행하면 뭔가 그럴듯한 산출물이 만들어질 것 같다. 배움과 깨달음도 함께...