서로 맞물려서 돌아가야 하는 기반시스템(Infrastructure System)
RSS Feed
소프트웨어를 개발하고 있는데, 필수적인 기반시스템에 대해서는 이미 설명한 바가 있습니다.
이 기반시스템은 서로 연동이 되어서 맞물려 돌아갑니다.
만약에 이 기반시스템들을 사용하고 있지 않다면 기적적으로 개발을 하고 계시거나 정말 쓸데 없는 고생을 하고 계신 겁니다. 어떠한 방법론을 쓰더라도 이 기반시스템을 쓰는 것은 거의 다르지 않습니다. 우선적으로 시급하게 기반시스템들을 도입을 해야합니다. 기반시스템을 써보려고 하는데 어려움이 있거나 궁금한 점은 제가 도와드릴 수 있습니다.
그리고 각 기반시스템이 서로 연동되지 않고 따로 돌고 있다면 최대한 활용하고 있는 것이 아닙니다. 각 기반시스템들은 서로 연동이 되고 최대한 자동화를 해야 효율이 높아집니다. 각 기반시스템들이 기본적으로 어떤 것들을 교환하는지 간단하게 예를 들어 보겠습니다. 여기서 예라고 하는 이유는 계속 개량 발전시켜나면 연동하는 것들은 점점 늘어나고 자동화 되면서 효율은 더욱 높아지기 때문입니다.
물론 이 외에도 사용하는 기반시스템들도이 있지만, 아래 그림이 소프트웨어 회사라면 필수록 필요한 최소한만 추린 것입니다.
각각의 연동 방식이나 자세한 내용은 많은 양이므로 추후 하나씩 설명하도록 하겠습니다.
그리고 하나하나의 운영 방법도 다양하고 계속 발전하고 있어서 자신의 회사에 적당한 방법을 찾아야 합니다.
이렇게 서로 연동되고 있지 않으면 자동화 될 수 있는 일에 괜히 시간과 노력을 들이고 있는 겁니다. 그렇게 된다면 개발자들은 개발을 해야 할 소중한 시간에 쓸데 없는데 시간을 허비하고 실수에 의한 사고 가능성도 높아집니다. 또 오랫동안 개발 정보가 쌓여도 그리 효율적으로 활용되지 못합니다.
일단 이런 식으로 잘 갖추워진 기반시스템 하에서 개발을 하다보면 과거의 방식으로는 도저히 돌아갈 수 없고, 과거에 왜 그렇게 개발을 하면서 시간을 낭비했는지 안타까운 마음이 생길 겁니다.
'기반시스템' 카테고리의 다른 글
| 몇억짜리 툴은 쉽게 사면서 더 좋은 공짜툴은 제대로 쓸 줄 모른다. (0) | 2009/03/05 |
|---|---|
| 깨끗한 개발 환경, 빌드 환경, 테스트 환경 (6) | 2009/02/05 |
| 서로 맞물려서 돌아가야 하는 기반시스템(Infrastructure System) (11) | 2009/02/03 |
| 이클립스 프로젝트 필수 유틸리티 개정판 : Subversion, Ant, JUnit, Trac (2) | 2009/01/28 |
| 우리 개발자는 뭐든 뚝딱 잘 만들어요. (0) | 2008/12/08 |
| 기반시스템(Infrastructure System)을 사용하고 계신가요? (4) | 2008/11/05 |
제 미천한 경험으로 위쪽 세가지 시스템은 다루어 봤는데,
버그 추적 시스템과 release 시스템은 아직 못 겪어봤네요.
위쪽 3가지 시스템은 그냥 정책적으로 표준화 시키면 다들 따라오는데,
버그 추적 시스템은 토론하거나, 의견 수렴하기가 좀 어려운 거 같습니다.
아무래도 국내 환경에서는 남들이 많이 쓰냐를 의식하는데,
그런 사례 정보를 못해서 그런 것도 있고, 필요성을 느끼지 못하니
토론 하거나 의견을 나누기도 좀 어렵더군요.
Release 시스템은 무얼 의미하시는지 잘 모르겠구요... T.T
써니님 안녕하세요.
버그추적시스템을 사용하고 있지 않다면 버그 관리는 어떻게 하시나요? 엑셀파일에 넣어서 관리를 하시나요? 그렇다면 하루라도 빨리 버그추적시스템을 도입하시기를 강력히 권장합니다. 윗분들이나 동료분들을 설득해야 한다면 제가 설득을 해드릴께요. 시중에는 좋은 OpenSource 버그 추적시스템이 많이 있습니다. 버그관리시스템은 사용이 그렇게 어렵지 않고 금방 적응할 수 있을 겁니다. 단 빠짐없이 써야하고 기존의 방식은 버리셔야 합니다.
그리고 Release System은 일반적으로 관심이 없지만 Release가 복잡한 시스템도 꽤 많습니다. 보통 Build와 Release는 같이 생각합니다. Release가 복잡한 경우는 새로운 패치가 나올 때마다 업데이트 서버에 파일들과 Release Note를 올려야 한다면 이를 자동화 할 수 있고, 업데이트도 Delta업데이트 되어야 한다면 좀더 복잡합니다. Build와 Release는 회사에 맞게 계속 연구하고 개량 해야 하는 부분이 많습니다.
멋진 그림이군요. JCO 발표할 때 인용해도 될까요?
영회님 안녕하세요. 블로그의 모든 내용은 출처만 표시하시고 변경만 하지 않으면 비영리 목적으로 이용할 수 있도록 표시 되어 있으니 맘껏 이용하세요.
정말 깔끔한 그림이군요.
저희팀은 릴리즈노트 작성시 릴리즈담당자가 SCM의 변경이력을 확인하여 작성하고 있습니다. 이 그림에서는 버그트랙커에서 릴리즈노트를 생성(자동이건 수동이건)하는 것으로 되어있는데
이에 대해서 나중에 좀더 자세하게 알려주시면 도움될듯 합니다.
계속 좋은글 부탁드립니다.
헝그리맨님 안녕하세요.
그림을 보면 변경이력이 SCM에서 자동으로 버그트랙으로 연동이 되도록 되어 있습니다. 그래서 결국 내용은 같은 것이 됩니다. 그런데, 버그 ID하나에 SCM에서 소스코드는 여러번 바뀔 수가 있습니다. 즉 제품에서는 버그ID하나에 해당하는 버그 하나가 수정되기 위해서 여러가지 일을 수해할 수 있습니다. Release Note에서 이를 한건으로 처리를 하기 때문에 버그트랙과 연동을 하고 있습니다. 그리고 Release Note는 자동으로 뽑아내게 됩니다. 그러기 위해서는 버그 해결 시 해결 Version을 제대로 지정해줘야 합니다. 물론 Release Note를 외부에 공개시는 문장은 다듬어줘야죠.
그림 잘 보았습니다. 그림에서 build system 으로 src/build script 가 넘어간다고 되어 있는데, 그렇다면 빌드를 위한 모든 리소스들(소스코드/테스트코드/설정파일 등등)이 모두 넘어간다는 것이고 binaries 라는 건 그것들을 모두 묶은 결과물을 이야기하는 것 같습니다.
그런데 그림을 보면 SCM 에서 release system 으로 file 들이 또 전송되는 것 같은데 이건 어떤 걸 의미하는 건지요?
release system 에서 release 환경에 맞도록 필요로하는 추가적인 것들을 의미하는 거라면 release system 에서도 릴리즈 환경에 맞도록 build script / test script 등을 다운로드 받아 빌드해야 할 것 같고, 위에서의 "build system" 은 "통합 테스트 system" 정도로 명칭을 바꾸어야 하는 건 아닌지요?
우울한딱따구리님 안녕하세요.
이 그림에는 테스트 시스템은 표현하지 않았습니다. 그리고 모든 연동을 다 표현한 것은 아닙니다. 위에서 언급했다시피 회사마다 조금씩 달라질 수 있습니다.
대부분의 경우 빌드, 팩킹이 한꺼번에 이루어지고, 릴리즈는 자동화 할 것이 없습니다. 따라서 그냥 상상하기는 어렵습니다. 하지만 복잡한 릴리즈 절차를 가지고 있는 회사라면 당연히 자동화를 해야 하는 것이 효과적이고, 당연히 자동화된 Release Script를 만들게 됩니다. 이때 Release Script는 빌드 시스템에서 빌드한 바이너리나 팩킹된 이미지와 릴리즈에 필요한 여러 데이터를 주변 기반 시스템에서 가져오게 되고, 그 예를 설명한 것입니다. 이러한 파일들은 제품에 포함되는 파일은 아니고 부가적으로 제공하는 파일 정도로 보면 될 것 같습니다.
복잡한 릴리즈 절차를 가지고 있는 경우가 아니라면 별로 고민할 필요가 없습니다. 나중에 고민할 필요가 있을 때 생각하면 됩니다.
mail 시스템은 하나 있는게 좋은거 같더라구요
회사서버에서 서버마다 sendmail 설정하려니 삽질하는거 같고...
괜히 그거 하나때문에 sendmail 설정하는 쓸데없는 시간이 낭비되는거 같더라구요
nakada님 안녕하세요.
sendmail설정하느라고 고생하셨군요. ^^ 개발자이신가 봐요? 만나서 반갑습니다.
결국 설정안했어요 ^^ㅋ;
저는 이제 시작하는 신입 개발자에요 ^^