저는 주로 Java 응용 프로그램을 구축하는 회사에서 일하고 있으며 모든 사람이 SCM에 바이너리 파일 (종속성 및 최종 제품) 체크인을 중지하도록 설득하려고합니다.
그들은 그것이 나쁜 습관이라는 것을 알고 있지만 "작동한다"고 생각하며 많은 사람들이 Maven과 Ant 이외의 빌드 도구를 알고있을 때조차도 실제로 문제가되지 않습니다. PM과 프로그래머 (약 50 명)는 모두 반대 의견에 귀를 기울이고 백업 공간을 낭비한다는 사실을 인정할 준비가되어 있지만 습관을 바꾸려면 많은 노력이 필요하기 때문에 정말로 확신을 갖고 싶습니다. 변경을 지원하기 위해 어떤 인수를 사용합니까?
편집 : 좋아, 의존성 및 생성 된 파일과 같이 거의 변경되지 않는 파일을 구별하는 것이 좋습니다. 그럼에도 불구하고 나는 후자에 대한 이유에 관심이 있습니다.
답변:
저장 공간이 저렴하므로 파일을 체크인하거나 체크인하지 않아야하는 이유에 대한 설득력있는 주장이 아닙니다.
대신 SCM의 목적에 호소 할 수 있습니다. SCM에서 추적하는 각 파일은 팀이 수행하는 병렬 분산 변경 사항을 관리해야한다는 것을 나타냅니다. 두 팀원이 동일한 파일을 변경하려고 시도 할 때까지는 그 사실이 분명하지 않습니다. 이러한 변경 사항을 해결하는 것은 SCM이 실제로하는 일이므로 다른 개발자의 작업을 실수로 덮어 쓰지 않도록하고 변경 사항을 병합하는 프로세스를 자동화하기를 바랍니다.
일반 병합 도구가 병합 된 이진 파일의 작동 방식을 추측 할 수있는 방법이 없기 때문에 이진 파일을 병합하는 것은 일반적으로 어려운 문제입니다. 특정 파일 형식을 인식하도록 특별히 설계된 경우가 아니면 파일의 인덱스 또는 오프셋 포인터가 작동하는 방식에 대해 충분히 알 수 없습니다.
즉, 이진 파일을 직접 병합 한 다음 SCM에 파일이 병합되었음을 알려야합니다. 개발자가 수행하기 때문에 병합은 실제로 이전 체크인의 모든 변경 사항을 다루지 않을 수 있으며 파일이 이진 파일이므로 병합을 자동으로 확인할 수있는 방법이 없습니다.
미술 자산과 같은 프로젝트 소스를 실제로 나타내는 이진 형식의 경우 이는 불행한 일이지만 필요한 단계입니다. 그러나 빌드 출력은 소스가 아닙니다. 소스를 병합하고 결과 빌드 출력을 재생성 할 수 있으므로 병합 할 필요가 없습니다. 이러한 변경 사항을 추적하고 관리하는 것은 100 % 낭비입니다. SCM의 리소스를 많이 낭비하지는 않지만 허위 병합 실패를지나 개발자 시간을 낭비합니다. 개발자 시간은 매우 비싸고 낭비하는 것은 암입니다.
반면에 빌드 출력을 보관해야하는 특별한 경우가 있습니다. 배송 또는 배포 된 모든 버전의 프로젝트는 무기한으로 유지되어야합니다. 고객이 문제를 겪고있는 실제 빌드의 정확한 바이트 사본 바이트를 사용하면 고객이 보유한 정확한 버전을 가지게되므로 훨씬 쉽게 고객을 지원할 수 있습니다.
해당 백업은 일반적으로 다른 스케줄을 따르고 기본적으로 다른 구조를 가지기 때문에 소스 코드와 동일한 저장소에 있지 않아야합니다.
SCM 사용의 주요 장점 중 하나는 과거 어느 때나 시스템을 재구성 할 수 있다는 것입니다. 따라서 개정 번호를 확인하고 빌드 할 수 있기 때문에 최종 빌드를 SCM에 저장하는 것이 중요하지 않습니다.
종속성에 대해 언급했습니다 ... SCM을 설정하여 새로운 시스템 (개발 환경이있는)을 클린 체크 아웃하고 빌드를 수행하면 다른 것을 설치할 필요없이 시스템을 빌드 할 수 있어야합니다. 따라서 SCM에서 이진 종속성을 유지하는 것이 좋습니다. 라이브러리는 거의 변경되지 않으므로 공간을 많이 차지하지 않습니다.
거의 아무도 이것을하지 않습니다.
소스 파일과 객체 파일을 모두 포함하기 위해 중복 된 것 같습니다 (소스 파일이 반드시 필요합니다). 객체 파일은 불필요 할뿐 아니라 많은 공간을 차지할 수 있습니다. 회사에서 분산 SCM (Git, Hg, Bzr)을 사용하는 경우 해당 바이너리 파일을 모든 개발자에게 복사하여 저장해야합니다.