소스 제어하에 프레임 워크 런타임을 저장하는 것이 좋은 방법입니까?

나는 많은 소프트웨어 상점 들이 바이너리를 소스 제어하에 두는 것을 알고있다 . 그러나 매장에서는 DirectX 런타임, CUDA, nVidia Optix 등 모든 프레임 워크를 저장소에 저장했습니다.

그것은 dev 머신 셋업을 더 쉽게 만든다고한다. 그러나 저장소를 크게 팽창시키고 관련이없는 이력으로 인해 부담이됩니다.

나는 그런 사용 패턴을 본 적이 없다. 좋은 습관이라고 생각하십니까?

[편집 :] 소스 제어 격리 된 타사 바이너리에 문제가 없습니다. 이 질문은 일반적으로 10 개 이상의 바이너리로 구성된 전체 프레임 워크 런타임에 관한 것입니다. 극단적 인 예로, Windows SDK를 사용합니다 (저장소에 보관하지 않고 고맙지 만 원칙적으로 차이는 없습니다).

바이너리는 일반적으로 다음과 같은 이유로 버전 제어 시스템에 적합하지 않습니다.

• 버전 제어 기능 (병합, diff)의 이점이 없습니다.
• 그들은 repo의 크기를 증가시킵니다 ...
• ... 간단한 공유 디렉토리 인 정리하기 쉬운 Nexus 와 같은 아티팩트 저장소 와 달리 VCS (VCS는 기록 을 유지 하기 위해 만들어 짐)에서 버전을 쉽게 제거하지 않기 때문에 중요 합니다 (정리하기 쉽습니다 : + !)cdrm
• 그것들은 VCS에서 텍스트 , 경로 + 버전 선언 으로 참조되어야합니다 : 당신 은 바이너리를 사용하는 경우 바이너리 버전의 변경 사항을 텍스트 파일의 변경 사항으로 기록합니다 (Nexus를 사용하는 경우 pom.xml과 같이) 예를 들어)

이진 애셋을 제어하는 ​​버전은 괜찮습니다. 생성 된 파일을 제어 하는 버전에 반대 합니다.

또한 환경 설정은 개발과 다릅니다. 우리는 주로 Python으로 개발하며 virtualenv라는 도구를 사용하여 프로젝트에 대해 경량의 격리 된 환경 (라이브러리 포함)을 만들 수 있습니다. 소스를 확인하면이 virtualenv를 빌드하는 설정 스크립트가 있습니다. 매니페스트를 사용하여 필요한 버전의 라이브러리 및 기타 사항을 지정합니다. 이 중 어느 것도 버전 제어되지 않습니다. 설정 스크립트 만 있습니다.

주요 프로젝트에서 전체 프레임 워크를 버리는 것은 역사를 혼란스럽게 만들고 일을 심각하게 망칠 것입니다. 프로젝트의 일부가 아니며 다르게 취급해야합니다.

일반적으로 프레임 워크 버전으로 구성 관리를 수행하는 것이 좋습니다. 코드에 특정 DirectX 버전이 필요한 경우 해당 버전을 쉽게 사용할 수 있어야하며 이전 버전의 소프트웨어를 확인하면 외부 종속성이 있는지 쉽게 확인할 수 있습니다.

여기서 좋은 생각이 아닌 것은 바이너리를 저장하기 위해 일반적인 버전 관리 시스템을 사용하는 것입니다. 회사에서는 모든 버전의 프레임 워크, 라이브러리 및 외부 도구를 네트워크 드라이브의 하위 폴더 구조로 저장합니다. 의미가 있다고 생각되는 경우, 어떤 툴 버전이 어떤 소프트웨어 버전에 속하는지 문서화하기위한 readme 파일이 있거나, 가능하면 특정 버전을 설치하거나 사용하기위한 스크립트가 있습니다. 해당 readme 파일과 스크립트 만 버전 관리에 들어갑니다.

또한 해당 도구에 따라 이전 버전을 다시 빌드해야 할 가능성이있는 한 이전 버전의 도구 및 라이브러리도 유지합니다. 이렇게하면 더 이상 사용되지 않는 네트워크 드라이브에서 오래된 라이브러리 및 도구 중 일부를 삭제할 수 있습니다 (물론 외부 미디어에 아카이브가있는 경우).

바이너리는 어딘가에 상점이어야한다고 생각합니다. 특히 저장소가 크거나 체크 아웃 시간이 길어지면 저장소 외부에 저장하는 것이 좋습니다. 나는 그것이 나쁜 연습이라고 보지 않을 것이지만, 내가 본 것도 아닙니다.

조직에 다른 런타임 버전을 대상으로하는 많은 프로젝트가있는 경우 실제로이 방법이 좋습니다. 올바른 프로젝트에서 작업 할 때 올바른 런타임 바이너리를 보장합니다.

나는 개인적으로 이것을 매우 나쁜 습관이라고 생각합니다. 설치 지침으로 위키를 설정하고 필요한 바이너리를 업로드하는 것을 선호합니다. 이 파일들은 새로운 개발자들에게만 필요하며 다른 사람들의 저장소를 팽팽하게 할 필요가 없습니다.

이를 수행하는 데는 정당한 이유가 있습니다. 즉 , 외부 종속성없이 단일 위치에 필요한 모든 것을 갖습니다 .

생각보다 훨씬 중요합니다. 기본적으로 모든 것을 사내에 가지고 있기 때문에 몇 년 후에 사라질 수있는 공급 업체 서버의 아티팩트에 의존하지 않도록합니다.

저장소 팽창과 관련하여. 복제 및 / 또는 업데이트 속도가 느리기 때문에 VCS가 전체 로컬 복사본을 유지하는 경우에만 문제가 발생합니다 (git은이 작업을 수행하지만 cvs는 지원하지 않습니다). 그 대가로 각 개발 머신에 사본이 있으며, 어떤 이유로 중앙 백업 구성표가 언젠가 실패하면 회사를 구할 수 있습니다.

우선 순위 또는 정책의 문제입니다. 결정이 고의적 인 한, 나는 이것으로 괜찮을 것입니다.