배포 스크립트가 빌드의 인공물이어야합니까?

이것은 Java로 작성된 웹 프로젝트입니다.

그래서 빌드 및 배포 스크립트를 작성하고 있습니다. 빌드를 만들기 위해 개미를 사용했습니다. 지속적인 빌드는 Jenkins로 수행됩니다.

빌드는 3 가지 다른 아티팩트를 생성합니다.

1. 전쟁 파일
2. 레이아웃이있는 지퍼
3. 이미지가 담긴 지퍼

지금까지는 훌륭했지만 이제는 배포 스크립트를 작성해야합니다.

• 서버 1 에서 실행중인 바람둥이에 전쟁 (아티팩트 1)을 배치하십시오.
• 서버 1 의 아티팩트 2 를 특정 디렉토리에 배치하십시오.
• 서버 2 의 아티팩트 3 을 특정 디렉토리에 배치하십시오.

그래서 나는 동료와 이야기하고 있었고 올바른 서버에 배치 할 때 이러한 아티팩트를 배치 하는 아티팩트 ( deploy.xml ) 도 생성해야한다고 말했습니다 .

따라서 다른 스크립트가 있습니다.

• 젠킨스 유물 다운로드
• 각 서버에 scp를 배치하고 deploy.xml을 거기에 배치하십시오.
• deploy.xml을 원격으로 호출

좀 불편한 것은 deploy.xml을 빌드 아티팩트로 사용하는 행위입니다. 이 배후의 동기는 VCS 리포지토리에 액세스 할 필요없이 배포를 수행 할 수 있도록하는 것이므로 빌드는 자체 포함됩니다. 즉, 모든 빌드는 Jenkins가 생성 한 것만으로 프로덕션에 들어갈 수 있습니다.

배포 스크립트는 어디에 배치해야합니까? VCS 에만 있어야합니까 아니면 아티팩트도 빌드해야합니까?

내 경험은 자동화 할 수 있는 모든 것이 있어야한다는 것입니다. 1 단계, 2 단계, .... 로 설명 할 수 있으면 스크립트 여야합니다. 빌드 특정 정보 (예 : 리비전 태그)를 포함하도록 스크립트를 자동 생성 할 수 있다면 그렇게해야합니다. 이것은 게으른 것이 아니라 예측 가능 하고 재현 가능한 것 입니다.

참고 : 자동 생성 된 배포 스크립트가 문제가되어 프로덕션 서버에 연결되는 경우 팀의 모든 사람이 사용할 수 있는 자동 생성 된 되돌리기 스크립트 도 있어야 합니다.

Peter Rowell이 쓴 모든 내용은 정확합니다.

배포 스크립트 파일

• 누군가가 작성한 경우 버전 관리가 필요합니다.
• 생성되어 다시 생성 될 수있는 경우 일반적으로 버전 관리에 들어 가지 않습니다.

배포 프로세스의 경우 :

• 아티팩트가 자체 포함되어 있고 쉽게 수행 할 수있는 경우 파일은 빌드 아티팩트 일 수 있습니다. 즉, 빌드에 사용할 수있는 방식으로 빌드 결과와 함께 패키지됨을 의미합니다.
• 반면에, 배포는 점점 더 복잡해 지므로 조만간 배포를 수행하는 전용 프로그램 (일부 코드를 읽음)이 필요하며 Jenkins 빌드 아티팩트는 더 이상 자체 포함되지 않습니다.

이는 프로세스 및 배포 처리 방법에 따라 다릅니다.