2009-08-11 5 views
12

오프라인 개발에서 웹 개발에 웹 서버를 올바르게 라이브로 배포하는 방법을 모르겠습니다. 나는 대부분 직관에 의지하고 있지만, 지금까지 내가 한 일은 다소 다르다 : 나는 웹 애플리케이션을 파이썬이나 PHP로 가지고 있으며, 라이브 웹 서버에서 호스팅하고있다. 소스가 svn 아래에있는 오프라인 개발 버전을 사용합니다.웹 응용 프로그램을 해제하는 방법?

이제 오프라인 버전을 개발하면서 svn에 대한 커밋을 수행합니다. 시간이 릴리스 올 때, 내가 할 수있는 중 하나

  1. 라이브 웹 서버에 임시 디렉토리에 오프라인 서버에서 코드를 복사 한 다음, 새 (. 예 : 링크)와 기존의 코드베이스를 교체 또는 ...
  2. 체크 아웃 svn에서 라이브 웹 서버 작업이 있고 svn update 만 실행하면됩니다.

일반적으로 라이브 배포 전에 데이터베이스를 업그레이드해야하지만 일반적으로 업그레이드 SQL 스크립트를 작성하고 라이브 데이터베이스에서 처음 실행 한 다음 계산하면됩니다.

이 작업의 모범 사례는 무엇입니까?

+0

스테파노, 내 대답을 좋은 것으로 생각하니? – TheJacobTaylor

+0

@ TheJacobTaylor : 저는 매 2 주마다 세션을 수락합니다. 이번 주말 나는 모든 대답을 다시 읽고 받아 들일 것이다. –

답변

10

체크 아웃 대신 SVN 내보내기를 사용하는 것이 좋습니다. 이렇게하면 SVN 파일을 전 세계에 공개하지 않게됩니다. 또한 일반적으로 클리너 폴더 구조를 만듭니다.

무대와 프로덕션간에 파일을 이동하기 전에 rsync를 활용했습니다.

내 일반적인 배포 방법은 다음과 같이 진행 :

  • 백업 생산 현장
  • 모든 외부 IP 주소
  • 수출 저장소에서 코드에서 아래로 서버를
  • 잠금 서버를 무대 백업에서 복원 임시 폴더에 (작은 변경 사항에 대해 두 폴더를 선택적으로 diff 함)
  • 임시 폴더에서 스테이지 서버 폴더까지의 rsyc 파일
  • 변경하려는 파일 만 실제로 변경되었는지 확인하십시오.
  • 는, 생산에 배포, 이제 웹 서버

