웹 애플리케이션을 버전해야합니까?


35

최근 웹 애플리케이션 버전 관리에 대해 동료와 논의했습니다.

나는 당신이 전혀 필요하다고 생각하지 않으며, 최신 릴리스가 공개되었는지 확인하기 위해 위생 검사를 원한다면 날짜 (YYMMDD)가 충분하다고 생각합니다.

나는 기지에서 떨어져 있습니까? 요점을 놓치고 있습니까? 웹 애플리케이션 버전 번호를 사용해야합니까

답변:


31

동일한 웹 응용 프로그램을 여러 고객에게 재판매하는 경우 반드시 버전을 지정해야합니다.

한 곳에서만 설치되는 웹 사이트라면, 그 필요성은 덜 심하지 만 여전히 아프지 않을 것입니다. 시간대 문제 등에 덜 취약합니다. 라이브러리 버전 1.0.2.25에서 문제를 진단하는 것은 2010 년 11 월 3 일 오전 11시 15 분에 라이브러리 빌드를 찾아내는 것보다 훨씬 좋습니다.


2
동일한 웹 응용 프로그램을 여러 고객에게 재판매하는 경우 반드시 버전을 지정해야합니다. 100 % 사실!
Gopi

8
동의하지 않습니다. 릴리스의 버전 관리는 웹 응용 프로그램이든 아니든 항상 중요합니다. 이것은 모든 개발 방법의 기본 관행입니다 (카우보이 코딩 제외).
Martin Wickman

2
@Sri 쿠마 : 아직 여기 키워드 인 :
마틴 Wickman

2
@sri, 스택 추적은 버전에 따라 크게 다릅니다. stacktrace에 대한 오류 보고서가있는 경우 이후에 최신 버전이 릴리스 된 경우에도 신속하고 확실하게 해당 스택 추적에 해당하는 소스 코드를 가질 수 있어야합니다. 최신 버전의 Java 로깅 소프트웨어는 스택 추적 자체에 버전 정보를 제공합니다.

1
@ anna lear-나는 데이트에 대해 당신에게 결코 대답하지 않았다는 것이 나에게 일어났다. YYMMDD 버전 관리에서 "2010 년 11 월 3 일 오전 11시 15 분"의 예는 101103으로 버전이 지정되므로 날짜별로 '버전이 지정됩니다'.
John MacIntyre 2018 년

12

응용 프로그램의 DLL에서 버전 번호를 자동화 할 수 있다면 문제가되지 않습니다. 버전을 추적하는 데 도움이됩니다.

일반적으로 웹 응용 프로그램은 호스팅하는 한 위치에서만 배포되므로 데스크톱 응용 프로그램만큼 중요하지 않습니다. 롤백, 버그 추적 (예 :이 버전이 포함 된 버전) 및 개발자, 스테이징 및 프로덕션 서버 (해당되는 경우) 간의 차이를 추적하는 데 도움이됩니다.

나는 그것을 자동화하는 것을 살펴볼 것입니다-그것은 당신이 한 번 설정하고 필요할 때 / 필요할 때 사용할 수있는 종류입니다.


각 빌드에 대한 VCS 태그를 포함하여 자동화. AFAIK 대부분의 빌드 시스템은 요즘 그렇게 할 수 있습니다.
JensG

9

어쨌든 사용자는 항상 최신 버전과 가장 큰 릴리스를 가지고 있기 때문에 버전 번호에 신경 쓰지 않지만 실제로 실행중인 버전을 정확히 알기 위해 자신과 팀에게 빚을집니다. 결국 개발 소스는 라이브 코드와 동기화되지 않으므로 반드시 알아야합니다. 따라서 svn / git 트리에서 릴리스에 레이블을 지정하고 웹 앱에 해당 태그를 표시하십시오.


1
전혀. 당신은 야생에서 버전없는 코드를 가질 여유가 없습니다. 버전이 SVN / hg / git commit # 인 경우에도 마찬가지입니다.
Paul Nathan

9

개발자 / 테스트 인스턴스가있는 경우 프로젝트 팀 구성원이 테스트중인 빌드 / 개정을 확인할 수 있어야합니다.


4

다른 사람들이 말한 것 외에도 버전 관리도 마케팅 관점에서 중요하다고 덧붙입니다. 새 버전은 잠재 고객 또는 기존 고객에게 판매 할 수있는 새로운 버전입니다. 고객에게 '새로운 것'을 알리고 앞으로 나아가고있는 것을 알 수 있습니다. 새로운 기능을 멋지게 그룹화합니다. 그리고 더 전문적으로 보입니다.


