버전관리 : 개발소스와 운영용 소스의 차이는 어떻게 관리하시나요?
글쓴이: krondor / 작성시간: 월, 2009/09/14 - 3:16오후
개발버전과 배포(운영)버전이 서로 차이가 나게되는 파일들 있잖습니까?
예를 들어서 DB접속정보나 특정 디렉토리 위치, 웹 컨테이너등에 따른 설정정보 등등..
(*.properties, *.res, *.xml, *.ini등등)
이런 파일들의 버전관리 정책은 다들 어떻게 하고 계신지 궁금합니다.
중요한 정보들이 담긴 파일들인 만큼 버전관리에서 뺀다는 건 무리이고..
버전관리에 포함시키자니...
개발팀에서 다운로드 받을 때 운영버전의 환경설정파일들을 내려받게 되거나,
심지어는 잘 모르는 개발자가 운영버전의 환경설정파일들을 내려받은 후 내용을 바꿔....
(상상만 해도 끔찍한 재앙이죠. -..-)
물론 버전관리로부터 Export받은 소스를 운영용에 맞도록 가공하는 스크립트를 짤 수는 있습니다만...
손바닥만한 프로그램/웹소스들을 위해서 일일이 그런걸 짜 놓는건 배보다 배꼽이 더 커지는 삽질이고요.
이런 문제를 어떻게 처리하고 계신지 궁금합니다.
혹시 사용자 권한을 설정해서 따라 버전관리(SubVersion) 프로젝트의
일부 파일만 다운로드 받도록 할 수 있을까요?
아니면 서브버전 프로젝트의 일부 파일만 다운로드 되도록 필터링 할 수 있는
요령이나 기능이 있는 지 궁금합니다.
Forums:
개발시에는 make만
개발시에는 make만 치면 되게,
릴리즈시에는 make release, 서버 배치시에는 make deploy등으로 설정해서 씁니다.
즉, make target으로 관리합니다.
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
-----
오늘 나의 취미는 끝없는, 끝없는 인내다. 1973 法頂
각각 관리하시는게 맞습니다.
개발 편의성 만을 생각하지 마시고 회사의 보안 정책이나 업무 분담 등을 고려하면,
개발소스를 운영소스로 변환하는 과정 자체가 감사, 통제의 대상입니다.
기본적으로 개발팀과 운영팀은 분리돼야 하므로,
두 소스는 각각 관리해야 합니다.
개발 소스를 누가 운영팀에게 배포하며,
이 때 설정을 누가 어떻게 바꿀 것이냐 하는 정책이 수립돼고 실제로 잘 지켜지는지 추적돼야 합니다.
===========================================================================
Shocky Han
BIM Consultant, Certified Information Systems Auditor
Seoul, Korea.
===========================================================================
그래도 저런 기능
그래도 저런 기능 필요합니다.ㅠㅠ
예를 들자면, 방대한 라이브러리를 만들었지만,
프로젝트에 필요한 건 일부분이죠.
그러면 파일을 복사해서 해당 프로젝트와 묶을 수 밖에 없는데,
그렇게 하면 버그 수정 등의 일이 발생할 때 프로젝트 별로 복사해 넣을 수 밖에 없습니다.
간단하게 해당 프로젝트에서 사용하는 파일들만 따로 지정할 수 있으면 업무가 훨씬 수월해 집니다.
emerge money
http://wiki.kldp.org/wiki.php/GentooInstallSimple - 명령어도 몇 개 안돼요~
http://xenosi.de/
https://xenosi.de/
문제는....
답변글들 감사합니다.
문제는 관리대상 어플리케이션들이 메인 상품이 아니라
메인 상품의 운영을 위한 세컨드 어플리케이션이라는 점이거든요.
스크립트 같은 걸 짜는 것도 고려를 했지만
메인이 아닌 보조 시스템들을 위한 관리 공수들이 점점 불어나고 있는 것 때문에 고민인거랍니다.
개개 담당자들은 "이거 하나 스크립트 들여다보면 되는건데...."라고 계속 뭔가를 만들어놓는데,
이게 갯수가 불어나기 시작하니까 전체적으로는 부담되는 상황이 생기고 있습니다.
(자기 입장에선 몇 개 안되지만 전체적으로는 관리도 잘 안되면서 자기개성은 강한 스크립트들이 쌓이기 시작...)
Man/Day로 인정받지도 못하는 작업들이 완전히 가랑비에 옷 젖는다는 식으로 조금씩조금씩 부풀어오르고 있어서
뭔가 명료하고 간단한 정책을 고민하고 있었습니다.
네. 동감합니다.
혹시 배포를 개발부서에서 직접 하시나요?
개발과정과 배포, QA 과정은 개발과 분리 되어야 하는게 맞다고 봅니다.
원하시는 명료하고 간단한 정책이 바로 이것이죠.
현실적으로 전담할 인원을 충원하는 게 쉽지는 않습니다만,
별도의 인력으로 분리 시켜야 원하는 결과가 나올 수 있을 겁니다.
저렇게 계속 관리하다보면 나중에는 정말로 주 업무에 부담을 줄 정도까지 문제가 쌓이고 복잡하게 꼬이게 됩니다.
정 어렵다면 내부적으로 소스관리와 배포를 담당할 사람을 정해 놓는게 좋습니다.
만약 회사 규모가 전산 감사의 대상이 된다면 이 부분은 감사기간에 증빙을 해야 하는 부분이기 때문에 고려 하시는게 좋겠네요.
개발 소스와 운영 소스는 동일해야 합니다.(동일 함을, 동일하게 관리 되고 있는 것이 감사 대상입니다.)
시스템의 차이 때문에 별도의 설정이 필요한 경우는 설정 파일로 분리 시켜야 하고, 운영 시스템에 배포된 소스는 운영 부서에서만 수정 할 수 있는 권한을 가지는 거죠.
운영 부서에서 개발 소스를 check out 하거나 build 해서는 안됩니다.
개발 부서에서 운영 소스를 패키징 해서 운영부서에 설정에 대한 문서와 함께 전달하고 운영부서에서 배포를 하는 거죠.
이런 프로세스 자체가 감사대상이고, 점점 더 강하게 요구하고 있습니다.
shockyhan님의 글처럼 개발 편의성으로만 접근 해서는 안됩니다.
아무리 훌륭한 기술로도 적절하지 못한 절차를 해결 해 줄 수는 없지만,
적절한 절차는 훌륭한 기술로도 해결 하지 못하는 문제를 해결 할 수 있습니다.
소스 관리는 이런 관점에서 접근 하셔야 할 것 같습니다.
조직이나 서비스 규모가 이런 것을 고려할 규모가 되지 않는다면 제 글이 별로 의미 없는 내용일 수도 있겠지만,
참고가 되실까 해서 남김니다.
답변은 안올려주셔서
예를 들어 a.cfg 라는 컨피그 파일이 있으면, a.cfg.template 이라는 식으로 "템플릿" 을 만들어서 이걸 버전 컨트롤에 올리고, 새로 들어온 개발자가 체크아웃을 하면 이 파일들을 카피해서 a.cfg 로 사용합니다.
그 다음 svn propset svn:ignore 를 이용해서 a.cfg가 commit 되는 것을 막으면 됩니다. 그럼 svn stat을 해도 ? 로 보이지 않습니다.
만약 svn stat 으로 무시된 파일들도 보고 싶으면 svn stat --no-ignore 하면 됩니다.
댓글 달기