2014년 6월 30일 월요일

Bamboo를 활용하여, Heroku로 지속적인 배포 하기

지금 blogsyncer를 개발하는 데 소스관리 시스템으로 github를 사용하고, 배포시스템으로 bamboo를 사용하고자 한다.
node.js로 개발하기 때문에 가장 적합한 서비스 플랫폼으로 heroku를 선택했다.
bamboo에서는 artifact를 만들고 그것을 업로드 하는 개념인데, 우선 node.js는 빌드 개념이 없다는 거 그리고 heroku의 경우에는 git으로 업데이트 된다는 것 때문에 헤맷습니다.
배포를 하기 위해서는 먼저 빌드를 해야 합니다. 저는 코드를 가지고 와서, mocha로 유닛 테스트 하는 것으로 build plan을 잡았습니다.
빌드를 완성하면 릴리즈를 만들 수 있고, 그걸을 배포하는 형태로 이루어집니다.

빌드 생성

Create에서 Create a new plan를 선택한다.
github의 계정과 패스워드를 입력하면 사용할 저장소를 선택할 수 있다.

서버 설정

Build Task는 source code check out, npm install, mocha 실행, parse mocha results 하면 mocha에 test결과가 bamboo에 등록된다.
우선 bamboo가 설치되어 있는 서버에 npm과 node.js를 설치해야 한다.
이거 mocha-bamboo-reporter를 설치해야 한다.
이거는 npm으로 간단히 설치할 수 있다.
$npm install -g  mocha-bamboo-reporter
이제 nodejs project에서 “mocha -R mocha-bamboo-reporter”라고 실행하면 mocha.json이 만들어 진다.

Bamboo 설정

Node.js를 사용하기 위해서는 plugin으로 “Bamboo Node.js Support”를 설치해야 한다.

Tasks 설정

빌드 생성에서 “Configure tasks”를 선택하면 Task를 등록하는 화면이 나온다.
Source Code Checkout은 이미 되어 있기 때문에 npm install과 mocha, parse mocha results를 하면 된다.
“Add task”를 선택하고 task types에서 npm 검색하여 선택한다. executable에 npm을 등록하고, command에 install만 추가 하면 된다.
 
mocha에 경우 task types를 command로 선택하고, executable에 mocha, argument에 -R mocha-bamboo-reporter 로 적어준다.
Parse Mocha results는 그냥 task types에 검색하여 추가만 하면 된다.
빌드를 하면 성공 여부가 나오고, tests에 보면 등록된 unitest에 대한 결과가 나온다.
  

Artifacts 설정

배포를 하기 위해서는 artifacts를 만들어야 한다. Configure Plan으로 간다. 거기서 job를 선택하면 tasks tab과 함께 artifacts가 있다.
지금 만드는 방법이 삽질을 통해 동작하는 방법을 찾은 것이지 좋은 방법이 아닐 수 있다. ;;
heroku의 경우에는 git으로 push해야 하기 때문에 사실 github에 등록된 code를 그대로 등록하면 된다.
그런데 copy pattern에서 기본적으로 .git폴더가 제외되어 있기 때문에 따로 정의해야 한다.
“Create definition”을 선택하여 두 개를 작성하자.
 
주의 할 것은 꼭 shared를 선택해줘야 배포시에 전달된다.
이제 새로 빌드 하면 빌드 결과에서 만들어진 Artifacts를 확인할 수 있다.

Deployment project 만들기

배포 정책을 만든 후에는 build를 하게 되면 release를 만들 수 있고, 그 release를 가지고 배포 할 수 있는데, release를 설정하는 것은 잘 기억나지 않는다. ;;
어째든 Create deployment project를 하게 되면 배포 설정하는 화면 나온다. 이름과 배포시에 사용할 build plan을 설정한다.
이제 환결 설정을 해야 한다. 아래의 화면에서 add envirement를 하면 이름과 함께 task를 구성할 수 있다.
기본적으로 “clean working directory task”와 “artifact download”가 있는데 artifact download에 “copy code”와 “copy git” 두개를 등록해야 한다.
그리고 command에 push code를 추가 해야 하는데, 이것이 정상 동작하기 위해서는 우선 서버에 heroku toolbelt가 설치되어 있어야 한다.

Heroku Server설정

Heroku dev center를 참고하여 heroku toolbelt를 설치하고 로그인 한다.
$ heroku login
Enter your Heroku credentials.
Password:
Could not find an existing public key.
Would you like to generate one? [Yn]
Generating new SSH public key.
Uploading ssh public key /Users/adam/.ssh/id_rsa.pub
github에서 code를 가지고 온다 다음에 push를 해보면 동작 확인 할 수 있다.
git push userid@heroku.com:application_name.git master
정상으로 올라갔다면 activity에서 확인 할 수 있다.
이제 환경 설정이 끝났다면, deploy 하면 build plan과 release을 선택하여 배포할 수 있다. release를 하기 위해서도 몇가지 해야 하는데 어렵지 않고 기억이 안나는 관계로 생략한다. ;;
참고

