유지 관리 작업을 줄이기 위해 코드를 공유해야하는 몇 가지 응용 프로그램이 있습니다. 나는 stackoverflow와 웹 전반에 대해 많은 것을 읽으려고 노력해 왔으며 이것은 꽤 일반적인 문제이다. 나는 내가 좋아하는 대답을 찾지 못했다.TFS의 솔루션 간 코드
우리의 TFS 분기 구조는 다음과 같습니다. 우리는 개발, 메인 및 프로덕션의 세 가지를 운영합니다. 개발 지점에서는 모든 능동적 인 개발이 완료되고, 새로운 기능을 개발할 때 Main과 병합 한 다음 생산에 병합합니다. 프로덕션 지점은 항상 서버에서 실행되는 코드입니다. 다음 반복 전에 수정해야하는 버그를 발견하면 변경 사항은 main에서 수행되고 배포 할 때 Production과 병합됩니다. 코드를 공유해야하는 응용 프로그램은 공통 분기 계층 또는 공통 반복 일정을 공유하지 않습니다. 실제로 응용 프로그램 중 하나는 1 년에 한 번만 1 개월 반복됩니다. . (난 내가 몇 가지 해결책을 발견이 그 일을하는 종래의 방법에서 약간 다릅니다 내 연구하는 동안
을 알고,하지만 난 그들 모두에 문제가있는
진 공유 :. 공통의 하나 내가 찾은 방법은 컴파일 된 바이너리를 개발 브랜치 아래에있는 폴더로 분기하는 것이 었습니다. 제 문제는 공유 코드에서 버그를 발견하면 빨리 수정해야하며, 문제의 코드는 컴파일해야합니다. 우리는 공유 된 코드베이스에 대한 모든 변경을 수행 할 수있는 버그를 얻었습니다.
프로젝트 공유 : 여기에서 가장 큰 문제는 어떻게해야할까요? e를 수용 할 수있는 방식으로 나의 초기 아이디어는 새로운 반복이 시작되었을 때 메인 브랜치의 변경 사항을 공유 코드와 병합하여 업데이트하는 것이다. 메인을 개발 브랜치와 병합하여 버그 수정의 결과로 개발 브랜치를 업데이트하십시오. 그리고 공유 코드의 새 업데이트 버전을 개발 브랜치에 분기합니다. 하지만 중첩 된 분기를 만들 것이므로 TFS에서 지원하지 않는다고 이해합니다.
내 질문은 : 솔루션을 자주 유지하면서 공통 프로젝트를 공유 할 수 있고 공통 프로젝트가 변경되어서 새로운 버그가 도입 될 염려없이 메인 브랜치에서 버그를 수정할 수 있습니다. 그러나 여전히 공통 프로젝트의 버그를 수정하고 수정 사항을 공유 된 공통 프로젝트로 다시 병합 할 수 있어야합니다.
죄송합니다 - 영어가 좋지 않습니다 :(:(** ** 무엇 ** 당신 질문입니까?) 무엇을 묻고 싶습니까? TFS (?)와 분기의 구조에 대해 많이 설명하고 잃어 버렸습니다. 당신은 어딘가에 중간에 ... – Jasper
죄송합니다. 방금 약간의 질문이 추가되었습니다. – user1450824
서비스로/SOA가 더 나은 접근 방식이 될 수 있습니다. 다음 코드 라이브러리를 공유하는 경우 아마도 NuGet 패키지를 만들어 바이너리 어셈블리를 "공유"하려고 시도하지 마십시오. – Kane