서버에 Mercurial을 설치하고 배포하는 것이 좋습니다.

지난 달에 새 직장을 시작했는데 코드에 대한 소스 제어가없는 것 같습니다. 그들은 호스팅 제공 업체가 제공하는 백업에 의존하고 있습니다.

약간 이야기를 한 후 나는 상사에게 소스 컨트롤을 사용해야한다고 확신했고, 짧은 세미나를 마치면 전체 팀이 참여했습니다. 그들은 Mercurial을 좋아했습니다.

바로 지금 이것이 우리가 일하는 방식입니다.

º----------BitBucket
º---------/
º--------/

저 자신과 hg pullBitBucket의 다른 세 개발자 가 변경 한 다음 hg pushBitBucket으로 변경 합니다.

이제 배포를 위해 누군가는 최신 파일을 프로덕션 서버로 FTP해야합니다.

서버에 Mercurial을 설치하고 hg clone(결과적으로 hg pull)를 사용하여 프로덕션 버전을 최신 상태로 유지하려고 생각했습니다.

º---push->-----BitBucket----<-pull-----º (production server)
º---push->----/
º---push->---/

이것이 좋은 생각입니까? 내가 볼 수없는 잠재적 인 함정은 무엇입니까? 여기에 비슷한 일을 한 사람이 있습니까? 대규모 PHP 프레임 워크 응용 프로그램을 어떻게 배포합니까 (Moodle을 사용하고 있습니까)?

이것은 확실히 좋은 생각이며 배포에 사용하는 일반적인 방법입니다. 안정적인 개발을 위해 트렁크를 유지하면서 배포 목적으로 안정적인 브랜치를 사용하여 프로덕션에 배포하기 전에 안정적인 브랜치를 테스트 할 수 있습니다.

코드베이스에 API 키 등의 민감한 정보가있을 경우 타사 서버 (귀하의 경우 Bitbucket)에 업로드하지 않으려는 유일한 문제가 발생할 수 있습니다. 이 경우 리포지토리에서 데이터를 가져와 올바른 위치에 중요한 데이터를 복원 한 후에 실행되는 간단한 스크립트로 해당 문제를 해결할 수 있습니다.

이 배포 전략이 원 자성이 아니라는 점에 유의하십시오. 응용 프로그램이 실행되는 동안 일부 파일이 이미 업데이트 된 상태에서 다른 파일이 여전히 이전 상태 일 수 있습니다. 예기치 않은 부작용이 발생할 수 있습니다.

원자 배포를 수행하는 방법은 심볼릭 링크를 사용하는 것입니다. 새 파일을 포함하는 디렉토리를 작성하십시오. 모든 것이 준비되면 사용 된 디렉토리의 심볼릭 링크를 변경하십시오. 이전 버전을 유지하면 쉽게 롤백 할 수도 있습니다.

또 다른 (제 생각에 더 나은) 가능성 : 빌드 서버 / 지속적인 통합 서버를 사용합니다.

간단한 짧은 설명 : 이것은 저장소를 모니터링하기 위해 설정 한 서버 (사내에서 인터넷에있을 필요가 없음)이며 저장소에 새로운 변경 세트가있을 때마다 서버가 코드를 작성합니다 ( AFAIK는 PHP에서 필요하지 않습니다.) , 단위 테스트를 실행하고 코드를 웹 서버에 배포합니다.

자세한 내용은 다음 링크를 확인하십시오.

• CI에 관한 Wikipedia 기사
• 스택 오버플로 질문 : "빌드 서버"의 요점은 무엇입니까?

CI에는 다양한 제품이 있지만 지금까지 사용한 유일한 제품 은 TeamCity 입니다. 설정하기가 매우 쉽습니다 ... 실제로 시도한 첫 번째 제품이므로 너무 좋아해서 고집했습니다.

대체 저렴한 솔루션 :

