SVN에서 가장 좋아하는 웹 앱 배포 워크플로는 무엇입니까?

Question

우리는 현재 원격 SVN 서버, DEV, STAGE 및 PROD용 3개의 SVN 분기, 패치를 통해 이들 간의 코드 승격 등을 포함하는 다소 복잡한 배포 설정을 사용하고 있습니다.소규모 개발팀 상황에서는 배포를 위해 무엇을 사용하는지 궁금합니다.

Answer 1

개발을 위한 트렁크와 프로덕션을 위한 브랜치(프로덕션)입니다.

내 로컬 컴퓨터에는 변경 사항을 테스트하기 위해 트렁크 분기를 가리키는 VirtualHost가 있습니다.

트렁크에 대한 모든 커밋은 svn 내보내기를 수행하고 온라인 서버의 dev URL과 동기화하는 커밋 후크를 트리거합니다. 따라서 사이트가 stackoverflow.com이면 이 후크는 자동으로 dev.stackoverflow.com을 업데이트합니다.

그런 다음 svnmerge를 사용하여 선택한 패치를 트렁크에서 로컬 체크아웃의 프로덕션으로 병합합니다.프로덕션 지점을 가리키는 로컬 컴퓨터에 VirtualHost가 다시 있습니다.

병합된 변경 사항을 프로덕션 브랜치에 커밋하면 다시 SVN 내보내기 후크가 프로덕션(라이브) 내보내기를 업데이트하고 사이트가 라이브 상태가 됩니다!

Answer 2

제가 소규모 개발팀(나, 다른 프로그래머, 상사를 의미함)에서 일했을 때, 정말 혼란스러웠습니다.그러나 우리는 "게이트키퍼" 유형의 프로세스를 할당하는 것이 우리에게 효과적이라는 것을 알았습니다.

게이트키퍼는 앱에서 가장 많은 작업을 수행한 사람이었습니다(이 경우 처음부터 개발한 프로젝트가 2개 있었는데 그 사람은 4개 정도였습니다).

기본적으로, 그가 내 프로젝트 작업을 해야 할 때마다 그는 자신이 작업을 하고 있다고 나에게 알려주었고, 나는 저장소가 최신이고 빌드 가능한지 확인한 다음 풀다운하여 변경 사항을 적용한 다음 커밋했습니다. .그는 그것이 완료되었다고 나에게 알릴 것이고, 나는 풀다운하고, 구축하고, 배포할 것입니다.DB 변경이 있는 경우 DB를 수정하는 모든 스크립트가 포함된 DB 변경 폴더가 있었습니다.

분명히 거기에는 많은 구멍이 있지만 그 과정은 우리에게 도움이 되었고 우리가 서로를 쌓아가는 것을 막았습니다.

Answer 3

공통 태그/브랜치/트렁크 구성에 문제가 없었습니다.

일반적으로 진행 중인 개발은 트렁크에서 이루어집니다.

프로덕션 릴리스의 유지 관리는 해당 릴리스 분기에서 수행됩니다.

트렁크와 여전히 관련된 릴리스 분기에 대한 변경 사항이 병합됩니다.

새 버전이 배포 준비가 되면 트렁크에서 태그가 지정되고 해당 태그에서 분기가 생성됩니다.새 릴리스 분기는 현재 릴리스와 동시에 서버로 체크아웃됩니다.전환할 때가 되면 경로가 조정됩니다("mv appdir appdir.old && mv appdir.new appdir").

프로덕션 릴리스를 지원하는 개발자는 svn 작업 복사본을 새 브랜치로 전환하거나 새 브랜치에서 새로 체크아웃합니다.

Answer 4

Three Branches는 추가 작업처럼 들립니다.

트렁크에 관련 파일의 다른 버전을 가짐으로써 환경적 차이를 처리할 수 있습니다.즉.데이터베이스.yml 및 데이터베이스.yml.prod.배포 프로세스는 환경을 인식해야 하며 환경별 파일을 기본 파일 위에 복사하기만 하면 됩니다.

Answer 5

간단한 트렁크 브랜치에는 최신 코드가 포함되어 있으며 라이브로 전환될 때마다 브랜치를 잘라냅니다.이것은 꽤 효과적으로 작동하는 것 같습니다.라이브 시스템을 위해 잘라낸 현재 분기가 실패할 때마다 이전 분기로 쉽게 이동할 수 있습니다.또한 현재 활성화된 브랜치의 버그를 수정하기 쉽고 새 브랜치를 잘라내면 해당 브랜치가 효과적으로 죽기 때문에 작업해야 하는 실제 브랜치는 단 하나뿐입니다(그런 다음 거기에서 수정 사항을 병합합니다). 라이브 지점).

Answer 6

우리는 웹 관련 작업을 준비하기 위해 분기를 사용하지 않습니다.시간이 오래 걸리는 실험적인 것을 테스트하는 데에만 사용됩니다(읽기:하루 이상) 트렁크에 다시 병합합니다.'지속적인 통합' 스타일의 트렁크는 (희망적으로) 작동하는 현재 상태를 나타냅니다.