의 잠금을 해제 DB

  • 테스트에 업그레이드
  • 를 SQL 스크립트를 적용 빨리 감기에서 다음 단계를 재생. 스크립트를 사용하면 훨씬 쉽게 할 수 있습니다.

  • +0

    동의하지만 파일이 많으면 svn 내보내기가 느려질 수 있습니다! –

    +0

    대부분의 웹 서버에서는 .svn 폴더를 제공하지 않는 필터를 설정하는 것이 쉽지 않으므로 "svn update"를 사용하지 않는 이유는 아닙니다. 서버를 처음 설정할 때 명심해야 할 것이 있습니다. – rmeador

    +0

    로컬 (디스크 또는 네트워크) svn에서 내보내는 경우 일반적으로 속도는 문제가되지 않습니다. 그렇지 않습니까? 내 말은, svn이 빠르다는 것이 아닙니다. 그것에서 멀리. –

    1

    이론적으로 나는 svn을 웹 서버의 새로운 영역으로 내 보냅니다. 그런 다음 새 영역을 사용하도록 웹 서버를 다시 구성하고 다시 시작하십시오.

    4

    이 모든 작업을 자동화하려면 일부 배포 스크립트를 고려해야합니다. 그것은 당신이 실수하는 것을 막을 수 있습니다. SQL 업그레이드 스크립트는 삶의 방식이지만 실제 데이터베이스에서 실행하기 전에 항상 실제 데이터베이스 복사본에서 테스트해야합니다.

    스테이징 서버로 고려해야 할 사항은 무엇입니까? 로컬 변경 작업을 수행 한 다음 준비 서버로 svn checkout을 수행하고 업그레이드 스크립트를 실행하십시오. 준비 서버에서 수락 테스트를 수행합니다. 모든 것이 잘되면 라이브 서버에 영구 설치합니다. 이것은 일부 스크립트를 실행하는 것처럼 간단해야합니다. 즉 update-staging.pl 및 update-prod.pl.

    데이터베이스에 버전 표를 추가하여 SQL 스크립트를 자동화하기가 쉽습니다. 업데이트 스크립트를 만들 때마다 버전으로 태그를 지정합니다. 전개 스크립트는 갱신 스크립트의 버전과 데이터베이스의 버전을보고 필요에 따라 갱신 사항을 적용 할 수 있습니다. 이것은 또한 가능한 백업에서 복원합니다. 변경 한 다음 백업으로 복원하는 경우 업그레이드 스크립트를 실행하기 만하면 db가 현재 버전으로 업데이트됩니다.

    +0

    사실, 가능한 경우 언제든지 "롤백"스크립트를 작성합니다. 얼마나 유용한 지 모르겠다. 데이터를 다시 삽입하지 않을 것이기 때문에 적어도 SQL 구조를 다운 그레이드 할 수있는 방법이있을 것이다. –

    3

    Capistrano을 사용하여 & 스크립트를 배포 프로세스 자동화에 사용합니다. 다음은 내 로컬 워크 스테이션에서 을 입력하면 어떻게되는지에 대한 개요입니다.

    Capistrano. . . 내 웹 서버에 (예를 들어 /var/http/mywebsite.com/releases/20090715014527에) 타임 스탬프 디렉토리에있는 소스의

    1. 체크 아웃 최신 버전, 필요한 경우, 어떤 암호에 대한 내 로컬 워크 스테이션 @ 저를 자극.

    2. 실행 전처리 스크립트 (예 : 업데이트 데이터베이스 스키마)

    3. 소프트 링크 라이브 디렉토리 사이트 :

      에선 -sf /var/http/mywebsite.com/releases/20090715014527/VAR/HTTP/mywebsite.com/현재

    4. 실행 후 처리 스크립트 (예 : 어쩌면 당신은 다시 시작해야 아파치 또는 무언가)

    도중에 문제가 발생하면 Capistrano는 이전 작업 릴리스로 롤백합니다.

    Capistrano는 Ruby로 작성되었지만 모든 언어/프레임 워크로 웹 응용 프로그램을 배포 할 수 있습니다. 아이디어는 "Deploying non-rails apps" section of the tutorials을 참조하십시오. railsless-deploy은 Capistrano를 사용하여 PHP 및 Python 응용 프로그램을 배포하는 데 특히 유용합니다. 작은, PHP 기반 시스템 용

    1

    은, 우리가 할하는 데 사용하는 것은 이것이다 : 코드 변경에 대한

    , 우리는 원격으로 로컬 (DEV) 시스템을 비교 이클립스에서 실행 개미 스크립트를 사용 (QA/prod/whatever) 시스템으로 변경 한 다음 변경된 모든 파일을 압축하고 zip을 원격 시스템으로 scp하고 대상에서 압축을 풉니 다. 물론 우리는 자동화 된 백업 등을 가지고 있습니다. 이것이 관심이 있다면 앞으로 며칠 안에 예제 스크립트를 게시 할 수있을 것입니다.

    , 우리는 각 변경 사항 (일반적으로 버그 추적기에 있음)에 대한 스크립트를 유지하고 대상 시스템에서 각 변경 사항을 수동으로 실행하려고합니다.

    큰 시스템의 경우 더 강력한 기능을 사용합니다.

    당신의 찌르다 시스템이 svn에서 직접 당기는 경우 제대로 테스트되지 않았을 수도있는 변경 사항을 디플로이하고 있습니다 (무언가를 저 지르거나 로컬 시스템을 테스트하는 것을 잊어 버리거나 모든 것이 손상 될 것입니다 ...)

    +0

    about zip : 이전 파일을 삭제하면 어떨까요? 마지막 발언은 +1 입니다. 나는 조금 있었어. –

    +1

    사실 저는 항상 이전 zip 파일을 유지합니다. 나는 yyyymmddhhmiss.zip이라고 지명한다. 그래서 언제 정확하게 정확히 어떤 코드를 넣을 수 있었는지 정확히 알 수있다. 내 백업이 실패하면 구버전으로 되돌릴 수도있다. 디스크 공간이 부족 해지면 만 삭제합니다. –

    1

    첫 번째 옵션을 권하고 싶습니다. 링크를 변경하여 코드 버전을 넣고 그 사이를 넘길 수있는 구조가 있다면 svn 체크 아웃을 사용하는 것보다 롤백하는 것이 훨씬 쉽습니다. svn을 사용하면 되돌리려면 이전 버전과 병합해야합니다.

    관련 문제