빌드 서버를 설정하는 데 너무 많은 노력이 필요하거나 사이트가 정확히 배포되는 시기를 더 많이 제어 하려면 스크립트 파일 (Windows의 배치 / Powershell 또는 Linux / Mac의 경우 이와 유사한 것) 을 설정하십시오. 리포지토리의 최신 버전을 프로덕션 서버에 FTP로 보냅니다.

기본적으로 빌드 서버와 동일하며 더 간단합니다.

결국 정확히 어떻게 해결하든간에 어떻게 든 자동화해야합니다!

한 번의 클릭으로 / 하나의 명령을 입력하여 배포 할 수 있기를 원하므로 모든 사람이 특별한 것을 알 필요없이, 심지어 재난이 발생하거나 스트레스를받는 경우에도 실수를하지 않고도 명령을 수행 할 수 있습니다.

우리는 이것을하거나 이와 비슷한 것들을합니다. 비 원자 @johannes는 각도가 한 가지 문제라고 언급하지만 현실적인 용어로는 너무 빨리 발생하지만 괜찮아 야하며 지적한 대로이 문제를 해결할 수있는 방법이 있습니다.

아마도이 비원 자성보다 더 중요한 것은 "데이터베이스 스키마 업데이트 관리 방법"일 것입니다. 이런 방식으로 잘못된 코드를 배포하면 쉽게 해결할 수 있습니다. 가장 큰 문제는 롤백하려는 데이터베이스를 변경하는 업데이트를 배포 할 때 발생합니다. 또는 업데이트가 잘못되고 데이터가 손상된 경우.

우리가 DCVS 도구와 관련한 또 다른 문제 (SVN 사용과 반대)는 이제 공격자가 잠재적으로 파악할 수있는 시스템에 전체 코드베이스의 복사본이 있다는 것입니다. 또한 DCVS 코드베이스는 크기가 상당히 무거워서 스토리지 및 / 또는 백업 비용을 지불하는 경우 중요 할 수 있습니다. 이러한 이유로 최종 배포에는 여전히 SVN을 사용하고 있습니다.

좋은 생각이지만 다음 사항을 명심하십시오.

• 플러그인을 설치하거나 컨텐츠 자산을 추가하는 등의 경우는 드물지만 서버에서 커밋하지 마십시오.
• 테스트를 위해 스테이징 서버 또는 보조 저장소 배치 사용
• hg update -C프로덕션에 영향을 미치지 않도록 항상주의하십시오 (예 : 중요한 파일 삭제)
• 프로덕션 및 개발 지점을 보유하고 프로덕션 지점 만 배포
• 자산을 백업 (예 : 콘텐츠 이미지)으로 취급하고 사용자 데이터 (예 : 첨부 파일 / 업로드, 캐시 등)를 무시합니다.
• 항상 hg status서버에 깨끗한 출력이 있어야합니다 (캐시를 무시하는 데 도움이됩니다).
• 웹 폴더에 저장소를 배치하지 마십시오. 공용 공간 외부에서 심볼릭 링크를 사용하십시오 (예 : ln -s / myrepo / src / web / public_html / myapp)
• 구성 파일 (특히 데이터베이스 비밀번호 또는 기타)을 버전 화하지 않도록주의하십시오.
• 프로덕션 백업 대신 사용하지 마십시오. 프로덕션 데이터가 아닌 프로덕션 코드 의 개발 백업입니다.

마지막으로, 배포 프로세스에 DVCS를 추가 할 때 가장 유용한 것은 배포에 보안을 추가하고 해커가 악의적 인 코드를 물건에 삽입하기 때문에 버전 제어와 같은 방법으로 쉽게 탐지 할 수있는 방법이 없다는 것입니다. VCS에 대한 분산 측면을 사용하면 파일의 무결성을 쉽게 확인할 수 있으므로 특별히 분산됩니다.

Mercurial을 사용하면 서버에서 서버를 발급하여이 해킹을 문자 그대로 실행 취소 hg update -C할 수 있습니다 (물론 hg status나중에 분석을 위해 영향을받는 파일을 가져와야 할 수도 있습니다 ).