SVN에서 직접 프로덕션에 웹앱을 배포 할 수 있습니까?

질문

프로덕션 배포에 SVN을 사용 하지 않아야 하는 합법적 인 이유가 있습니까? 아니면 이것은 단지 개인적인 취향의 경우이며 SVN에 대한 실제 사례는 없습니까?

배경

내 직장에는 SVN에 릴리스 태그 지정 문화가 있으며 프로덕션을 직접 사용 svn co하거나 svn switch포함 하여 다양한 웹 서버에 해당 릴리스를 직접 배포합니다 .

빌드 및 배포 스크립트 또는 일부 형식 또는 자동 배포를 사용하지 않으면 문서화되지 않았으므로 통합 환경 설정이 손실된다고 생각하기 때문에 개인적으로 이것에 문제가 있습니다. 그러나 그 이상으로 간과 된 일, 아직 못생긴 머리를 아직 걷지 않은 일을하는 데 숨겨진 위험이있을 수 있다고 생각합니다.

다양한 환경 (스테이징, 사전 제작, 프로덕션 등)에 코드를 배포 할 책임이있는 운영 직원에게 우려를 표명했습니다. 그들의 주장은 지금까지 아무런 변화가 없었지만 지금까지 잘 작동했다는 주장이었습니다.

편집하다:

빌드 및 배포에 대한 의미 :

예를 들어, 개발자에게 특정 환경에 추가 된 web.config 설정이 필요한 경우. Web.config는 일반적으로 svn에 보관되지 않으므로 이러한 파일은 자동 빌드 스크립트 형식없이 수동으로 업데이트됩니다. 따라서 분실되거나 OPS가 릴리스를 위해 web.config에 필드를 추가하는 것을 잊어 버린 경우 문제가 있습니다.

XMLPoke를 사용하여 특정 환경에 적합한 web.config를 자동으로 생성하는 빌드 스크립트는 각 환경에 필요한 모든 변경 사항을 문서화하는 버전 화 가능한 스크립트가 있다는 점에서 이상적입니다.

현재 빌드 및 배포 방법

문제가되는 프로젝트의 경우 개발자가 수동으로 릴리스를 빌드하면 다른 프로젝트에는 NANT 또는 MSBuild (확인)로 자동화 된 빌드 단계가 있습니다.

대부분의 프로젝트에 대한 데이터베이스 마이그레이션은 DB 스크립트 또는 마이그레이션 스크립트 (Migrator.NET) 또는 CMS 패키지를 통해 이루어집니다.

CI는 일반적으로 Team City에서 체크인 단위로 수행되며, 모든 티켓은 지점에서 수행 된 후 트렁크에 체크인하기 전에 유효성 검사 및 정확성 / 품질에 대해 동료 검토를 수행하는 코드 검토 프로세스가 있습니다 (잘 작동 함).

그러나 실제 코드 배포는 항상 태그가있는 릴리스의 체크 아웃 또는보다 일반적으로 SVN 스위치를 통해 SVN을 통해 이루어집니다. 이는 배포 프로세스의 일부로 리포지토리를 사용하고 있다는 점에서 이상합니다.

구성은 일반적으로 자주 변경되지 않으며 구성 파일에있는 유일한 환경 환경 정보입니다. 다른 모든 것은 db에 있습니다.

이 작업이 잘못되지 않도록하십시오. 잘 작동합니다. 그러나 자동화 된 빌드 및 배포를 시도하고 추진하고 싶습니다. 나는 이것을 Rails 및 Capistrano와 함께 사용했으며 Cygwin, Nant 및 SSH를 사용하는 개인 프로젝트에 사용했습니다.

더 중요한 것은 동료가 자동 빌드 및 배포를 사용하도록 변경하려면 매우 구체적인 유효한 인수가 필요하다는 것입니다.

아니면 SVN을 사용하여 프로덕션 환경에 배포하는 것에 대한 실제 유효한 주장이 없습니까?

내 경험으로는 장점과 단점이 있습니다.

장점 :

• 때때로 프로덕션 서버에서 긴급 핫픽스를 작성한 다음 거기서 바로 다시 체크인 할 수 있습니다. 이론 상으로는 보안상의 이유로 프로덕션 서버에서 리포지토리에 대한 읽기 전용 액세스를 사용하는 것이 좋습니다.

• 단순성 : 여기에 언급 된 다른 사람들처럼 업데이트 스크립트 체계로 쉽게 전환 할 수 있지만 신속하게 제공 할 수 있습니다.

단점 :

