웹 응용 프로그램의 개발/테스트 설정에서 dvcs (bzr, git) 을 사용할 때 실제로 저장소 디렉토리에서 응용 프로그램을 실행하는 것이 잘못 될까요?git 또는 bzr 저장소에서 코드를 직접 배포하지 않는 이유는 무엇입니까?
내가 만난 모든 팀은 리포지토리 체크 아웃을 다른 디렉토리 또는 서버로 내보내는 별도의 배포 스크립트를 가지고 있습니다. 그러나 나는 정말로 어리석은 이유를 이해하지 못했고 어른들에게 "어리석은"것처럼 보이지 않기를 두려워했습니다. 내 말은, 어쨌든 그것은 생산 서버가 아니기 때문에 ...?
명확히하기 위해 문제는 실질적으로 이 아니며 배포하는 방법은입니다. 그게 다른 질문입니다. 더 깊은 원칙은 @DaveE가 언급 한 이유로 테스트 환경이 가능한 한 생산에 가깝도록해야한다는 것입니다. 작은 배치 차이로 인해 테스트가 쓸모 없게 될 수 있습니다.
실제 설치를 미러링하는 것이 개발 중에 테스트하기에는 너무 많은 작업이라고 생각합니다. 여기에는 두 가지 해결책이 있습니다. 테스트 환경을 프로덕션 환경과 다르게 만드는 것은 그 중 하나가 아닙니다.
먼저 제작 설치를 쉽게하십시오. 이것은 자동 프로세스로 수동 프로세스 (여기에 파일 복사,이 스크립트 실행, 이러한 권한 변경 ...)를 할 수 있습니다. 또는 실제로 배치가하는 것을 줄일 수 있습니다. 세부 사항을 모른 채 더 이상 말할 수 없습니다.
테스트 환경이없는 경우 dev 환경 은 테스트 환경이이되어 프로덕션 전의 유일한 방어선이라는 더 엄격한 규칙을 따라야합니다. 이를 피하려면 테스트 할 준비 서버를 만드십시오. 스테이징 서버는 가능한 많은 제품을 미러링하는 서버입니다. 개발 사본은 먼저 스테이징 서 v에 설치되고 프로덕션으로 푸시되기 전에 테스트됩니다. 이것은 당신에게 2 단계 테스트 시스템을 제공합니다. 정확하지 않은 개발 환경에서 일부 테스트를 수행하고 전체 테스트 배터리를 준비 환경에서 수행합니다. 전체 테스트 스위트를 항상 실행할 필요는 없으므로 스테이징 서버를 지속적으로 업데이트 할 필요가 없습니다. YMMV. 그런 다음 개발 환경에서 모서리를 잘라내어 개발 속도를 높이면서 모든 것이 제작 전에 전체 설치에서 테스트된다는 것을 알 수 있습니다.
리소스가있는 경우 준비 서버는 프로덕션 환경의 모든 하드웨어 및 소프트웨어를 완벽하게 반영합니다. 아마도 가상 머신이나 하위 디렉토리 일 수 있습니다.나머지 팀에서 구매할 필요가 없다면 둘 다 개발 컴퓨터에서 살 수 있습니다.
설치 프로세스와 준비 서버를 자동화하면 continuous integration testing을 시작할 수 있음을 의미합니다. 이는 "모든 커밋에서 테스트 서버에서 테스트를 자동으로 실행"하는 멋진 용어입니다. 연속 통합 시스템의 예는 Jenkins입니다. 그렇다면 배치가 얼마나 복잡한 지 상관없이 로봇이 처리해야합니다.
처음에는 까다로운 작업처럼 보일 수도 있지만, 버튼을 누르지 않아도 테스트가 가능하도록 모든 것이 함께 제공됩니다.
궁극적으로 새 코드는 실제 푸시되기 전에 가능한 한 프로덕션과 유사한 환경에서 테스트해야합니다. 이를 달성하는 데는 여러 가지 방법이 있지만 이는 견고한 규칙입니다.
자세한 답변을 보내 주셔서 감사합니다! ... 그래서 나는 확실히 테스트 서버/VM을/설치해야하고 dev 설치가 덜 정확한지 (그리고 만약 내가 바보 같은 일을하는 경우에는 dev 설정에서 repo에서 실행하는 것과 상관 없다.). 가장 단순한 솔루션이 무엇인지 이해하려고 시도한 것은 재미 있습니다. 연속적 통합 테스트와 같은 "복잡한"설정이 왜 존재하고 왜 실제로 도움이 될 수 있는지 이해할 수있었습니다. – NeuronQ
경로와 권한이 거의 비슷해서 오류가 현실을 반영 할 수있는 런타임을 살펴 보시겠습니까? 그렇지 않으면 비공개로 해결 될 괴상한 문제를 해결하기 위해 시간을 보내시겠습니까? - 표준 배포의 고유성? 당신은 당신이 로컬 관리자있어
또는 여러 가지 일을 느리게하지만 품질이 좋은 코드를 제공하는 데 기여하지 않는 여러 가지 작업 중 하나입니다.
tl; dr : @Schwern이 말한 내용.
다음과 같이 요약 할 수 있습니다. dev/test 설치를 가능한 한 프로덕션 설치에 가깝게 만드십시오. 그렇지 않으면 사용자가 사용중인 것과 동일한 것을 테스트하지 않을 것입니다. 당신이 평행 우주에서 일하고있는 것처럼. – Schwern
실제로 개발자 서버가 main/central repo 또는 다른 3 단계 설치 중 적절한 3 단계 설치를 호스팅하는 개발 서버와 다른 테스트 서버가있는 경우에는 의미가 있습니다. 주요 저장소가 dev 서버에 있으며 별도의 테스트 서버가 없습니까? (나는 이런 종류의 설정을 본 적이 있습니다 ...) – NeuronQ
절대적으로 필요한 경우 서버에서 repo를 사용할 수 있지만 테스트를 위해 non-repo 위치에 배포 할 수 있습니다. 귀하의 repo는 웹 서버의 배치 위치에 없어야합니다 *. 그건 그냥 바보 같을거야. – DaveE
나는 공격적인 단어가 허용되지 않는다는 것을 알았습니다. –
@Schwern ... 마지막에 주제가 호언 장담하고 습관으로 f 단어를 사용하는 것에 대해 유감스럽게 생각합니다. q를 다시 읽으면서 나는 그 점에 대해 아무런 지적이 없다는 것을 깨달았고 그냥 삭제하거나 downvoting하는 대신 편집 해 주셔서 감사합니다. 건배! – NeuronQ