회사 입사이후 개발 환경 구축 후기

OOOOOOOO 회사에 입사를 결정했습니다.

입사 첫날, 제 자리에 앉았습니다.

개발팀원들과 인사를 나누고, 앞으로 업무 파악을 하시면서 전체적으로 문제되는 사항들을 잘 잡아주시면 된다라는 이야기를 들었습니다. 

다들 의욕이 충만한 젊은 개발자들이 이였습니다. 냐하핫

아.. 나도 열심히 해야지 !!!

자리에 앉았지만, 컴퓨터나 모니터가 보이지 않네요;;;

배송이 늦어져서 오후에나 온다고 하네요 @.@

다행이도 제 가방에는 읽을 책이 있어서, 책을 읽고 있었습니다.

점심을 먹고 나니, 컴퓨터가 도착해 있네요.. 우왕.. 내가 좋아하는 맥북..이 아닌 윈도우즈 데스크탑이네요.

오홋.. 최근 회사를 다니면서, 데스크탑을 받은건 참 오래간만이네요 ..

뭐 클라우드 시대 이니까.. wherever!!! 

이메일 계정을 만들고, 사내에서는 telegram 으로 커뮤니케이션을 하고 있었습니다만,

이메일은 만들어 놓고, 거의 쓰지를 않았고, telegram만 약간 활용하고 있었습니다.

하지만 팀 커뮤니케이션을 하기에는 적격은 아니였습니다. 

커뮤니케이션 툴 필요

