메이저 패치와 마이너 패치 시 소스 관리
김정훈
semtl...@gmail.com
김우승
내용으로 봐서는 major 버전변경이 생길 때 분기를 하는 것 같은데요.
아니면 major 버전변경관리를 source의 compile time이나 run time에서 인식해서 동작하도록 작업을 하신 것인지요?
만일 source에서 분기동작을 하는 것이라면 개발기능이 들어가는 것은 개발팀의 실수일 뿐입니다.
그것은 개발팀이 좀더 세심한 주의를 해야하는 문제겠지요.
확실히 버전관리시스템의 분기기능은 작업이 번거롭게 만드는 것이 사실입니다.
1주일마다 minor 버전변경이 생기면서 그것이 배포된다면 많은 작업부담이 있을 것입니다.
제품이 어떤 것인지는 모르겠지만 1~2달 사이의 major 버전변경도 상당히 빠른 것 같은데요.
Google Chrome이 상당히 빠른 major 버전변경을 한다고 생각하는데 6개월마다 major 버전변경을 하겠다고 했다지요.
만일 솔루션 제품이고, 배포된 major 버전에 대해서 장기적인 유지보수를 해야한다면 저는 버전관리시스템의 분기기능의 사용은 반대하고 싶습니다.
XPE에서 Kent Beck은 버전관리시스템의 분기기능에 대해서 그다지 좋게 평가하지 않았던 것으로 기억합니다.
저는 형상관리, 버전관리에 경험은 별로 없지만 source에서 분기동작을 하도록 추천하고 싶습니다.
Youngrok Pak
그리고, 릴리스를 자주하는 이유는 자주 고객의 피드백을 받아서 개선하기 위함인데, 오히려 주간 릴리스로 불안정한 버전을 릴리스하느니 차라리 월간으로 안정적인 버전을 릴리스하는 것이 훨씬 좋을 겁니다.
브랜치도 물론 해결책 중 하나입니다만, 이도저도 안될 때 최후의 수단으로 생각하는 것이 좋습니다. 심각한 생산성 저하가 발생할 것이고 최악의 경우 버전마다 담당자가 따로 필요해질 수도 있습니다.
굳이 브랜치를 따야 한다면 마이너 패치를 trunk에서 작업하는 것이 더 바람직합니다. 마이너 패치는 전후 버전에 다 적용되는 반면, 메이저 패치는 새 버전에만 적용되기 때문에 진짜 trunk에 있어야 할 것은 마이너 패치죠. 차라리 새로운 기능을 브랜치 따서 작업하고, 완료하면 trunk로 머지하는 것이 더 좋습니다. 이 방식은 적어도 브랜치가 일시적으로만 존재하면 되기 때문에 브랜치가 아예 없는 것보다야 못하지만, 상설 브랜치보다는 낫죠. 어쨋든 브랜치는 필요악이기 때문에 어쩔 수 없을 땐 쓰되, 최소화하는 것이 좋습니다.
그리고, 같은 개념을 조금만 틀어서 적용하면, 새 버전에 들어갈 기능을 빌드 옵션에서 on/off로 끌 수 있게 하면 전부 trunk에서 작업할 수도 있습니다. 물론, 이런 빌드 작업이 오류 없이 정확하게 되어야겠지만요.
Chang Min Jeon
--
Spread Great Software to the world.
my dream
강석천
> 작업을 해달라고 강력하게 요구하고 있는 상황입니다.
QA 쪽에서 이렇게 요구하는 이유는 어떤 것인가요?
yagur
On 9월9일, 오후10시48분, 김정훈 <wond...@gmail.com> wrote:
> 저희 회사에서 최근에 주별 릴리스를 하기 위해서
> 1주일에 한번씩 마이너 패치를 하고 1-2달 사이에 메이저 패치를 합니다.
>
> 문제는 마이너 패치를 할 때 메이저 패치 때 들어갈 개발중인 기능이 들어가거나
> 검증되지 않은 기능이 들어간다는 점입니다.
>
> QA쪽에서는 trunk에서 직접 작업을 하지 말고 마이너 패치 할 내용은 메이저 패치 때 브랜치를 딴 내용에서
> 작업을 해달라고 강력하게 요구하고 있는 상황입니다.
>
> 사실 브랜치를 생각해보지 않은 것은 아니나 브랜치를 따게 되면 버그를 수정할 때 트렁크와 브랜치 양쪽에
> 동시 작업을 해야 하니 작업량이 늘어나고 리팩토링 등을 통해 한쪽의 구조가 바뀌면 양쪽에 작업하는 것이
> 더욱 어려워집니다.
전 QA쪽 말이 맞는것 같습니다. 핫픽스가 리팩토링과 같은 구조적 문제 때문보다, 다른 문제일 경우가 더 많으니 브랜치를 통해
수정해도 머징할때 심각한 컨플릭트가 날것 같진 않습니다. 본연의 목적인 버그 수정은 개별적 브랜치를 통해 달성하는 것이지요.
리팩토링을 통한 구조변경에도 브랜칭이 더 좋을것 같습니다. 문제별로 독립적 분기가 존재하기때문에 어떤 문제가 구조적 영향을 받느
지 알수있기때문이죠. 그에 따라 대처하시고 순차적으로 머지하시면 됩니다.
여러 메이저 버젼이 존재한다면 마이너 패치는 각 버젼별로 해주실것인가요? 구조가 다르면 마이너 패치 역시 각각의 형태로 적용
될 가능성이 있어보입니다만, 심각한 컨플릭트가 있다면 이미 브랜칭해 해결한 문제를 또 분기해서 구조변경에 따라 대처해주시고,
새 메이저 버젼에 머지하시면 되지 않을까요.
새기능도 브랜치를 만들어야한다고 생각합니다. 구조변경할동안 새기능 추가를 멈추실것인가요? 동시 진행하실것이면 스테이블 버젼에서
개발하고, 머지하셔야 될것 같습니다. 모듈의 독립성을 높다면 충돌이 적겠죠.
김정훈
김정훈
송영빈
--
-------------------------------------------------------------------
항상 레몬을 가지고 다닐것
수진이아빠, 시화남편, 송영빈
경치를 보기위해 브래이크를 밟을수 있음
김정훈
강석천
일단 전제를 버그 픽스 발생시에도 이전 릴리즈 버전에 대해 버그 픽스 반영을 할 필요가 없다라는 전제로 이야기하면요. (만일
DBMS 같은 경우 고객의 마이그레이션 이슈 때문에 이전 릴리즈 버전에도 버그 픽스 들어가는 경우가 있습니다)
* QA 쪽은 개발실에서 프로세스 변경된 것에 대해 같이 쫓아가지 못하는 것에 대한 부담감도 있을 듯 합니다. 1명이고, 릴리
즈 주기가 짧아질 수록 자기 업무 부하가 느는 구조인데, 현재 QA 앞의 throughtput 이 올라갔는데 QA 쪽은 인력 추
가가 없어서 해당 일을 감당할 양이 아니니 앞에 검증 대상이 재고처럼 쌓이는 상황 같아보입니다. QA 입장에서는 자기가 병목이
되었으니 개발실에서 릴리즈 주기 줄인다고 하면 보통때에도 그렇겠지만 더욱더 '최대한 완벽하게 해서 일이 없게' 주기 원할 것 같
습니다.
QA 생산력이 높아지거나 (인력 투입, QA 테스트에 대한 자동화, QA 검증을 개발팀에서 일부 맡아준다던지 등등) 앞의
재고가 적거나 해야 할 것 같습니다. (다시 릴리즈 주기가 길어지거나, 결함이 적게 된 결과물로 나가거나)
* 사람들이 trunk 의 용도에 대해 어떻게 생각하는가가 궁금한데요. 일단 trunk이건 branch 이건 저장소의 상황이
자주 바뀌고 싱크가 잦은 쪽은 어떻게든 불안할 수 밖에 없을 겁니다. 현재 해당 기능 작업 (이슈트래커 기준 이슈 하나)에 대
해 완료가 되지 않은 상황이여도 트렁크에 커밋하고 있는 상황이라면 (중간 백업용을 위한 커밋) 트렁크 변경 내용이 많을 수 밖
에 없을 것 같습니다. 이런 경우이면 #if 로 해당 코드를 열고 닫고 하면.. 꽤 복잡할 것 같습니다.
trunk 를 배포용으로 쓸려면, 개발자들이 trunk 를 '개발 중 임시 저장소' 로 생각하고 사용하시면 안될 겁니다.
redmine 이나 trac 의 이슈 기준으로 커밋할 때에도 이슈 단위로 완료 될 때만 커밋해야 할겁니다. 그렇지 않으면 해당
코드 변화 대비 관련 이슈에 대한 트래킹을 하기가 어렵고, 위에서 언급하신 패치에 포함될 예정이 없던 리소스가 커밋되는 일이 생
길 수 있습니다. 그런데 이렇게 정책을 취하면 1주 이상 걸리는 이슈 작업에 대해 사람들이 로컬카피 생기고 하는 문제가 생깁니
다. 그래서 이런 이슈들에 대해서는 별도 branch 를 나누고 작업을 한 뒤 trunk 와 로컬에서 merge 해서 문제없는
지 확인해보고 trunk 에 통합합니다. branch 내에선 임시 커밋이건 기능 단위 커밋이건 해당 branch 를 관리하는 서
브팀/개발자 소관이므로 좀 더 자유로이 사용이 가능합니다.
* 한번에 동시에 진행되는 이슈의 수가 어떻게 되는지 궁금합니다. 동시에 병렬로 진행되는 이슈가 많을 수록 동기화 문제가 커질
겁니다. 이를 해결하려면 병렬 처리되는 이슈 수를 줄이거나 (pair 나 팀으로 묶어서 버그 수정 및 기능 작업), 아니면 앞에
서 언급한대로 3일 내로 잡히는 버그는 trunk 에 적용하고, 1주일 이상 걸리는 기능 추가에 대해 브랜치를 나눈 뒤 해당 작
업이 완료될 때만 trunk 로 머지하여 trunk 에의 커밋되는 수를 줄이고 커밋되는 코드 단위를 이슈 해결을 위한 단위로 보
이게끔 하는 것은 어떨까 합니다. (추적성 면에서 이를 선호하는 팀도 있습니다)
김홍식
2010년 9월 12일 오전 8:43, 강석천 <free...@gmail.com>님의 말:
--
---------------------------------------------------------------------------------------------
Korea Polytechnic University/Computer Engineering Department/
Adjunct Professor/
Hong Sik Kim
429-793
2121 Jungwang-dong, Shihung-city, Kyonggi-do, Korea
TaskForce Systems/Director/EA Senior Consultant
Enterprise Architect /
GIS Auditor/CISA / CMMI / SPICE
Information System Auditor Certified by
National Information Society Agency
137-855
722 Seocho officetel 1302-1 Seocho-dong Seocho-gu, Seoul, Korea
Tel: 822-3476-8250/Fax: 822-3476-8255
Mobile: 8211-274-7274
e-mail: hski...@gmail.com
: hski...@kpu.ac.kr
------------------------------------------------
강석천
는 export된 lookup 함수를 추가하거나, 체크섬 정보 등)를 집어넣으시는지 궁금합니다.
On 9월11일, 오후3시47분, 송영빈 <songyoung...@gmail.com> wrote:
> trunk는 여러 개발자들이 수시로 체크인아웃을 해야 하니까 이 trunk를 자동 배포하면 당연히 통합 테스트되지 않은 코드가
> 배포되겠죠.
> 그런데 또 문제는 그럼 통합테스트에 통과한 코드만 따로 branch로 만들어 관리해야 하느냐 인데요.
> 여기서 복잡한 문제가 생깁니다.
>
> 답은 없구요. 제가 지금 하고 있는 프로젝트에서 하고 있는 방법을 설명해 드리겠습니다. 이건 svn하고는 전혀 상관없습니다.
>
> 0) 개발자가 수정된 모듈을 배포테스트서버에 수정됨 모듈만 선별적으로 카피한다. 즉 자동이 아니라 수동
> 1) 개발자가 PL에게 수정된 모듈을 설명하고 결재서류에 사인받는다. 이때 PL은 배포테스트서버에서 테스트를 1회거친다
> 2) 개발자가 PM에게 수정된 모듈을 설명하고 결재서류에 사인받는다. 이 때 받는 서명은 사실 거의 의미없다. 상징적인거다.
> 3) 개발자가 필요하면 DBA에게 관련 스토어드 프로시저등의 업데이트를 요청하고 결재서류에 사인받는다.
> 4) 개발자가 SM에게 수정된 모듈을 설명하고 결재서류에 사인받는다.
> 5) SM이 배포담당자에게 배포요청한다.
>
> 이방법은 바이너리 전체를 배포하는게 아니라 필요한 바이너리만 최소한으로 배포하는 방식을 쓰다보니 발생하는 사고들을 방지하기 위해
> 마련되었습니다. 최대한 여러사람의 리뷰를 거치게 하겠다는게 이방법의 핵심입니다. 그런데 이방법은 1회 수정을 패치하는데 발생하는
> 개발외시간이 무지 많이 걸립니다. 결재서류만드는데만 1시간이상이 걸리고 결재담당자가 최대 4인인데(본인빼고) 이 사람들이 다 자리에
> 있는것도 아니여서 실제 진득하게 테스트하는 건 기대할수 없습니다.
>
> 단, 결재서류만들고 배포테스트서버를 별도로 운영하면서 개발자 본인이 스스로 배포직전에 문제를 깨닫게 되더군요. PL과 SM이 실제로
> 테스를 정성껏 해주는 케이스는 기대할 수 없습니다. 왜냐하면 이들의 업무량은 이미 살인적이거든요. 전문 테스터가 필요합니다.
>
> 또 이방법은 매우 심각해질수 위험이 하나 있는데요. 매번 전체를 릴리즈하는게 아니면서 어느 순간 어떤 바이너리가 어떤 버전까지
> 릴리즈된건지 알수 없는 사태에 이를 수 있습니다. 바로 개발서버에서는 전혀 문제가 없는데 운영서버에서만 문제가 있는데, 관련 바이너리를
> 아무리 배포해도 문제가 해결되지 않는 현상입니다. 이때는 전체 바이너리의 재배포가 불가피합니다.
>
> 이상 나이스하지 않지만 실제로 이루어지고 방법의 소개였습니다.
>
> 2010/9/11 yagur <yagurc...@gmail.com>
김정훈
김정훈
김정훈
강석천
요.
브랜치의 경우, 기간이 길어져 trunk 와의 차이가 클 수록 merge 때 시간이 많이 걸리고 버그가 유입될 가능성이 크다는
문제가 있습니다.
그래서 브랜치로 작업하실 때에는 1-2일 정도 짧은 단위로 trunk -> branch 로 자주 merge 하시면서 통합시 발생
할 문제들을 미리 발견하고 보완하셔야 합니다.
그리고 최종 기능 구현 완료 뒤 머지할 때 자동 통합 테스트들이 있으면 좋고요. 테스트가 없어서 용기가 나지 않는다면
팀 간 코드리뷰 등 다른 안전장치를 도입하는 방법이 있습니다. 페어를 하신다면 팀 간 페어 교체가 통합 관련 여러 문제를 미리
드러나게 해줄 수 있을겁니다.
On 9월12일, 오후8시19분, 김정훈 <wond...@gmail.com> wrote:
> 제가 아는 바로는 없는 것으로 알고 있구요.
> 참고로 언어는 자바를 이용하고 있습니다.
>
> 2010년 9월 12일 오후 4:24, 강석천 <free1...@gmail.com>님의 말:
김홍식
형상관리는 익히 잘 아는 내용은 아니며 소프트웨어 프로젝트 관리에서
가장 어려운 분야로 알려져 있다고 보입니다. 가지고 있는 자료를 통해서
형상관리에 대한 내용을 공유하도록 하겠습니다.
다음 내용은 형상관리에 대하여 선진 미국의 사례입니다...!!!
보잉사의 2004년도 실무 자료 중 형상관리에 대한 내용입니다...!!!
우리나라와는 많은 차이가 있겠지만...그저 참고할만은 하다고 보입니다.
다음 내용을 보면 대충 형상관리자의 역할을 이해할 수 있으리라 보입니다.
저의 형상관리에 대한 경험은...?
실제로 어느 프로젝트(약 30억 정도의 공공 기관)에서 QA 를 담당하여 형상관리까지
손을 대 보았으나 이건 정말!!!...!!! 형상관리 툴을 사용하더라도 프로젝트에 참여하는 모든 이해관계자들이 모두 형상관리에
훈련되어 있고 또 형상관리를 당연히 수행할 정도로 성숙되어 있지 않으면 쉽게 되지 않겠다는 교훈을 얻은바 있습니다...!!!
우리나라에서, 특히 규모가 작은 회사에서는 통상 잘 하지 않는 분야이며 규모가 큰 회사나 프로젝트라도 구현하는데 가장 어렵게
생각하고 있는 분야라고 알고 있습니다만 아무튼 다음 내용을 참조바랍니다.
단지, 규모가 크건 작건 간에 소프트웨어 제품 품질 보증을 하기 위해서는
어느 정도 적절한 형상 관리를 해야 하는 것은 공통적이라고 보입니다.
따라서, 보잉사처럼 큰 회사에서 엄격한 형상관리체제에 따라 형상관리를
수행하는 대신 규모에 적절하게 필요한 정도의 형상관리 원칙을 적용하는
것은 필요하지 않을까 생각해 봅니다...!!!
감사합니다...!!!
---------------------------------------------------------------------------------------------------------
1. Configuration Management
Purpose
Establish and maintain the integrity of work products using configuration
identification, configuration control, configuration status
accounting, and configuration
audits
Meaning
Identifying configuration items/units
Systematically controlling changes
Establish baselines
Control changes
Maintaining integrity and traceability of the configuration
throughout the software life
cycle
Reporting accurate status to all stakeholders
2. The Need For Configuration Management
Have you experienced the following:
The latest version of source code disappears
A major bug that was fixed reappears
Wrong version of the code was tested
A fully developed and tested feature is mysteriously missing
A fully tested program suddenly does not work
No one knows which modules were delivered to customers
Undocumented features suddenly appear
3. The CM Disciplines
Configuration Management Planning
Configuration Identification
Change Management
Baseline & Integrity Control
Configuration Audits & Review
Status Accounting
4. Example Of A CM Plan
1) Overview
CM goals & objectives
Roles & Responsibilities
CM process, charter, members, training, tools
Product assurance relationship
2) CM process
Configuration items identification
Baselines and contents
Change management system
Auditing process
Status accounting process
CM support tools (CM tools)
3) CM Practices
Reference to organization standard, procedures, guidelines
CM forms and records
CM Checklists
4) CM implementation
Schedule, milestones, checkpoints
Status, reports
Audits, verification results
5. Support Environment
A baseline for all requirements, design, code, test, and tools
A control log that documents and describes all changes and revisions
A control environment where changes can be made in an orderly
fashion (e.g.,
check in/out)
A protected environment where the baseline is kept
A controlled environment where testing can be conducted
6. Baseline & Control
An example of a baseline is as an approved description of a product that
includes internally consistent versions of requirements,
requirements traceability
matrices, design, disciplines-specific items, and end-user documentation
Work products should be placed under CM control based on:
1) Stage of project lifecycle
2) When work product is ready for test
3) Degree of control desired on the work product
4) Cost and schedule limitations
5) Customer requirements
6) Supplier's delivery of sourcing work products
7. Examples Of Work Products Under CM Control
Plans (e.g., Project, QA, CM, Requirements)
Process description
Requirements (e.g., Documents, Specification, Change requests)
Design (e.g., Data Flow, Documents)
Configuration items identification
Drawings
Product Specifications
Product data files
Product technical publication
Code
Compilers
Reference to standard, procedures, guidelines
Audit forms and records
Formal review Checklists
Status reports
Verification results
8. Why Control Change ?
Configuration Management provides a stable working environment
Uncontrolled change of work products is a chaotic process
Configuration Management provides a "memory" of the status of
software work
products via baselines
Baseline is a specification or product that has been formally
reviewed and agreed
on; it serves as the basis for further work, and can only be
changed through formal c
change control procedures
9. Establish CM Records & Status
To maintain a consistent record of the status of all baselined items:
Time at which each baseline was established
Time at which each configuration item and change was included
Description of each configuration item
Status of each change (Approved, open, closed)
Description of the change
Documentation status for each baseline
Change log: History of the change
All change requests and/or discrepancy reports
Content of a release (Creation date, version, versions of related items)
10. Some People Believe That ...
Software is so adaptable that small changes can be achieved without any
significant impact
Lack knowledge of basic software project management
Do not recognize the composite effect of numerous in-work changes
Do not follow a disciplined process of cost and impact analysis
11. The Fact Is ...
Accept changes only after thoroughly analyzing the necessity
and impact on the
software project
Ensure all changes are under software configuration control
Establish project management disciplines
Assure all changes are under strict control of configuration management
Understand the impact of rework on completed components
Promote the design of a software architecture with flexibility
to accommodate
changes
12. Perform CM Audits
A CM audit should be performed periodically to ensure the CM practices
and procedures are consistently followed.
Internal audit (performed by CM staff)
External audit (performed by PPQA)
CM audit must be planned and scheduled (in CM plan)
CM audit must be performed before every major baseline change
CM audit team must be trained and NOT involved in tasks being audited
CM audit must verify that all changes to baseline are
implemented properly
CM audit must verify that the CM process is being followed appropriately
CM auditing is continuous throughout the life of a project
2010년 9월 12일 오후 8:18, 김정훈 <won...@gmail.com>님의 말:
YounJung Park
1주일이라는 기간은 버그픽스하고 테스트하고 패키징하고 빌드하고 하긴엔 꽤 짧은 시간인 것 같구요.
차라리 발생하는 이슈들을 누적해서 좀 더 긴 텀으로 가져가는게 어떨까 생각됩니다.
그리고 소스상에서 단순한 방식으로 if 조건에 의해 분기를 한다면 오히려 원본 소스의 복잡도가 더 올라가지 않을까 싶습니다.
물론 브랜치에 의한 머징의 부담이 있긴하지만 QA의 의견대로 trunk에서 패치작업 및 마이너패치태깅을 하고 trunk의 안정성에
문제가 될 수 있는 코드는 feature branch 에 커밋하고 주기적으로 trunk에서 branch로 머징을 한후 feature branch에 대한 검증이
끝났을 때 trunk에 머징 후 삭제하는 방식이 어떨까 싶습니다.
잘 아시겠지만 자주 사용하는 branch의 유형은 release branch, feature branch 가 있는데 저같은 경우 패키지의 사이즈가 그렇게
크지 않고 규모도 작아서 feature branch를 운영했습니다. trunk에서 feature branch로의 머징 주기는 3일에 한번 정도 였구요.
Version Control with Subversion online문서에 있는 Common Branching Patterns도 한번 참조해 보시길..
http://svnbook.red-bean.com/en/1.1/ch04s04.html
Jake Kim
저희는 promotion model 을 사용하고 있습니다. 박영록님께서 말씀하신 release branch 라고 하나요?
저희도 거의 일주일에 한번 (바쁜 주기에는 거의 매일) QA 로드가 있고 매달 관리 주기가 있습니다. 그리고 고객의 요구사항에
따라 수시로 로드가 생기기도 하죠.
저희는 DEV -> MAIN -> PROD 브랜치를 냅니다. 개발자들은 DEV 에서만 작업하고 해당 주에 QA 로 올라가야 할
부분만 MAIN 으로 머지가 됩니다. 그리고 다 통과가 되면 PROD 로 머지가 된 후 STG 과 production 으로 배포
가 됩니다.
김정훈님의 상황이라면 DEV 에서 major 브랜치를 내고 DEV ->MAIN 머지시에 Major 브랜치에도 머지가 이루어져야
할것 같습니다. 그런데 일주일에 한번 머지를 한다면 둘간에 충돌이 생길경우 이 작업만도 만만한 일이 아닐거란 생각이 드네요. 배
보다 배꼽이 더클수 있다는... 따라서 DEV 에서 Major 로의 머지는 수시로 하는 것이 작은 변화를 반영하는데 도움이 되
지 않을까 하는 생각이 듭니다. 그리고 한달에 한번있는 Major 패치시에는 DEV -major 머지는 계속 되어 왔으므로, 결
국 그주의 마지막 변화만 반영이 되면 작은 머지가 될 것 같구요.