모든 사람들이 직장에서 오픈 소스 통합을 어떻게 관리합니까? 예를 들어, 작업장의 요구에 따라 변경된 내용이 오픈 소스 프로젝트로 변경된 다음 병을 통해 주 코드 라인으로 통합됩니다. 최소한의 두통으로 모든 로컬 변경 사항을 원활하게 적용하는 오픈 소스 프로젝트의 새 버전을 통합하는 가장 좋은 방법은 무엇입니까? SVN은 Vendor branches 컨셉/프랙티스를 가지고 있지만 소스 제어 시스템이 다른 경우 어떻게해야합니까?오픈 소스 통합 관리
오픈 소스 프로젝트는 기부금을 기쁘게합니다. 오픈 소스 소프트웨어의 기능을 향상 시키려면 일반적인 용도로 사용하십시오. 개발자가 소프트웨어를 지원하는 커뮤니티에 참여하고 이러한 변경 사항을 프로젝트에 제공하십시오.
사용자 정의 기능 a, b 및 c가있는 버전 1.1.2를 사용한다고 가정 해 보겠습니다. 이 조언을 따르는 경우, 프로젝트가 버전 1.2.0을 릴리스하면 기능 a, b 및 c가 기본 배포에 포함되어 있으므로 그대로 채택 할 수 있습니다.
오픈 소스 프로젝트가 성공하고이 모델을 번창합니다. 이 방법으로 기부금을받지 못한 프로젝트는 종종 생존하지 못합니다. 그 때문에 기여할 수있는 인센티브는 2 배입니다 :
이러한 종류의 품질 보증에는 몇 가지 계층이 있습니다.
오픈 소스 자격.
OS 구성 요소가 실제로 작동하는지 테스트해야합니다. 대부분 구성 요소와 함께 제공된 테스트 실행과 관련이 있습니다.
그러나 특정 기능이나 API가 필요할 수도 있습니다. 구성 요소가 기대하는 바를 수행하는지 단순히 설정하는 테스트가 있어야합니다.
개발 통합 테스트.
오픈 소스 구성 요소를 사용하는 개발자는 새 릴리스의 특정 새 기능이 필요할 때 통합 테스트를 수행합니다.
OS 라이브러리가 업그레이드 된 경우 사용자는 업그레이드를 "의무"로하지 않습니다. 결국, 당신은 지원비를 지불하지 않습니다. 당신은 그 근원을 가지고 있습니다. OS 구성 요소의 사본을 "자동으로"업그레이드 할 이유는 없습니다.
생산 통합 테스트.
오픈 소스 구성 요소를 업그레이드 할 때 응용 프로그램과의 통합 테스트를 수행해야합니다. 이 방법이 작동하고 프로덕션 환경으로 전환되면 모든 개발자가 동일한 업그레이드를 수행해야합니다. 칠판에 걸쳐.
구성 관리는 매우 간단합니다. 원본 배포본 전체는 리포지토리에 저장 (수정되지 않음)되어 있어야하며 응용 프로그램의 일부로 수정되지 않은 상태로 배포되어야합니다.
오픈 소스 배포판의 각 버전은 별도입니다. 당신은 당신이 사용하고있는 각 버전을 유지해야 할 것입니다. 그리고 당신은 그것들을 분리하여 보관해야합니다.
/opt/some-package/some-package-1.1/
/opt/some-package/some-package-1.2/
etc.
각 개발자는 적절한 설치를 수행해야합니다. 통합 테스터 역시 마찬가지로 적절한 설치 작업을 수행해야합니다. 생산은 또한 통합 테스트가 통과되면 OS 패키지 설치를 수행해야합니다.
예, 패키지의 여러 버전을 여러 위치에 배치합니다.
예, 프로덕션 업그레이드가 업그레이드를 수행하는 각 개발자에게 직접 연결되는 것을 확실히 알아야합니다. 각 개발자가 올바른 OS 구성 요소 집합을 갖출 수 있도록하려면 버전 번호 감사가 필요합니다.