2013-02-15 3 views
2

우리 프로젝트 그룹은 우리가 SVN 저장소에서 작업 한 프로젝트의 바이너리 파일을 1 년 넘게 저장했습니다. 결국 저장소가 통제 불능 상태가되어 SVN repo 백업이 불가능 해졌습니다 체크 인 된 각 바이너리는 약 20MB이기 때문입니다.TFS 및 바이너리 파일 저장

이제 우리는 TFS로 전환했습니다. 우리는 저장소를 백업 할 책임이 없으며, IT 부서에서 처리하고 백업을위한 네트워크 및 스토리지 용량이 더 많습니다. 그러나 우리는이를 위해 무엇을해야할지 결정하고 싶습니다. 바이너리. 내가 아는 한 TFS는 델타와 바이너리 파일을 저장하지만 델타는 엄청 크지 만 어느 날 디스크 공간 할당량에 도달 할 수 있으므로 처음부터 더 나은 계획을 세우고 싶습니다. 문제를 해결하기에는 너무 늦었을 때 나쁜 상황에 휩싸였다.

소스 제어에서 빌드를 유지하지 않는 것을 선호하지만 프로젝트 그룹에서는 프로덕션 시스템에서 볼 수있는 문제를 재현 할 수 있도록 모든 바이너리 복사본을 보관해야하지만 소스 코드를 가져올 수는 없습니다. TFS, 그것을 빌드하고 이진 파일을 작성하십시오. 왜냐하면이 파일은 간단하지 않기 때문입니다.

TFS는 더 나은 빌드 버전 관리 방법을 제공합니까? 누군가가 통찰력을 공유 할 수 있다면 정말 감사 할 것입니다. 당신에게 도움이 될 수

답변

3

일반적으로 TFS에 빌드 출력을 저장하면 안됩니다. 때로는 많은 응용 프로그램에서 사용하는 공용 라이브러리 용 바이너리를 저장할 수 있지만 누젯과 같은 도구는이를 해결합니다.

빌드 출력은 수명이 다르고 각 단계는 별도의 장소에 저장해야합니다. 예 :

빌드 출력 : 코드가 빌드되면 (TFS/Jenkins/Hudson 등) 출력이 드롭 위치에 저장됩니다. 이 저장소는 많은 빌드를 생성 할 것이므로 휘발성을 고려해야하며 그 중 많은 부분이 삭제됩니다.

테스터에게 전달 된 빌드 : 다음은 매우 기본적인 품질 관리를 통과 한 빌드입니다. 그것은 컴파일, 정적 코드 분석 도구는 행복, 단위 테스트를 통과합니다. 일단 빌드가 테스트에 제공 될만큼 충분히 좋은 것으로 간주되면 드롭 위치에서 다른 영역으로 이동해야합니다. 이것은 네트워크 공유 일 수 있습니다 (빌드를 재현 할 수있는 생산이 아님). 프로젝트의 수명 기간 동안 승격되는 수많은 빌드가있을 수 있으며 각 환경에서 테스터의 버전을 추적하고 싶을 것입니다.

테스트에 통과했으며 현재 생산중인 빌드 : 테스트 팀은 빌드가 충분히 높은 품질의 것으로 간주합니다. 라이브 진행 과정의 일부로 테스트를 통해 서명 된 빌드를 가져 와서 3 번째 위치에 저장해야합니다. ITIL에서이 말은 Definitive Media Library입니다. 이 파일은 단순한 파일 공유 일 수 있지만 "프로덕션"으로 간주되어야하며 다른 프로덕션 시스템과 동일한 백업 및 복원성 기준이 있어야합니다.

DML은 프로덕션에있는 바이너리 (및 설치 지침, 기호 파일 등과 같은 관련 구성 항목)를 저장하는 장소입니다. 빌드를 생성하는 도구는 TFS에서 소스를 레이블링해야합니다. 바이너리를 생성하기 위해 어떤 코드가 사용되었는지 알아보십시오. 분기 전략은 코드에 바이너리를 연결할 수있게 도와줍니다.

