버전 제어 대 자동 배포 대 종속성 관리

Question

수백 대의 컴퓨터 (노드)로 구성된 분산 소프트웨어 시스템을 상상해보십시오. 노드는 스케줄 된 태스크를 자동으로 실행합니다. 수백 개의 작업이 있으며 모든 작업은 약 5-10 개의 노드에서 실행되도록 예약됩니다. 노드는 며칠 동안 중지 될 수 있으며 시스템에서 제거 될 수 있습니다. 모든 작업은 하나 이상의 소스 파일과 노드 별 설정 파일에 의해 정의됩니다. 이 코드는 특수 하드웨어가 장착되어 있고 작업을 실행하는 데 필요한 네트워크 컨텍스트가 있기 때문에 (원격 액세스를 사용하여) 노드에서 직접 개발 및 테스트됩니다 (개별 테스트 시스템을 구축하는 것은 너무 비쌉니다). 모든 작업의 ​​소스 파일은 공유 소스 파일 (라이브러리)을 참조하고 라이브러리는 다른 라이브러리를 참조 할 수 있습니다. 태스크와 라이브러리의 의존성 트리는 복잡합니다.

나는 distributed version control systems에 대한 경험이 없지만이 시스템은 DVCS 주위에 구축 될 수 있다고 생각합니다. 다른 라이브러리 및 다른 작업의 소스 파일에는 자체 저장소가 있습니다. 주어진 태스크를 실행하는 모든 노드에는 해당 태스크의 repo 인스턴스가 있어야합니다. 노드의 적어도 하나의 태스크가 사용하는 모든 라이브러리의 repo도 해당 노드에 있어야합니다. 개발자는 노드에서 로컬로 코드를 수정하고 commit 코드를 작성하고 DVCS 기술을 사용하여 다른 노드의 repos에 수정 사항을 배포합니다.

질문 # 1 어떤 다른 노드로 코드 변경을 배포 할 수있는 가장 좋은 방법이 될 것입니다?

몇 가지 가능한 시나리오 : 인스턴스를 같은 REPO이있는 모든 다른 노드에

1. 개발자 push 자신의 수정. (하지만 그들은 잊을 수도 있습니다.)
2. 노드가 자동으로 pull 다른 모든 원격 저장소에서 변경되며 update 자체입니다. (그러나 충돌이있을 수 있습니다.)
3. 각 repo에 대해 인스턴스 중 하나가 "참조"로 사용됩니다. 개발자 push이 인스턴스에 대한 수정 사항과 여기에서 자동으로 pull 초의 인스턴스가 있고 다른 모든 노드는 update 그 자체입니다. (그러나 참조 인스턴스를 갖는 노드는 중지 할 수 있습니다.)

질문 # 의존성을 처리하기 위해 2 어떤 것이 가장 좋은 방법은?

하나 이상의 작업 (또는 라이브러리)이 동일한 라이브러리를 참조하고 참조 된 라이브러리를 수정해야하는 경우 하나 이상의 참조 작업 (또는 라이브러리)이 작동을 멈출 수 있습니다 (dependency hell). 처음에 언급 된 버전을 고수하고 적절한 테스트를 거친 후 새 버전으로 업그레이드하는 것이 좋습니다. 즉, 동일한 소스 파일의 버전이 둘 이상 동일한 repo에 있어야하며 가능하지 않습니다. 추천 된 라이브러리의 새 버전에 대해 새 branch을 만들어야합니까? 그렇다면 추천 리포지토리는 어떻게 업그레이드해야합니까?

도움 주셔서 감사합니다.

Answer 1

분산 버전 제어 시스템에 대한 경험이 없습니다. 이 시스템을 DVCS를 기반으로 구축 할 수 있다고 생각합니다.

잘못된 느낌.VCS (SCM)는 버전 제어 시스템 (소스 제어 관리), 즉이다 - 트랙

• 역사적 측면에서
• 변경 대부분
복잡한 의존성이없는
• 같은 평면 배열 (일부 의존성은 여전히 ​​고려)
구성 관리 소프트웨어 등 배포 한 정책, 복잡한 의존성, 조건 기본적으로
0을 처리 -

당신은 도구의 another category에서 볼 수있다

당신 은 DVCS와 CM 몇 가지 반복를 얻을 수 있지만, 노력과 결과로