답변:
동일한 웹 응용 프로그램을 여러 고객에게 재판매하는 경우 반드시 버전을 지정해야합니다.
한 곳에서만 설치되는 웹 사이트라면, 그 필요성은 덜 심하지 만 여전히 아프지 않을 것입니다. 시간대 문제 등에 덜 취약합니다. 라이브러리 버전 1.0.2.25에서 문제를 진단하는 것은 2010 년 11 월 3 일 오전 11시 15 분에 라이브러리 빌드를 찾아내는 것보다 훨씬 좋습니다.
응용 프로그램의 DLL에서 버전 번호를 자동화 할 수 있다면 문제가되지 않습니다. 버전을 추적하는 데 도움이됩니다.
일반적으로 웹 응용 프로그램은 호스팅하는 한 위치에서만 배포되므로 데스크톱 응용 프로그램만큼 중요하지 않습니다. 롤백, 버그 추적 (예 :이 버전이 포함 된 버전) 및 개발자, 스테이징 및 프로덕션 서버 (해당되는 경우) 간의 차이를 추적하는 데 도움이됩니다.
나는 그것을 자동화하는 것을 살펴볼 것입니다-그것은 당신이 한 번 설정하고 필요할 때 / 필요할 때 사용할 수있는 종류입니다.
어쨌든 사용자는 항상 최신 버전과 가장 큰 릴리스를 가지고 있기 때문에 버전 번호에 신경 쓰지 않지만 실제로 실행중인 버전을 정확히 알기 위해 자신과 팀에게 빚을집니다. 결국 개발 소스는 라이브 코드와 동기화되지 않으므로 반드시 알아야합니다. 따라서 svn / git 트리에서 릴리스에 레이블을 지정하고 웹 앱에 해당 태그를 표시하십시오.
나는 사소한 웹 응용 프로그램을 제외하고는 그것을 버전 화해야한다고 말합니다. 여기에는 약간 다른 두 가지 개념이 있습니다.
상황에 관계없이 파일에는 개별 버전 (또는 개정) 번호가 있어야한다고 생각합니다. 이상적으로는 버전 제어 시스템에서 자동으로 처리됩니다. 다른 사람들이 언급했듯이 날짜 및 시간보다 파일의 버전 번호를 참조하는 것이 더 쉽습니다.
응용 프로그램을 두 개 이상 설치했거나 설치 한 경우 전체 버전을 지정해야합니다. 별도의 개발 환경과 테스트 환경이있는 경우에도이 방법을 사용하는 것이 좋습니다. 각 응용 프로그램 (또는 릴리스) 버전 번호는 특정 버전 번호의 개별 파일 모음을 나타냅니다. 이 모든 것을 처리하는 것은 추가 부담이지만 특정 개정 번호의 개별 파일보다 특정 릴리스를 체크 아웃하는 것이 더 쉽습니다.
이것은 언어학의 개념을 생각하게합니다. 어떤 언어로 표현할 수 없다면 그 언어로 생각할 수 없다고합니다. 나는 독일어 'Schadenfreude'를 생각합니다. "다른 사람의 불행으로 인한 기쁨을 느낀다"는 개념보다 그 단어를 언급함으로써이 개념을 생각하고 말하기가 훨씬 쉽습니다. 그렇기 때문에이 단어가 영어에서 사용되기 시작했습니다.
마찬가지로, 버전 번호를 사용하면 특정 상태에서 응용 프로그램과 파일을보다 쉽게 말하고 생각할 수 있습니다. 한 사람의 팀인 경우 하나의 응용 프로그램에서 작업하더라도 큰 차이는 없습니다. 그러나 상황이 복잡 해짐에 따라 이러한 레이블을 사용하는 것이 좋습니다.
빌드 서버의 빌드 ID를 사용하여 웹 응용 프로그램의 버전을 지정하고 해당 버그가 모든 버그 보고서에 포함되어 있어야합니다.
현재 프로덕션에없는 이전 버전에서보고 된 버그를 수정해야하는 경우를 대비하여 시간을 거슬러 돌아갈 수 있습니다.
귀하의 질문에서 간단한 웹 응용 프로그램 을 염두에두고 있음이 분명합니다.
Web (-service) API가 아닌 Web GUI를 통해서만 액세스 할 수 있습니다 . API를 사용하여 애플리케이션에 액세스하는 사용자가있는 경우 버전 을 지정 해야 합니다. API를 변경하면 클라이언트가 중단되므로 다른 버전의 API를 동시에 유지 관리해야합니다.
한 번에 하나의 인스턴스 만 실행 중 입니다. 웹 사용자 만있는 경우에도 더 많은 설치가있는 경우 어떤 고객이 어떤 버전을 실행 중인지 알아야합니다.
라이브 버전을 업그레이드 할 수있는 다운 타임 이 허용 됩니다 . 가능성이있다 거대한 는 IS 문제 데이터베이스 . 최신 버전의 중요한 변경 사항에는 데이터의 기본 구조가 변경됩니다. 한 번에 하나의 버전 만 실행중인 경우 이전 버전을 끄고 데이터베이스를 업그레이드 한 후 새 버전을 켜야합니다. 응용 프로그램 중단 시간이 발생합니다. 사용자 수와 종류에 따라 허용 될 수 있습니다.
웹 응용 프로그램이 클라이언트와 서버 모두에서 여러 모듈로 구성된 경우 각 모듈의 버전을 지정해야합니다. 그리고 클라이언트와 서버 모두에서 모듈 버전의 각 조합에는 고유 한 ID, 모든 로깅 및 오류 메시지에있는 ID가 제공되어야합니다.
이 규칙을 사용하면 웹 앱이 주어진 순간의 상태를 항상 다시 만들 수 있습니다.
제 생각에는 요즘 웹 응용 프로그램은 서버와 클라이언트 모두에서 동적 언어를 사용하여 작성되므로 사용자가 브라우저를 다시 시작하거나 수동으로 페이지를 다시로드하지 않으면 업데이트 된 웹 응용 프로그램을 다시로드 할 이유가 없습니다.
웹 애플리케이션의 업데이트 된 부품 또는 모듈 만 애플리케이션의 전체 상태에 영향을주지 않고 다시로드해야합니다.
왜 물어 볼까요? 이를 적용함으로써, 웹 앱은 디자인 상 더 강건하고 정확하며 유지 관리가 더 쉬워 질 것입니다. 웹앱에 항상 동시 서버 / 클라이언트 업데이트가 필요한 경우 올바른 방법으로 빌드되지 않을 수 있습니다.
개인적으로 어쨌든 버전을 만들어야한다고 생각하지만 웹 사이트 전용 웹 응용 프로그램 버전 관리의 큰 이점 중 하나는 정적 콘텐츠를보다 쉽게 관리 할 수 있다는 것입니다.
예를 들어, 만료일이 훨씬 먼 mysite.css 파일이 있다고 가정 해 보겠습니다 (일반적으로 각 페이지의 브라우저에 캐시되도록). 그런 다음 해당 파일에서 스타일을 변경하면 이전에 사이트를 방문한 적이없는 사람이 캐시에서 해당 파일을 지우는 작업을 수행하지 않는 한 아무도 해당 스타일을 보지 못합니다.
사이트 버전을 지정하는 경우 빌드의 모든 CSS 참조를 mysite.css? v = 1234와 같이 변경할 수 있습니다. 'mysite.css? v = 1235입니다.
네 그렇습니다. 다른 답변으로 여기에 지적 된 배포 이유 때문에.
그러나 나는 왜 당신이 질문을하는지 압니다. 웹 앱 접근 방식은 비용 중심입니다. 물리적 수축, 배포, 설치, 문서 사본, 교육 및 기술 지원 비용이 포함 된 레거시 수축 랩 방식과 반대입니다. 제외 할 수있는 것은 제외해야합니다.
분명히하기 위해, 나는 당신이 일종의 사용자가 볼 수있는 버전 번호에 대해 이야기하고 있으며 개발시 버전 제어를 포기하지 않는다고 가정합니다. (개발에서 버전 관리가 필요하지 않다고 생각되면 잘못된 것입니다. 버전 관리가 필요합니다).
단일 호스트 프로젝트의 경우 반드시 필요한 것은 아닙니다. 질문이 있으면 항상 호스트를보고 실제로 실행중인 것을 확인할 수 있기 때문입니다. 그러나 한두 번 편리하게 사용할 수 있기 때문에 친절합니다. 유용하다고 생각할지 여부는 귀하에게 달려 있습니다.
멀티 호스트 프로젝트의 경우 실제로 선택 사항이 아닙니다. 다른 호스트는 결국 다른 버전으로 끝나게되므로 사용자 측에서이를 구분할 수 있어야합니다.