Slack (https://slack.com/  , Team communication for the 21st century) 

개발팀은 회사내에 업무 관련하여서는 Slack을 도입하자고 외쳤습니다.

Channels , Private Channels, Direct Messages 는 기본이고, 데스크탑 어플리케이션, iOS/Android App 제공

대화 내용 히스토리 관리 및 검색이 용이 하고, 공유하고자 하는 파일, 문서등의 관리도 용이 합니다.

여러 툴과의 통합(Integration)이 잘 되어 있기 때문에,

이후 확장성을 고려하면, 제가 이전부터 사용했던 Slack이 가장 시급했습니다. 

프로젝트 관리 툴 필요

Trello(https://trello.com/ , The free, easy and visual way to organize anything with anyone.)

Trello를 도입했습니다. 개발 방법론 중에서 칸반 이라고 있습니다.

다시 말해 작업 흐름을 시각화 하는 것으로써, 프로젝트 별로 진행되는 사항을 한눈에 확인하는데 이것만큼 좋은 것이 없습니다.

Trello에는 각 카드를 생성, 카드 내에 업무 내용, 일정, Todo 리스트, 그리고 member 배정 과 Color flag.

카드내에 Comment를 커뮤니케이션 및 이력 관리가 너무나도 용이 합니다.

검색, 파일 관리등이 용이합니다. 

소스 버전 관리 시스템 필요

Git, Github(https://github.com/, Where software is built)

Powerful collaboration, code review, and code management for open source and private projects. Public projects are always free.

SVN을 사용하고 있었고, branch,trunk, tag 의 활용이 전혀 되지 않고, 거의 소스를 통짜로 넣고 관리를 하고 있었습니다.

통짜라는 것은 모든 소스(web,server module,android,flex....) 등등... 회사에 있는 모든 소스가 한 라인하에서 관리가 되는거죠.

그렇게 된 것은 , 초기에 팀 작업 형태로 진행한 적이 없었기에, 불편함 없이 쓴것 같았습니다.

merge 할 일이 없었을 수도 .... 이제는 팀작업을 기준으로 진행 해야 하기에, 적극적으로 Github에 대한 사용에 대한 제안을 했고,

회사 계정으로 10개의 private repository를 월 단위로 구매해서 사용하기로 했습니다.

svn 서버를 별도로 두지 않아도 되기에, 보다 개발자들에게 이런 관리적인 측면을 제거 함 점과

회사측에도 이것과 관련한 서버를 두지 않아도 된다는 비용 적이 측면도 도움이 된다고 생각합니다. 

이슈 관리 프로그램

redmine ( http://www.redmine.org/, Redmine is a flexible project management web application)

이것은 이전에 SVN와 연계하여 사용하였지만, 이제는 사용하지 않기로 했습니다.

Trello + Slack + Github 를 연계해서 이슈 및 프로젝트 관리를 하기로 했습니다.

Trello + Github 연동은 trello 유료 버전에서만 가능하기에 , Slack + Github 연동을 하는 것으로 진행 할 예정입니다.

물론 Trello + Slack 연동도 가능하답니다.

개발 환경

개발자 컴퓨터에서 다이렉트로 상용(Production)으로 배포해서 서비스를 진행하고 있었습니다. 헉

테스트 서버는 로컬에서 충분히 해도 되지만, Test -> Staging -> Production 의 순 으로 개발 프로세스를 변경하는 것이 필요 했습니다.

우선 Staging 서버를 구축 했고, 테스트 DB도 함께 구축 했습니다.  T.T

단위 테스트 (http://junit.org/, JUnit is a simple framework to write repeatable tests.

It is an instance of the xUnit architecture for unit testing frameworks)

개발자 컴퓨터에서 개발을 마친후에 빌드, 눈에 보이는 몇가지 테스트를 거쳐서 바로 Production으로 디플로이 하는 프로세스는 정말 치명적입니다.

하지만 그렇게 수년을 해왔다는 것이 믿어지지 않았습니다.

위에 Staging 서버를 두긴 했어도, 유닛 테스트가 반드시 추가 되어야 하는 점이 가장 시급했습니다.

JUnit 단위 테스트를 반드시 추가후 통과 해야, Staging 서버로 이동하는 프로세스를 만들었습니다.

CI 서버 (Jenkins , https://jenkins-ci.org/, An extensible open source continuous integration server) 

Jenkins is a cross-platform, continuous integration and continuous delivery application that increase your productivity.)

테스트 자동화, 빌드 자동화, 배포 자동화 까지....

이제는 CI 서버를 안쓰는게 이상하지만, 이 역시 없었네요.

Jenkins 서버를 Staging 서버에 세팅을 하고, 신규 프로젝트 부터 테스트,빌드,디플로이 프로세스를 만들었습니다.

이것도 사내 교육이 필요해서 사내 발표 등을 진행 했습니다. 

클라우드 서버 

Production은 KT 클라우드 서버를 사용하고 있었습니다.

물론 국외 서비스 전용이면, 아마존 클라우드를 사용하는 것이 맞겠지만, 국내 전용 서비스 이다 보니,

클라우드에 대한 부분은 큰 걱정은 없었습니다. 서버 증설은 빠르게 대응 가능합니다만,

Containerization for Production Service 에 대한 부분이 취약해 보였습니다.

이후에 CoreOS, Docker 등에 대해 좀더 알아 본뒤에, 빠른 대처 방안을 마련하는 숙제를 얻었습니다.

 

여기까지 정리를 했으면 개발 환경에 대한 큰 그림을 그려보면 아래와 같습니다.

(참고: https://en.wikipedia.org/wiki/Deployment_environment )

Local (Developer's desktop)   --> Development/Trunk (Development server aka sandbox) 

--> Integration(CI build target, or for developer testing of side effects) 

--> Test/QA (For functional, performance testing , Quality Assurance etc) 

--> Stage/Pre-production (Mirror of production environment) 

--> Production/Live (Serves end-users/clients)

회사에서는

local (각 개발자들은 Github 상에서 master/branch 개발 진행 )

--> Development / Trunk ( project master가 branch merge 하면서, 코드 리뷰 진행 )

--> Integration ( Jenkins , Testing & Building)

--> Test/QA ( "", 퍼포먼스 테스팅, 품질 테스트에 대한 방법 강구  ) 

--> Stage/Pre-production ( 클라우드 Stage Server) 

--> Production/Live (클라우드 Live Server)

이런 식으로 진행 할 예정입니다.

전체적으로 이런 가이드를 하는 문서는 아래 링크를 참고하면 더더욱 잘 알수 있습니다.

A Field Guide to the Distributed Development Stack 

http://sites.oreilly.com/odewahn/dds-field-guide/ch01.html#idp668304

제가 진행하려고 하는 것과 거의 일치하는 듯 싶습니다... 

앞으로 부족한 부분이나 변경 되는 사항들은 지속 관리 하도록 할 예정입니다.

오늘은 여기 까지 입니다.