• svn up및 DB 업데이트 중에 시스템이 불안정해질 수 있습니다. 트래픽이 많은 사이트의 경우 일부 사용자가 오류 메시지, 깨진 페이지 또는 빈 페이지를 가장 잘 보게됩니다. 그게 우리가 다양한 사회 서비스에서 자주 보게되는 것입니다. 그러나 좋은 서비스는 업데이트 기간 동안 시스템을 유지 관리 모드로 전환한다는 의미에서 "원자 적"입니다. ( 당신은 레딧을 끊었다! )

• 충돌 : 프로덕션 서버에서 갑작스러운 충돌을 해결하는 것은 끔찍한 생각입니다. 다시 말하지만 서비스를 수정하는 동안 서비스가 불안정 해집니다.

• 프로덕션 서버의 관련되지 않은 파일은 사용자에게 속하거나 속하지 않을 수 있지만 물론 리포지토리에서 올바른 하위 트리를 확인하면 파일을 피할 수 있습니다.

• 보안 : 합법적으로 또는 프로덕션 서버에 액세스 할 수있는 사람도 리포지토리, 다른 제품 및 쓰기 액세스 권한에 액세스 할 수 있습니다! 내부 SVN 서버를 외부에 공개하는 것은 나쁜 생각입니다. 소스 리포지토리는 회사 방화벽 뒤에 있어야합니다.

• 어쨌든 DB 구조 업데이트, cronjob 관리 등과 같은 업데이트 스크립트가있을 것입니다. 그래서 모든 것을 수행하는 스크립트가없는 이유는 무엇입니까? 즉, 최신 사전 패키지 릴리스를 가져오고 유지 관리 모드로 전환하고 소스를 업데이트하고 릴리스 별 스크립트를 실행합니다.

편집 : 여전히 SVN 체계에있는 사람들을 위해 아파치 구성에서 이것을 잊지 마십시오.

<DirectoryMatch .svn>
    Order deny,allow
    Deny from all
</DirectoryMatch>

단위 테스트가 성공적으로 완료되었다고 가정하면 설치 프로그램을 자동으로 생성하는 CI 서버를 작업에 설정했습니다. 그것은 하루의 일이 걸렸고 내가 그것을 설립 한 이래로 그 이상을 저축했습니다.

릴리스 / 설치 프로그램 / 제작 웹 사이트를 구성 할 때 수동 프로세스가 있으면 자신과 회사 시간을 항상 절약 할 수 있습니다. 귀하의 질문에서 설정 프로세스에 수동 구성 단계가있는 것처럼 보이므로 적합합니다.

참고로 Joel 은 단일 클릭 빌드 프로세스로 단기 및 중기 적으로 어떻게 비용을 절감 할 수 있는지에 대해 Joel이 설명합니다.

SVN에 적절한 체크인 제어가 있는지 확인하십시오. 예를 들어, 이것을 고려하십시오-

• 릴리스를위한 기능 체크인
• 코드가 준비에 배포되고 QA가 작업을 수행함
• 버그가 수정되었습니다. 또 다른 테스트 라운드입니다 (단, 팀에서 작동)
• 사전 제작을위한 Ditto
• 프로덕션에 배포

사전 제작 단계 이후 누군가 실수로 체크인을하면 무언가를 깰 위험이 있습니다. 버그 수정을 제외하고 사전 제작 과정에서 체크인이 허용되지 않는 것처럼 제어되는 경우 위험이 없습니다.

업데이트 : 구성 파일을 체크인하지 않으면 대기하는 데 문제가 있습니다. 나는 "제발, 빨리 해줘!"이외의 다른 조언은 할 수 없다.

저장소 외부에 아무것도없는 한 괜찮습니다. 실제로, 프로젝트의 처음 몇 개월 동안 배포 도구에 시간을 투자해서는 안된다고 생각합니다. 원인 배포가 너무 많아서 정식 릴리스 프로세스에 대한 고객의 불만이 충분하지 않습니다.

그러나 프로젝트가 약 1 년이 지나면 배포 도구에 대한 투자를 고려할 가치가 있습니다. 간단한 이유는

• 비즈니스가 성장하여 둘 이상의 서버에서 호스팅 할 계획
• 특정 환경에 버그가있을 수 있으며 버그를 복제 할 장소가 없습니다. tar-untar-forget_about_home_for_a_week 프로세스없이 쉽게 설정할 수있는 방법은 없습니다.
• 어떤 사람은 빌드를 깨뜨릴 수 있습니다. 누가 빌드를 깨뜨 렸습니까?

이를 확인하려면 내부 테스트 또는 QA를 위해 다른 서버를 설정하도록 요청하십시오.