■소개

현재, 참가하고 있는 프로젝트가 설계서의 관리를 파일 서버만으로 실시하고 있어,
매우… 매우 불편하게 느껴졌기 때문에, 이 기사를 남깁니다.

개요

참여 프로젝트

・모 Web사이트 3기 추가 개발 안건
1기 개발 중반부터 참가를 해, 그대로 2기, 3기와 계속해서 착임하고 있다.

■ 원래 버전 관리가 필요한 이유

다음과 같은 디렉토리를 본 적이 있습니까?


추가로 개발 안건이 늘어나거나 단계 릴리스하는 프로젝트라고
이러한 디렉토리 구성으로 되어 있는 파일 서버를 자주 볼까 생각합니다.

"bk"폴더라든지 "old"폴더라든지 과거 자료 들어 있다든가
개변 이력마다 볼 때마다 화려하게 되어 가는 자료 등도 본 적이 있는 사람도 있을까 생각합니다.
(원래 본 폴더의 파일명에 날짜가 있는 설계서등도 본 적이 있습니다…)

파일 서버 관리의 단점

· 최신 문서가 무엇인지 모르겠다.
"사용자의 문의로 현재 릴리스하고있는 사양의 확인
차기 개발을 위해 갱신하는 문서가 어느 것인지 한눈에 모르는 경우가 발생할 수 있다.
그 때문에, 쓸데없는 시간의 로스나 실수로 낡은 분의 문서를 수정해 버릴 우려도 있다.

· 시계열로 문서를 관리하는 것이 어렵습니다.
로컬로 떨어 뜨리고 업데이트하는 작업자
장애 대응으로 어느 시점에 전기 분의 디렉토리에있는 자료가
갱신되고 있는 등으로 되돌아가 일어나 버린다.
또한 변경 이력에 상세하게 변경 내용을 기재하고 있어도, 수작업에 의한 이력 관리에서는,
역시 실수나 누설에 의해 충분히 관리할 수 없는 경우가 적지 않다.
누구의 지적으로 어떤 흐름으로 변경이 가해 졌는지를
순서를 쫓아의 확인이 리뷰 지적 일람이나 의사록 등
다른 자료를 보면서가 아니면 정확한 곳을 모른다.

・무조작으로 복사되어 서버 용량을 압박한다
위의 이미지와 같은 디렉토리 구성이라면 이번에는 "2020 년도"폴더에
「2019년도」폴더의 자료를 카피해 추가 요망이 발생한 기능의 설계서를 고쳐…
　　와 파일 서버를 압박한다.
하지만 과거 시점의 문서는 남겨두고 싶기 때문에,
불필요한 폴더를 압축해 서버 용량을 어떻게든 확보한 경험도 있습니다.

·보기 쉽습니까?

■ 버전 관리 도구

추가 예정