4

나는 사소한 웹 응용 프로그램을 제외하고는 그것을 버전 화해야한다고 말합니다. 여기에는 약간 다른 두 가지 개념이 있습니다.

  1. 전체적으로 응용
  2. 개별 파일

상황에 관계없이 파일에는 개별 버전 (또는 개정) 번호가 있어야한다고 생각합니다. 이상적으로는 버전 제어 시스템에서 자동으로 처리됩니다. 다른 사람들이 언급했듯이 날짜 및 시간보다 파일의 버전 번호를 참조하는 것이 더 쉽습니다.

응용 프로그램을 두 개 이상 설치했거나 설치 한 경우 전체 버전을 지정해야합니다. 별도의 개발 환경과 테스트 환경이있는 경우에도이 방법을 사용하는 것이 좋습니다. 각 응용 프로그램 (또는 릴리스) 버전 번호는 특정 버전 번호의 개별 파일 모음을 나타냅니다. 이 모든 것을 처리하는 것은 추가 부담이지만 특정 개정 번호의 개별 파일보다 특정 릴리스를 체크 아웃하는 것이 더 쉽습니다.


이것은 언어학의 개념을 생각하게합니다. 어떤 언어로 표현할 수 없다면 그 언어로 생각할 수 없다고합니다. 나는 독일어 'Schadenfreude'를 생각합니다. "다른 사람의 불행으로 인한 기쁨을 느낀다"는 개념보다 그 단어를 언급함으로써이 개념을 생각하고 말하기가 훨씬 쉽습니다. 그렇기 때문에이 단어가 영어에서 사용되기 시작했습니다.

마찬가지로, 버전 번호를 사용하면 특정 상태에서 응용 프로그램과 파일을보다 쉽게 ​​말하고 생각할 수 있습니다. 한 사람의 팀인 경우 하나의 응용 프로그램에서 작업하더라도 큰 차이는 없습니다. 그러나 상황이 복잡 해짐에 따라 이러한 레이블을 사용하는 것이 좋습니다.


4

빌드 서버의 빌드 ID를 사용하여 웹 응용 프로그램의 버전을 지정하고 해당 버그가 모든 버그 보고서에 포함되어 있어야합니다.

현재 프로덕션에없는 이전 버전에서보고 된 버그를 수정해야하는 경우를 대비하여 시간을 거슬러 돌아갈 수 있습니다.


1

귀하의 질문에서 간단한 웹 응용 프로그램 을 염두에두고 있음이 분명합니다.

  • Web (-service) API가 아닌 Web GUI를 통해서만 액세스 할 수 있습니다 . API를 사용하여 애플리케이션에 액세스하는 사용자가있는 경우 버전 을 지정 해야 합니다. API를 변경하면 클라이언트가 중단되므로 다른 버전의 API를 동시에 유지 관리해야합니다.

  • 번에 하나의 인스턴스실행 중 입니다. 웹 사용자 만있는 경우에도 더 많은 설치가있는 경우 어떤 고객이 어떤 버전을 실행 중인지 알아야합니다.

  • 라이브 버전을 업그레이드 수있는 다운 타임 이 허용 됩니다 . 가능성이있다 거대한 는 IS 문제 데이터베이스 . 최신 버전의 중요한 변경 사항에는 데이터의 기본 구조가 변경됩니다. 한 번에 하나의 버전 만 실행중인 경우 이전 버전을 끄고 데이터베이스를 업그레이드 한 후 새 버전을 켜야합니다. 응용 프로그램 중단 시간이 발생합니다. 사용자 수와 종류에 따라 허용 될 수 있습니다.


합의되지 않은 버전의 웹 API를 만드는 것은 대부분의 사람들이 그것을 믿을 수없는 중대한 무능입니다. 그리고 네, 앱의 한 인스턴스에 대해 이야기하고 있습니다.
John MacIntyre

또한 단일 인스턴스 애플리케이션에서도 여전히 유효한 세 번째 포인트를 고려하십시오.
OGrandeDiEnne

나는 그것을 읽고 그것이 중요하고 까다로운 반면, 그것이 버전 문제인지 확실하지 않습니다. 배포 문제가 더 많지 않습니까? KWIM?
John MacIntyre

예, 아니오 (오래 전에는 생각했지만 ..) 요점은 코드를 버전 화 해야하는 경우 db 구조도 버전 화해야 할 가능성이 있다는 것입니다.
OGrandeDiEnne