MARU180 1층 마이크임팩트 스튜디오 이용 후기

이미지
마이크임팩스스튜디오는 오픈형 워크스페이스이다.
최고 장점은 일요일만 21시까지 운영하고, 주중과 토요일은 24시간 운영!!
문제는 여기는 일하는 장소가 아니라 미팅할 장소정도 밖에 안됨. 조명이 너무 어둡고, 책상형 테이블이나  파티션이 너무 부족함.
분위기가 너무 커피숍이라, 드림엔터나 디캠프같은 오피스 분위기가 안남.
그리고 무료가 아니라는 것!
일인당 1시간에 2천원, 하루에 만원, 한달에 20만원(현18만원) – 팀을 위한 요금정책은 아직 없음
혼자 일하는 경우에는 한달 20만원에 개인사물함, OA시스템, 우편택배 보관 등이 있어 쓸만하겠지만 팀으로 쓰기에는 비용이 너무 비쌈.

TDD는 항상 옳지 않다 (비용의 문제)

Originally posted on arload - my Load to be Architect:
TDD
꽤 진부하면서도, 논쟁거리가 될수도 있지만, 개인적인 경험과 고민 끝에 글을 나누고자 한다. 꽤 스타트업을 기술적, 아키텍팅 쪽을 컨설팅하면서 지켜보아 왔던 경험치를 가지고 말씀 드리는 겁니다.  (물론 삼성이라는 대기업만 다닌 니가 스타트업을 얼마나 잘 알아? 라고 물어보실수 있지만 말랑 스튜디오, 빙글, 이노피아 테크 등 꽤 많은 업체들을 컨설팅하고 이야기를 나누고, 그들을 지켜보온 경험치라고 생각을 해주시면 될듯 합니다)
개발자들에게 TDD의 도입을  물으면 찬반이 매우 명확한 편입니다. 특히 큰 규모의 라이브 시스템을 운영한  웹 개발자 분들은 TDD를 통해 조기에 많은 문제를 잡고, 찐한 경험 이야기를 해주십니다. 100%로 동의합니다. 많은 유저들이 동시에 모여서 나가는 서비스라면 품질이 매우 중요해지고,  돌다리도 두들기고 건너가는 것이 맞습니다.  큰 웹서비스를 경험하신 분 입장에서는 TDD 가 큰 보험이 되며, 그 다음 Step을 넘어가는 좋은 보험이 되죠.
은총알은 없다.
특정 방법론, 전략이 A 상황에서는 좋은 약이 될수 있지만, 모든 상황에  항상 옳다고 할수 있을까요?
어떤 방법론이든, 기법이든 항상 장단이 있습니다. 전달을 할때 꽤 신중하게 전달을 해야 한다고 봅니다. “TDD는 좋다!” , “내가 해본 경험으로서는 정말…

Distributed Development

distributed development project is a research & development (R&D) project that is done across multiple business worksites or locations. It is a form of R&D where the project members may not see each other face to face, but they are all working collaboratively toward the outcome of the project. Often this is done through email, the Internet and other forms of quick long-distance communication.

Success factors

  1. Select and/or recruit good, strong, highly skilled people.
  2. Spend some money for face-to-face meetings, especially at the beginning of each major project.
  3. Build an organizational design that supports working in a distributed development, including the right incentive systems.

지역적 분산 소프트웨어 개발을 위한 툴들

지역적 분산 개발(Geographically Distributed Development, GDD)은 효율성이나 비용면에서 다수의 보상을 가져다 주지만, 성공적인 GDD 팀을 만들기 위한 몇가지 문제들도 있다.
GDD 프로젝트가 마주치는 가장 큰 위험은 내부적으로 효율적인 의사소통을 할 수 있는가에 대한 것이다.
우리에게 있어 GDD의 기본초석은 Internet Relay Chat 프로토콜이다. 우리는 IRC가 원거리 개발에 있어 인스턴트 메시징보다 우월하다.
  • 중간에 들어온 사람도 처음부터 글을 볼 수 있음.
  • 연결 유지가 쉬움.
  • 언어장벽에도 맞설 수 있는 기반 또한 제공
GDD 팀원간의 시차는 팀을 위기로 내몰고, 작업흐름을 혼란시키는 장애물이 될 수 있다.
  • timeanddate.com - 회의 스케쥴을 잡을 때 시차를 시각화하기 쉽게 만들어주는 Meeting Planner
