많은 수의 Maven 아티팩트가있는 프로젝트 (내부적으로 생성 된 아티팩트뿐만 아니라 외부의 아티팩트)에도 전체 제품 릴리스의 일부로 내부 제어 아티팩트를 자동으로 릴리스하는 방법에 대해 설명합니다.Maven 아티팩트 릴리스 자동화
이 질문에 대해서는 Jenkins와 Maven 릴리스 플러그인을 사용합니다. 따라서 단일 아티팩트를 릴리스하는 작업은 자동화됩니다 (프로세스를 시작하는 작업은 수동 작업 임에도 불구하고). 그러나 릴리스 과정에서 변경된 모든 아티팩트를 릴리스하는 프로세스는 자동화되어 있지 않습니다. 즉, 각 아티팩트의 릴리스를 수동으로 시작해야합니다. 문제의 일부는 릴리스가 끝날 때까지 거의 아무 것도 릴리스되지 않고 모든 것이 SHAPSHOT에 남아 있다는 것입니다. 우리는 엄청난 구성 요소뿐만 아니라 수많은 구성 요소에 의존하는 수많은 응용 프로그램/서비스 (30 개 이상)를 보유하고 있습니다. 따라서 구성 요소를 선택하고 릴리스하는 경우 일뿐 아니라 따라야하는 릴리스 종속성 계층 구조가 있습니다 (즉, 다른 구성 요소를 사용하지 않는 구성 요소를 맨 아래부터 시작한 다음 모든 응용 프로그램/서비스가 작동 할 때까지 작업하십시오). 공개).
우리는 대부분 외부 아티팩트 종속성 및 내부 구성 요소 종속성의 버전을 제어하는 두 개의 공통 상위 폼을 사용한다는 점도 유의해야합니다. 구성 요소 및 응용 프로그램에 대한 일부 pom 파일은 이것을 무시할 수 있지만 이는 예외이거나 예외적이어야하며 양호하지만 일시적인 이유 여야합니다. 따라서 내부 아티팩트가 릴리스되면 해당하는 상위 종속성의 버전도 업데이트해야합니다.
제품의 릴리스 번호는 있지만 (물론) 다양한 pom 파일은 기술적으로이 버전 번호를 공유하지 않습니다. 이것이 사실은 아니지만, 소프트웨어의 일부가 수명 종료 시점으로 설정되면 미래에 업데이트되지 않으므로 제한된 개수의 아티팩트 버전이 현재 제품 버전과 일치하지만이 결국은 그렇지 않을 것이다.
이 프로세스를 자동화하는 방법에 대한 생각은 크게 감사하겠습니다. 또한 내가 설명한 내용을 소프트웨어를 관리하는 미친 방법으로 생각한다면 의견을 말하십시오. 고맙습니다.
몇 개의 내부 종속성이 있습니까? 내 회사에서 비슷한 문제가 있지만 마법 같은 해결책을 찾을 수 없습니다. 우리는 의존하는 프로젝트를 릴리스해야 할 때 모든 종속성을 릴리스해야합니다. – BrunoJCM