Tomcat에 일반적인 웹 응용 프로그램을 배포했습니다. 요구 사항은 응용 프로그램을 업데이트 할 때 증분 업데이트 대신 전체 패키지 배달 (war 파일)을 제공하는 것입니다.Java EE 웹 응용 프로그램을 증분 업데이트하는 방법은 무엇입니까?
예를 들어, 일단 jar 파일, XML 파일 및 jpg 파일을 변경 한 버그 수정을 마칩니다. 이 3 개의 파일을 패치라고 부릅니다. 패치 파일을 제공해야합니다. 고객이 원래 버전으로 롤백하려는 경우에도 패치를 롤백 할 수있는 방법을 제공해야합니다. 모든 프로세스가 자동으로 수행됩니다.
제 생각에는 요구 사항이 이해가되지 않습니다. 전체 패키지 전달은 쉽고 신뢰할 수있는 방법으로 웹 응용 프로그램을 업데이트하므로 복잡하고 오류가 발생하기 쉬운 방식으로 업데이트하고 싶지 않습니다.
증분 업데이트 요구 사항을 구현 하시겠습니까? 감사!
.war 또는 .ear를 배포 할 때 응용 프로그램 서버는 일반적으로이를 내부 디렉터리에 압축을 풉니 다. 이 디렉토리의 파일은 세분화하여 직접 변경할 수 있습니다. 그러나 변경 사항이 지속적으로 적용 되려면 서버를 다시 시작해야합니다.
귀하의 관점은 실제로 완전히 정확합니다. 요즘에는 파일의 크기가 중요한 역할을하지 않으며, 전체 업데이트로 인해 문제가 나타나지 않습니다. 고객이 전체 업데이트에 만족하지 않는 이유는 무엇입니까?
참고 : 그가 원하는 것은 서버를 다시 시작하지 않고 동적 업데이트, 즉 인 경우, 다음이 (JRebel 같은 솔루션을 개발 중에 만 가능 하죠) 어쨌든 완전히 다른 문제, 주로 자바의 생산 시스템에 불가능하다 .
JRebel을 기반으로 한 또 다른 제품이지만 LiveRebel이라는 라이브 환경에서 응용 프로그램을 업데이트하기위한 것입니다. 최신 업데이트도 가능하며 여러 노드 등의 롤아웃을 자동화 할 수 있습니다. –
Delta-Sync 프로토콜을 사용하는 Java 프로그램을 만들 수 있습니다. 즉, 업데이트해야하는 파일 만 업데이트해야합니다. Dropbox를 사용했다면 꽤 잘 이해할 것입니다. Dropbox는 델타 동기화 프로토콜을 사용하여 파일 및 동기화 데이터를 업데이트합니다.
시간이 지남에 따라 클라이언트에 설치 (서버의 WAR 폴더에 매핑) 및 로컬 시스템과 Dropbox를 사용하여 해당 폴더를 공유 할 수 있습니다. 그런 다음 로컬 시스템의 파일을 변경할 때마다 자동으로 해당 변경 (패치) 파일을 클라이언트의 시스템에 업로드하고 동기화합니다.
이것은 매우 나쁜 생각입니다. 전혀 지원되지 않습니다. 이전 코멘트에서 언급했듯이, 유일한 제정신의 대답은 이것을 전혀하지 않는 것입니다. – GreyBeardedGeek
원근법이 정확합니다. 점진적 업데이트는 추적 및 지원하기가 거의 불가능합니다. 특정 버전이 아닌 앱을 사용하여 고객에게 다가 가면 다시 되돌릴 수 없습니다. 내 제안 -하지 마. – GreyBeardedGeek