0
  • 제한된 설치 기반으로 만 내부에서 사용합니까?
  • 아니면 야생에서 여러 버전을 가질 수 있습니까?

우리는 전자를 가지고 있으므로 릴리스 후 온 전성 검사를 위해 버전 번호 만 사용합니다. 사용중인 많은 버전을 동시에 추적 할 필요는 없습니다.


0

웹 응용 프로그램이 클라이언트와 서버 모두에서 여러 모듈로 구성된 경우 각 모듈의 버전을 지정해야합니다. 그리고 클라이언트와 서버 모두에서 모듈 버전의 각 조합에는 고유 한 ID, 모든 로깅 및 오류 메시지에있는 ID가 제공되어야합니다.

이 규칙을 사용하면 웹 앱이 주어진 순간의 상태를 항상 다시 만들 수 있습니다.

제 생각에는 요즘 웹 응용 프로그램은 서버와 클라이언트 모두에서 동적 언어를 사용하여 작성되므로 사용자가 브라우저를 다시 시작하거나 수동으로 페이지를 다시로드하지 않으면 업데이트 된 웹 응용 프로그램을 다시로드 할 이유가 없습니다.

웹 애플리케이션의 업데이트 된 부품 또는 모듈 만 애플리케이션의 전체 상태에 영향을주지 않고 다시로드해야합니다.

왜 물어 볼까요? 이를 적용함으로써, 웹 앱은 디자인 상 더 강건하고 정확하며 유지 관리가 더 쉬워 질 것입니다. 웹앱에 항상 동시 서버 / 클라이언트 업데이트가 필요한 경우 올바른 방법으로 빌드되지 않을 수 있습니다.


0

예, 버전을 지정해야합니다! 또한 버전 관리 시스템에는 버전 번호와 일치하는 태그 (예 : 서브 버전, 자식, 머큐리얼 등)가 있어야합니다.

태그를 사용하면 돌아가서 지점을 만들 수 있습니다. 예를 들어, 현재 프로덕션 버전에는 버그가 있지만 컴퓨터의 코드가 문을 열 준비가되지 않았기 때문에 수정할 수 없습니다. 그러나 RCS에 태그가 있으면 해당 태그에서 분기하여 프로덕션에서 실행중인 코드의 정확한 버전에서 버그를 수정할 수 있습니다.


0

개인적으로 어쨌든 버전을 만들어야한다고 생각하지만 웹 사이트 전용 웹 응용 프로그램 버전 관리의 큰 이점 중 하나는 정적 콘텐츠를보다 쉽게 ​​관리 할 수 ​​있다는 것입니다.

예를 들어, 만료일이 훨씬 먼 mysite.css 파일이 있다고 가정 해 보겠습니다 (일반적으로 각 페이지의 브라우저에 캐시되도록). 그런 다음 해당 파일에서 스타일을 변경하면 이전에 사이트를 방문한 적이없는 사람이 캐시에서 해당 파일을 지우는 작업을 수행하지 않는 한 아무도 해당 스타일을 보지 못합니다.

사이트 버전을 지정하는 경우 빌드의 모든 CSS 참조를 mysite.css? v = 1234와 같이 변경할 수 있습니다. 'mysite.css? v = 1235입니다.


0

네 그렇습니다. 다른 답변으로 여기에 지적 된 배포 이유 때문에.

그러나 나는 왜 당신이 질문을하는지 압니다. 웹 앱 접근 방식은 비용 중심입니다. 물리적 수축, 배포, 설치, 문서 사본, 교육 및 기술 지원 비용이 포함 된 레거시 수축 랩 방식과 반대입니다. 제외 할 수있는 것은 제외해야합니다.


0

분명히하기 위해, 나는 당신이 일종의 사용자가 볼 수있는 버전 번호에 대해 이야기하고 있으며 개발시 버전 제어를 포기하지 않는다고 가정합니다. (개발에서 버전 관리가 필요하지 않다고 생각되면 잘못된 것입니다. 버전 관리가 필요합니다).

단일 호스트 프로젝트의 경우 반드시 필요한 것은 아닙니다. 질문이 있으면 항상 호스트를보고 실제로 실행중인 것을 확인할 수 있기 때문입니다. 그러나 한두 번 편리하게 사용할 수 있기 때문에 친절합니다. 유용하다고 생각할지 여부는 귀하에게 달려 있습니다.

멀티 호스트 프로젝트의 경우 실제로 선택 사항이 아닙니다. 다른 호스트는 결국 다른 버전으로 끝나게되므로 사용자 측에서이를 구분할 수 있어야합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.