테스트 및 프로덕션 환경을 동일한 시스템에 두는 것은 좋지 않습니까?

Question

MySite.com이 생산되고 test.MySite.com이 테스트가되도록 설정하는 것이 좋지 않습니까? 둘 다 같은 기계에서 작동합니다. 사이트는 많은 트래픽을 얻지 못합니다.

UPDATE

나는 Windows 서버에서 실행되는 ASP.NET 웹 응용 프로그램에 대해 이야기하고있다.

Answer 1

예, 좋지 않은 생각입니다.

테스트 코드에 메모리/CPU/디스크 공간을 모두 소모하는 버그가 있다고 가정 해보십시오. 그런 다음 제작 사이트가 다운됩니다.

프로덕션 및 테스트를 위해 별도의 시스템을 사용하고 DNS를 사용하여 URL을 지정하십시오.

---

편집 (더 많은 포인트) :

사이트가 기계를 공유하는 경우는 IP 주소를 공유하므로 사이트에 액세스하는 IP 주소를 사용하는 경우, 당신은 당신이 생산에 있는지 알 수 없습니다 또는 테스트.

동일한 컴퓨터를 공유 할 때 배포가 까다로울 수 있으므로 테스트되지 않은 코드를 프로덕션 환경에 배포하지 않도록주의해야합니다. 둘 다 동일한 시스템에 있기 때문에 더 쉽게 수행 할 수 있습니다.

프로덕션 및 테스트에 대한 보안 고려 사항은 별도로해야합니다. 이러한 종류의 설치로 인해 더 어려워집니다.

Answer 2

나쁜 생각입니다. 테스트되지 않은 새 기능이있을 때 프로덕션 사이트를 죽일 수 있습니다.

Answer 3

모든 종류의 표준 준수가 문제입니까? 일반적으로 개발자는 테스트 환경에 대한 많은 액세스 권한을 갖고 문제를 해결할 수 있기를 원합니다. 그러나 개발자가 프로덕션 시스템에 동일한 수준의 액세스 권한을 갖는 것이 항상 좋은 아이디어는 아닙니다 (또는 심지어 허용되는 것은 아닙니다).

Answer 4

동일한 컴퓨터에서 테스트 및 프로덕션 환경 업데이트 (새 버전의 php/perl/python/apache/kernel/whatever)를 테스트하는 것은 정말 어렵습니다.

Answer 5

이론상 그렇습니다. 개발할 때, @Oded와 같이 많은 오류가있을 수 있습니다. 전용 웹 서버에서 주 사이트를 실행하면 중복 된 데이터베이스, 가상 호스트 등의 복잡성을 피할 수 있습니다. 물론 test.mysite.com을 공개적으로 사용할 수 있습니다.

종종 고객이 가장 먼저해야 할 일은 회사 웹 사이트를 방문하는 것입니다. 사이트에 액세스 할 수없는 경우 잠시라도 전문가가 아닌 것처럼 보이고 곧 관심을 잃습니다. 컴퓨터를 하나 더 사기에는 너무 싸기 때문에 사업을 잃고 싶지 않습니다!

편집 : 위에서 언급 한 내용은 실제로 비즈니스 서버라는 것을 알았습니다. 답변이 업데이트되었습니다.

Answer 6

질문이 플랫폼에 특정한 것이 아니기 때문에 일반적인 형태로 답할 것입니다. 모든 일반적인 예방 조치가 취해지면 "도메인 이름"이 매우 쉽게 변경 될 수 있으므로 질문의 "동일한 컴퓨터"부분 만 참조 할 것입니다.

정말 필요한 것은 환경을 격리하는 것입니다. 사용 된 기술에 따라 "별도의 기계"를 의미 할 수도 있고 그렇지 않을 수도 있습니다.

예를 들어, 세계의 많은 중소 규모의 은행이 하나의 메인 프레임에서 중요한 시스템을 실행합니다. 이 짐승들 중 하나가 6 개의 인물 (주변 장치 및 모두)을 소비하는 것은 드문 일이 아닙니다. 그들 중 일부는 개발과 테스트를 위해 별도의 작은 머신을 사용하는 반면, 다른 머신은 동일한 머신에서 수백 개의 환경 (때로는 VM)을 실행합니다. 까다로운 세부 사항은 메인 프레임 하드웨어 및 운영 체제가 디스크, CPU, 통신 채널, 자격 증명, 라이브러리, OS 모듈, DB 등을 할당하는 이러한 환경간에 실제적이고 일관된 격리를 제공한다는 것입니다. 원하는대로.

다른 많은 플랫폼의 문제점은 공룡 플랫폼이 HAL의 은혜로 제공되는 동안 환경을 격리하는 방법을 찾는다는 것은 당신에게 달려 있다는 것입니다.

HTH!

Answer 7

"좋았어, 나, 총을 가진 사람이야." - 애쉬

나쁜 것은 실제로 범위입니다. 지나치게 짧은 변수 이름을 사용하는 경우 마더 보드를 전원에 연결하고 젖은 손으로 교체하는 것 사이에서 어디서든 사용할 수 있습니다. 당신이 정말로 알고 싶은 것은 절충점입니다. 분명히 이점 중 일부를 알고 있거나 테스트를 위해 프로덕션 서버를 사용하지 않을 것입니다.

큰 문제는 공유 환경에서 실행중인 테스트 코드입니다. 프로덕션 서버에 영향을 줄 위험이있는 샌드 박스 (프로세스 제한, 메모리 제한, 디스크 제한, chroot 파일 시스템 등)가없는 경우 테스트에서 문제가 발생합니다. 실수로 특정 리소스를 모두 소비하여 자신을 도용 할 수 있습니다. 실수로 생산 사이트를 제거 할 수 있습니다. 누군가가 부하 테스트를해도된다고 생각할 수도 있습니다. 이러한 위험을 감수하는 것이 좋으면 프로덕션 서버에서 테스트 응용 프로그램을 실행할 수 있습니다.

동의어 : 나쁘다.