개발 흐름을 촉진시킬 툴들
  • 메일링리스트, 버전관리, 버그추척, 문서 관리 
  • aMember - 여러분의 툴들이 단일 로그인
  • CollabNet사의 SourceCast - GDD를 막 시작한 팀들을 위해 이러한 모든 툴들을 통합해서 제공하는 상용서비스
  • Skype - 음성회의를 하고, 좀더 세부적인 논의가 필요할 때는 음성과 화상을 교차하여 회의
성공적인 분산 개발을 위한 12가지 조언
  • 아웃소싱을 위한 분산 개발이 아니라, 좋은 인재와 같이 일하기 위함
  • 사용도구가 분산 개발을 가능케 함, 분산 개발을 조장해야 함. 
  • 오픈 소스 수준의 협업 - 좀 더 모듈화된 API 기반의 접근방식을 조장한다.
  • 정직한 요구조선 수비과 검증 – 최신 정보를 구두보다는 서면으로 전달하고, 양보다 빈도를 많게 소 통
  • 시차가 4시간을 초과하면, 같은 시간에 소통하기 어려움.
  • 팀 크기를 작게 유지함으로써, 더 나은 공동체 의식과 책임감을 조장할 수 있다
  • 팀들이 가능한 많은 채널(스카이프, 채팅, SMS)을 통해서 접촉할 수 있게 해주어서 개발자들이 접촉하는데 부담을 느끼지 않도록 하는 것이다.
  • 관리자라면 시간 절반을 소통하는데 사용해야 한다.
  • “군대 수준의 정확성”으로 관련 모든 정보(버그번호, JIRA 추적보고, ..)를 전달해야 한다.
  •  버그 개수, 빌드 상태, 서버 부하, 초당 질의 개수, 다운시간 등 개발자들에게 중요한 수치는 모두 공유되어야 한다.
  • 충분한 사회성도 필요하다. – 즐거운 시간 보내기

분산 Scrum

팀 멤버가 분산되어 있는 경우 소프트웨어 개발자는 서로로부터 자신을 분리하려고 코드에 더욱 더 많은 추상화 레이어를 만드는 경향이 있습니다.
인간이 서로 간에 말하는 것 중 많은 부분이 신체 언어를 통해 전달됩니다.  디자인 토론 중에 누군가를 관찰하여 수집한 정보는 화이트보드에 적은 정보만큼이나 중요할 수 있습니다. 이 때문에, 분산 작업자 간의 격차를 해소하기 위해서는 신체 언어 장벽을 극복하는 데 더욱 더 중점을 두어야 합니다.
화면 공유는 매우 효과적인 연결 및 공동 작업 도구입니다.
모든 항목에 대한 단순 확인 규칙을 추가(팀 전체에 걸쳐 수행되는 작업에 대한 집단 이해도를 높임)
  • 각 항목을 완료 상태로 간주된 통합 환경에서 확인해야 합니다.
  • 확인을 수행하는 사람은 작업을 수행한 사람이 아니어야 합니다.
가상 단체방은 항상 열린 상태로 유지되었으며 팀 멤버는 작업할 때 이 작업실을 방문하게 됩니다.
개발자들은 화면 공유 소프트웨어를 사용하여 서로의 화면을 보기 시작했습니다. 이 방법이 더 빠르니까요. 팀에서는 몇 인치의 벽 공간으로 분리된 각자의 사무실에서 앉아 있지만 하루 종일 가상 작업실을 사용하기 시작했습니다.
결국 팀 멤버 중 하나가 몇 일 동안 사무실로 출근하지 않고 재택 근무를 시도했습니다. 스프린트 회고(Sprint Retrospective) 중에 개발 팀은 복도를 지나 몇 번째 문에 해당하는 사무실에 있든 집에 있든 작업자의 위치는 가상 작업실에서 아무런 상관이 없음에 동의했습니다. 가상 단체방이 개인 사무실보다 더 중요함이 입증되었습니다.
물리적 장벽을 극복하고 팀의 커뮤니케이션에서 참여한다면 더 높은 품질, 혼란의 감소, 더 빠른 처리량, 그리고 더 큰 개인적 만족감을 결실로 얻게 될 것입니다. 팀 내에서 도구 및 구현 방식을 신중히 고려할 때 분산 구조가 잘 운영될 수 있습니다.

SW분산개발이 일자리 만든다
클라우드 환경에서 웹을 기반으로 원격 분산개발 환경을 구축할 수 있기 때문이다. 클라우드 웹 기술은 언제 어디서 접속하여도 작업 환경을 복원해주기 때문에 원격 개발의 효율성이 높아졌다.
소프트웨어 분산개발이 활성화 된다면 소프트웨어 기업에서 유연근무와 재택근무 형태가 확산될 것이고 이는 육아부담의재택개발자들에게 양질의 일자리를 제공할 것이다. 

참고