git, maven 및 jenkins로 다음을 수행하는 선호되는 방법은 무엇입니까?
"dev"및 "release"분기를 유지하려는 응용 프로그램을 개발 중입니다. jenkins가 두 가지를 모두 구축하고 싶습니다. 릴리스 아티팩트의 버전은 1.5.2와 같고 개발 빌드는 0.0.1-SNAPSHOT입니다. 2 개의 다른 pom.xml 파일이 필요하지 않습니다.
프로파일을 살펴 봤지만 이슈 버전을 변경할 수없는 것 같습니다. 내가 본 한 가지 방법은 테스트 빌드에 'qualifier'를 추가하는 것입니다. 물론 앱의 독립 아티팩트 정보는 중요하지 않기 때문에 파일 이름을 바꿀 수 있습니다.
이 작업을 수행하는 데 선호되는 방법은 무엇입니까? 아니면 어떻게 하시겠습니까?
답변:
버전 번호의 문제를 해결해야하는 이러한 브랜치간에 고유 한 관계가 있어야한다고 생각합니다.
dev 브랜치에서 릴리스 브랜치로 프로덕션 준비 코드를 병합 한 다음 Maven 릴리스를 수행합니다 (Jenkins를 통해 또는 수동으로). 그러면 버전 번호가 다음 빌드로 자동 롤백됩니다. 따라서 코드 1.4.7-SNAPSHOT을이 분기에 병합하고 릴리스 및 잘라 내기 버전 1.4.7을 수행하면 Maven은 자동으로 작업 복사본을 1.4.8-SNAPSHOT으로 롤업합니다.
아직 트렁크 (또는 기준선 분기 등)를 릴리스의 장소로 사용하지 않는 경우 릴리스를 완료하자마자 트렁크를 업데이트해야합니다. 이는 버전 번호도 업데이트되고 있음을 의미합니다. 릴리스 브랜치를베이스 라인으로 간주하면이 단계는 문제가 될 수 있습니다.
개발 지점은 실제 생산 코드 를 최신 상태로 유지해야 합니다. 기준선 (또는 구현에 따라 릴리스 브랜치)에서 개발 브랜치까지 코드를 병합해야합니다. 버전이 1.4.8-SNAPSHOT으로 변경된 릴리스 프로세스 중에 발생한 pom 변경 사항이이 분기로 가져 오기 때문에 중요합니다.
내가 읽은 (내 조직의 프로세스뿐만 아니라) 읽은 것을 바탕으로 이것은 Maven 릴리스 및 스냅 샷을 상당히 표준적이고 효과적으로 사용하는 것으로 보이며 다른 지점에서 완전히 분리 된 버전 번호를 유지하는 대신 쉽게 말할 수 있습니다. 모든 1.4.7-SNAPSHOT 빌드는 실제로 1.4.7 릴리스의 바로 전임이었습니다. 그들은 관련이 있습니다. 이 지점들 사이에서 합병하지 않으면 SCM과 Maven 버전 관리가 잘못되고 프로덕션과 일치하지 않는 코드에 대해 개발할 위험에 처하게됩니다. , 프로덕션 등에 버그를 다시 소개합니다.
접근 방식을 재고하십시오.
릴리스 버전은 1.4.2를 사용하고 다음 개발에는 1.4.3-SNAPSHOT을 사용하는 것이 매우 일반적입니다.
릴리스 1.4.2 THEN 분기 를 유지 보수 해야하는 경우 1.4.2 아티팩트를 시작한 커미트에서 분기합니다.
그런 다음 Jenkins에게 리포지토리의 위치와 지점 이름을 알려주고 파일 세트가 체크 아웃되고 Jenkins에게 프로젝트에서 maven을 사용하여 빌드하도록 지시합니다.
참고 : 단일 pom.xml을 사용하여 실제 아티팩트를 빌드하고 다른 pom.xml을 사용하여 고객에게 전달할 실제 비트를 작성하는 것이 매우 유리하다는 것을 알았습니다.