따라서 대부분의 변경 사항은 트렁크에 직접 커밋됩니다.CruiseControl.NET 서버는 IIS를 실행하고 사용 가능한 모든 추가 사이트 리소스의 최신 복사본이 있는 시스템에서 자동으로 업데이트되므로 사이트를 사내에서 완전하고 깔끔하게 테스트할 수 있습니다.테스트 후 파일이 공개 서버에 업로드됩니다.

이것이 완벽한 접근 방식이라고는 말할 수 없지만 간단하고(따라서 상대적으로 작은 직원에게 적합) 상대적으로 안전하며 잘 작동합니다.

Answer 7

트렁크에는 현재 "기본" 개발 코드베이스가 포함되어 있습니다.

개발자는 트렁크 코드베이스를 가득 채우고 다른 개발자를 방해할 수 있는 중장기 프로젝트에 대해 개별 분기를 만드는 경우가 많습니다.완료되면 다시 트렁크로 병합됩니다.

우리는 코드를 프로덕션에 푸시할 때마다 태그 릴리스를 생성합니다./tags의 폴더는 단순히 버전 번호입니다.

프로덕션에 배포하기 위해 SVN 내보내기를 스테이징으로 수행하고 있습니다.이것이 만족스러우면 간단한 rsync를 사용하여 프로덕션 클러스터로 롤아웃합니다.

Answer 8

나는 이 책을 강력히 추천합니다(현재 대략적인 작업 중). 지속적인 전달, 는 지속적인 통합 원칙을 기반으로 소프트웨어 제공을 관리하는 전체 프로세스를 설명합니다.

나는 분기 및 병합 접근 방식을 매우 싫어합니다. 매우 지저분해질 수 있고 실제로 새로운 가치를 제공하지 않는 활동에 시간을 소비하게 되므로 꽤 낭비되기 때문입니다.이미 코드를 한 번 개발하고, 테스트하고 수정했는데, 왜 이 작업을 다시 실행해야 하는 상황(코드를 다른 브랜치에 복사)을 만들까요?

어쨌든 분기 및 병합을 피하는 방법은 트렁크에서 배포 가능한 아티팩트를 빌드하고 테스트, 스테이징 등을 통과할 때 빌드된 아티팩트(소스가 아닌)를 승격시키는 것입니다.이렇게 하면 프로덕션에 투입하는 것이 테스트한 것과 동일하다는 것을 100% 확신할 수 있습니다.

다양한 일정에 따라 출시해야 할 다양한 기능이 있는 경우 구현 방법에 대한 접근 방식을 변경(기능을 구성 가능하게 만들거나 더 나은 모듈화)하면 단일 개발 트렁크를 유지하는 데 도움이 될 수 있습니다.

Answer 9

우리는 릴리스 분기를 사용합니다. 이는 우리가 수행하던 기능 분기보다 더 효율적인 것 같습니다.

서로 다른 환경에 대해 서로 다른 분기를 만들지 마십시오.

Answer 10

저는 개인적으로 로컬에서 작업(개발)하고 기능을 추가/수정하고 준비가 되었다고 생각되면 트렁크(프로덕션)에 투입합니다.프로덕션 서버에서는 svn 업데이트만 수행합니다.

Answer 11

나는 당신이 현재 겪고 있는 상황과 비슷한 상황에서 일하고 있습니다.나는 '더 나은' 솔루션을 찾는 임무를 맡았고 다음과 같은 내용을 실행했습니다.

라이브 분기는 현재 상태의 서버를 나타냅니다.

모든 개발 작업은 라이브에서 가져온 브랜치에서 수행되어야 합니다.이는 1인 30분 작업일 수도 있고 1년 동안 진행되는 다중 팀 프로젝트일 수도 있습니다.원하는 만큼 자주 변경 사항을 이러한 개발 분기에 병합할 수 있습니다.

작품이 게시되기 전에 라이브에서 변경된 내용이 다시 병합되고 잠재적 릴리스로 태그가 지정됩니다.이 릴리스는 스테이징 환경에서 테스트되었으며 테스트를 통과하면 새 라이브가 태그에서 가져옵니다.

더 잘 작동한다면 여러 작업을 하나의 릴리스로 병합할 수 있습니다.

즉, 개발 브랜치를 실시간으로 최신 상태로 유지하는 것이 매우 간단하며 개발 중인 작업이 삭제된 경우 정리 작업이 최소화됩니다.

한 프로젝트에서 다른 프로젝트로 작업을 변경하려면 개발자는 로컬 작업 환경을 다른 지점으로 svn 전환하면 됩니다.

귀하가 설명하는 시스템에서 발생한 문제 중 하나는 DEV가 PROD를 사용하면 상당히 빨리 구식이 될 수 있으므로 실제 환경에 대해 개발하지 않고 단계까지 교차 종속성을 발견하기가 쉽지 않다는 것입니다.위의 솔루션은 상당히 가벼운 상태를 유지하면서 이러한 문제를 해결합니다.