2011-01-19 5 views
9

현재 내 호스팅 웹 서버에 svn 저장소가 있습니다. 로컬에서 작업하고 내 서버의 저장소에 변경 사항을 커밋 한 다음 변경 내용을 적용 할 준비가되면 라이브 폴더의 ssh를 통해 "svn 업데이트"를 실행합니다.스테이징 및 라이브 웹 사이트에서 SVN 사용

이제 동일한 서버에 상주 할 준비 사이트를 추가 중입니다. 동일한 서버에있는 다른 폴더 일뿐입니다.

문제점은 제가 테스트를 1 주일 정도 소요될 수있는 스테이징 서버의 사이트에 다소 큰 변화가있을 예정입니다. 그 시간 동안, 나는 테스트가 필요없는 라이브 사이트에 작은 외관 변화를 만들고 싶을 수도 있습니다. 다음의 예제를 보자 :

  1. 모두가 내가 로컬 주요 변경 사항을
  2. 개정 1. 시작 내 로컬, 스테이징, 라이브 사이트를 가정, 커밋, 내 준비 서버를 업데이트합니다. 로컬 및 스테이징은 개정 2, 라이브는 여전히 1입니다.
  3. 누군가 라이브 사이트에서 간단한 텍스트 변경을 요청합니다.
  4. 어. 이제 로컬 복사본을 리비전 1로 되 돌리고 작은 변화를 만들어 커밋해야합니다. 이제 약간의 변경 사항이있는 개정판 3의 라이브 사이트로 업데이트합니다.
  5. 중요한 변경 작업을 계속하고 싶기 때문에 로컬 복사본을 리비전 2로 업데이트하고 계속 작업합니다.
  6. 등등 ....

이 날 업데이트하고 되돌릴 수 지속적으로 revsions 추적하고 강제로. 더 좋은 방법이 있습니까? 나는 여기에 브랜칭과 태그를 사용하고있는 것처럼 느껴지지만 정확하게 이해하지 못한다.

감사합니다, 요나 이미 분기 및 태그를 사용하고이 작업을 수행하는 가장 좋은 방법을 식별

답변

9

5 명의 개발자로 구성된 개발 샵을 관리합니다. 우리는 우리의 웹 사이트에 대한 다음과 같은 방법으로 SVN을 사용 :

  • 개발자가 완료로 일을 표시하기 전에 우리의 'dev에'지점에 대한 모든 개선 사항이나 버그 수정을 커밋합니다.
  • 작업은 dev 분기에서 최신 코드를 실행하는 준비 상자에서 테스트됩니다.
  • 작업이 테스트를 통과하면 해당 작업의 개정판이 트렁크 분기에 병합됩니다.
  • 우리 라이브 웹 서버는 트렁크 분기를 실행합니다. 주기적으로 이들은 라이브 서버에서 SVN을 업데이트하는 '게시'스크립트를 통해 업데이트되며 일부 다른 작업 (예 : CSS 및 JavaScript를 난독 화하고 최소화)을 수행합니다.

이렇게하면 작은 버그가 빠르게 파이프 라인을 통과하고 더 큰 작업이 개발 및 테스트에 필요한만큼의 시간이 걸릴 수 있습니다.

각 개발자는 자신의 작업을 병합해야하며 각 병합은 더 작은 코드 변경 집합으로 이루어 지므로 원활하게 진행됩니다. 병합 관리자가 향상된 기능 집합을위한 주요 향상 지점을 만드는 이전 패턴보다 훨씬 열이 없습니다. 다른 개발자는 일반적으로 일련의 개선 작업을 수행하므로 작성하지 않은 코드를 병합 한 병합 관리자가 생겨 결국 충돌을 병합 할 때 특히 실망하게됩니다.

실제로이 방법은 Git 및 Mercurial과 같은 버전 시스템이 자신의 리포지토리를 구성하는 방법을 통해 승격을 시도하는 방법을 반영합니다. 이러한 버전 시스템을 사용하면 각 개발자는 고유 한 '로컬'리포지토리를 갖게됩니다. 다른 저장소의 변경 사항을 원하면 로컬 코드와 병합 한 다음 유효한 '병합 된'버전을 커밋해야합니다.

Andy가이 질문에 대한 답변에서 언급 한 태그 지정을 사용할 수도 있습니다. 그것은 당신을 위해 일할 수도 있지만, 나는 중앙 수석 개발자 또는 게시 관리자보다는 코드를 작성하는 개발자에게 합병의 책임을 두는 것을 선호합니다. 그들은 그렇게 부드럽게 움직이는 경향이 있습니다.

+0

+1. 당신의 방법이 아마 웹 사이트에 더 적합하다고 생각합니다. 내 팀이 출시 된 모든 항목에 대해 항상 정확한 코드를 얻을 수 있다는 것이 중요하기 때문에 태깅을 많이 사용합니다. 그러나 이것이 대부분의 웹 사이트에서는 그리 어려운 일이 아닙니다. –

+0

@Andy : 실제로. 활성 웹 사이트에서는 수명주기 동안 여러 가지 수정 사항을보고 게시하여 지점과 버그 수정을 분리하면 오버 헤드가 상당히 많이 발생합니다.물론이 방법은 현장에있을 수있는 별개의 '버전'이있는 프로젝트에 더 적합합니다. 그러나 많은 작은 변화가 있고 오직 하나의 '버전'만있는 프로젝트의 경우 각 버그 수정 태깅 및 분기의 구분이 덜 유용합니다. – Shaun

1

. 이를 수행하는 좋은 예는 다음과 같습니다.

주요 개발

  1. 당신은 트렁크에 당신의 주요 개발을한다.
  2. 소프트웨어 사본을 공개 할 때마다 트렁크에서 태그를 만들고 새 태그를 가리 키도록 웹 사이트를 전환하십시오.

이제 다음을 수행 할 수 있습니다를 살 수있는 작은 변화를 만들 필요가 :

  1. 라이브 태그에서 브랜치를 만들고 여기에 일을.
  2. 이 변경 사항에 만족하면이 분기에서 새 태그를 만들고 실제 작업 복사본을 새 태그로 전환합니다.
  3. 이 변경 사항을 지점에서 트렁크로 병합하여이 변경 사항이 다음 주요 버전에도 적용될 수도 있습니다.

모두 여기에 극심한 자세하게 설명 전복에 정말 좋은 수수료 책이있다 : 당신은 시간을 찾을 수 있다면

http://svnbook.red-bean.com/

난 강력하게 읽기를 제안 할 것입니다.

+0

Andy, 내가 일하는 것에 따라 latptop에서 한 지점에서 다른 지점으로 끊임없이 변화하고있는 실제 로컬 복사본이 있습니까? – Jonah

+0

Andy의 방법을 사용하면 작은 변경 사항마다 로컬 시스템의 새 분기를 만들어 변경해야합니다. 주요 변경 사항은 트렁크에서 발생하며 트렁크에 태그를 지정하고 프로덕션 서버를 해당 태그로 업데이트하여 '릴리스'합니다. – Shaun

+0

@Jonah : 두 개 이상의 작업 복사본을 체크 아웃했습니다. 예를 들어'foo' 프로젝트가 있다면'C : \ Projects \ Foo \ Trunk'가 있고'C : \ Projects \ Foo \ v1.1-Bugfix'가 동시에 체크 아웃됩니다 (여기서 'c : \ Projects \ Foo'는 버전 관리하에 있지 않습니다.) 귀하의 방법에 대해 –

관련 문제