"라이브와 같은"환경을 유지하는 것이 좋습니다. 이는 일반적인 개발 환경 및 테스트 환경과 분리되어 있어야합니다. 이름에서 알 수 있듯이 프로덕션에 릴리스 된 코드 만 포함되어 있습니다. 이것은 생산에서 버그를 재빨리 재현 할 수있게 해준다.

+0

훌륭한 설명을 주셔서 감사 드리며, 제작 또는 테스트 환경으로 이동하는 중요한 빌드 만 백업해야하며 TFS에서 백업해서는 안됩니다. 나는 그들을 설득하려 노력했다. 나는 길을 찾을 수 있기를 바란다. –

+0

파일 공유가 이것을 다루는 더 좋은 방법이다. TFS에 바이너리를 저장하면서 발견 한 문제는 때때로 변경을 감지하고 무언가 실제로 체크 인해야 할 필요가있는 바이너리 파일을 감지하는 알고리즘이 변경된다는 것입니다. 즉, 업데이트 된 버전의 이진 파일을 체크인해야 할 때 FORCE를 사용하여 실제로 체크인되었는지 확인해야합니다. – Alex

+1

Google을 통해 온 사람들에게만 실제 질문에 답할 수 있기를 바랍니다. 예를 들어 바이너리 소스 (PNG와 같은)를 저장하고 싶지만 지금은 "바이너리 파일 저장 방법"을 모른다. – Martin

1

두 가지 방법 :

  1. 사용하여 Team Foundation 빌드 시스템. 장점 중 하나는 완성 된 빌드의 보존 기간을 설정할 수 있다는 것입니다. 예를 들어 TFS에 최신 빌드 10 개를 저장하도록 요청할 수 있으며 실패한 빌드 2 개는 마지막으로 실패한 빌드를 저장합니다. 특정 빌드 (예 : "제작 빌드"/ 최종 릴리스)를 무기한 저장하도록 TFS에 지시 할 수도 있습니다. 이 바이너리 폴더는 물론 필요한 경우 외부에서 백업 할 수도 있습니다.

  2. 백업 스케쥴이 다른 (덜 빈번한) 바이너리에 다른 모음을 사용하십시오. TFS는 전체 모음을 백업해야하지만 소스만큼 자주 변경되지 않는 데이터를 분리하여 백업 비용을 낮출 수 있습니다. 이것은 물론 바이너리를 백업하는 데 필요한 빈도에 따라 다릅니다.

+0

약 1 번째 옵션 인 우리 IDE는 우리가 C++을 사용하는 데비안에서는 일식이고 Boost와 QT는 많이 사용하지만 TFS 서버는 Windows 서버이다. Team Foundation Build System을 사용하거나 TFS 서버 아래에서 동일한 환경을 만들어 빌드 시스템이 작동하도록해야합니까? 그렇다면 우리 기업에 하나의 TFS 서버가 있고 관료제가 많기 때문에 이것이 우리에게 도전이 될 것입니다. –

+0

두 번째 옵션은 동료들에게 옳은 일을하도록 설득했을 때 더 가능합니다. –

1
당신은 당신의 프로젝트 그룹을 특정 지점에서 소스 코드를 잡고 다음을 구축하고 위치에 드롭 할 수있는 쉬운 '하나 개의 버튼을'밀어주고 TFS의 정의를 구축 만들어 보길 원하는 것일 수도

. 그렇게하면 바이너리가 생기고 소스를 제어 할 필요가 없습니다.

프로덕션으로 릴리스 할 때 릴리스 또는 RTM 분기를 만드는 분기 전략을 사용하는 경우 해당 분기에서 빌드 정의를 가리키고 TFS 포털 또는 Visual Studio에서 수동으로 트리거 할 수 있습니다 .

+0

Eclipse와 Eclipse에서 빌드 정의를 작성해야합니다. 좋은 옵션 일 수도 있습니다. –