다음 트리에 구성된 프로젝트가 있습니다.
|.
|..
|-- devops
|-- project1
|-- project2
devops 폴더에는 다른 두 프로젝트를 하위 모듈로 포함했습니다.이 두 프로젝트는 두 팀이 독립적으로 개발하기 때문입니다.
|.
|..
|-- project1@0deed0fa
|-- project2@0beef0fb
|-- .gitlab-ci.yml
프로젝트를 배포하기위한 파이프 라인을 설정했습니다. 프로젝트에 새 커밋이있을 때마다 devops프로젝트 파이프 라인 을 실행하기위한 트리거가 설정됩니다 . devops 작업의 일부로 git submodule가져 오기 및 병합 명령을 실행 합니다. 그런 다음 빌드하십시오. 효과가있다.
내가 가진 문제는 일정 기간 동안 서브 모듈에 많은 변경 사항이 있다는 것입니다. 마지막 서브 모듈 커밋에서 devops 프로젝트 폴더로의 변경 사항은 프로젝트에 커밋이있을 때마다 재생됩니다. 한 달에 한 번 devops프로젝트 폴더를 수동으로 업데이트 하고 하위 모듈 프로젝트의 최신 커밋 으로 업데이트합니다 . devops 파이프 라인 작업에서 변경 사항을 커밋 할 수 있지만 동일한 devops 파이프 라인에 새 파이프 라인이 생성됩니다. (나는 그것을 테스트하지 않았지만 분명해 보입니다).
devops 파이프 라인의 일부로 하위 모듈을 최신 커밋으로 업데이트 할 수있는 방법이 있습니까?
감사.
git 하위 모듈을 사용하는 것은 통합 파이프 라인을 구현하는 모범 사례가 아닙니다. 중요한 책 Continuous Delivery 는 섹션 Only Build Your Binaries Once(5 장) 에서 다음과 같이 설명합니다 .
많은 빌드 시스템은 버전 제어 시스템에 보관 된 소스 코드를 여러 단계의 표준 소스로 사용합니다. 코드는 커밋 프로세스 동안 다른 컨텍스트에서 반복적으로 컴파일됩니다. 다시 승인 테스트 시간에 [등] 코드를 컴파일 할 때마다 약간의 차이가 발생할 위험이 있습니다.
또한 다시 컴파일하는 데 많은 시간이 걸리므로 피드백주기가 더 길어집니다. 권장 사항은 다음과 같습니다.
빌드의 커밋 단계 동안 바이너리를 한 번만 빌드해야합니다. 이러한 바이너리는 파이프 라인의 나중 단계에서 쉽게 검색 할 수있는 [...] 파일 시스템에 저장되어야합니다.
이 패러다임을 따르면 워크 플로는 다음과 같습니다.
project1하고 project2커밋 밀어 버린다release소스 코드가 어떻게 한 번만 빌드되는지 주목하십시오.
많이 사용되는 바이너리 저장소가 많이 있습니다. 대부분은 무료 및 유료 프로 버전이 있습니다. 자세한 내용은 웹 사이트를 확인하세요.
이 기사는 인터넷에서 수집됩니다. 재 인쇄 할 때 출처를 알려주십시오.
침해가 발생한 경우 연락 주시기 바랍니다[email protected] 삭제
몇 마디 만하겠습니다