(높은 수준의 소프트웨어 개발 관련 질문입니다.)웹 서버에 업로드하지 않고 코드를 테스트하려면 어떻게해야합니까?
저는 웹 앱을 운영하고 있습니다. 과거에는 새로운 기능을 테스트하기 위해 test /와 같은 하위 디렉토리에 업로드했습니다. 이것은 일반적으로 모든 URL을 파기했기 때문에 테스트 코드에서 URL을 다시 실행해야합니다. 그런 다음 메인 사이트로 푸시했을 때 모든 URL의 이름을 바꾸어야합니다. 더 나은 방법이있을 것이라고 확신하지만 사람들이 일반적으로하는 일을 알지 못합니다.
노트북에 웹 서버를 설치합니까? 저는 항상 값싼 컴퓨터를 구입하여 테스트 웹 서버로 실행할 수 있습니다.
결국 저는 친구와 함께 버전 제어 시스템을 만들고 싶습니다. 그래서 우리는 우리 노트북에 Apache와 MySQL을 모두 설치해야합니까? 그렇게하면 새 코드를 테스트 할 때 서로 간섭하지 않습니다.
두 답변 :
플랫폼에 따라 크게 다를 필요는 없습니다. Ruby on Rails 애플리케이션을 개발하고 있다면 웹 서버가 내장되어 있고 다른 것들은 쉽게 설치할 수 있습니다. Tomcat 또는 Apache의 로컬 복사본은 문제가되지 않습니다. IIS의 경우 올바른 버전의 Windows를 실행할 필요가 있다고 생각합니다.하지만 잠시 동안은 그 분야에서 일하지 않았습니다.
대타로 가상 컴퓨터에서 서버 환경을 실행할 수 있습니다. 이렇게하면 실제 서버의 정확한 환경을 쉽게 복제 할 수 있다는 장점이 있습니다. 때로는 사용자 자신의 컴퓨터에서 문제없이 작동하지만 사용 권한 문제 나 환경 설정 등으로 인해 서버에서 작동하지 않는 상황에서 실행될 수 있습니다. 이것들은 디버그하기가 힘들 수 있습니다. 서버 환경을 복제하는 VM은이를 방지하는 한 가지 방법입니다. 자바에 대한 JUnit 같은
로컬 컴퓨터에서 실행중인 개발 버전의 앱이 있어야합니다. 웹 프레임 워크에 따라 쉽거나 어려울 수 있습니다. 예를 들어, grails에는 로컬에서 쉽게 실행할 수있는 도구가 있습니다. 그러나 상관없이, 당신은 확실히 이것을해야합니다. 많은 경우 서버, 특히 프로덕션 환경에 익숙한 서버에 문제가 발생할 수 있습니다. 시간을 투자하고 제대로 설정하십시오.
다른 답변에서 지적한 것처럼 단위 테스트.
귀하와 귀하의 친구는 각 랩탑에 WAMP/LAMP 스택을 설치할 수 있습니다. 버전 관리 시스템이 필요한 경우 SVN 또는 Git을 모두 사용할 수 있습니다.
프로덕션 서버의 디렉터리 구조를 복제 할 수 있도록 폴더를 구조화합니다. 그렇게하면 배포 시간이되면 URL을 다시 쓸 필요가 없습니다. 가상 호스트가 도움이 될 것입니다.
로컬로 테스트 할 때 로컬 We Server 및/또는 App Server를 실행하는 것이 나에게 평범한 것 같습니다.
큰 커뮤니티에 공개되는 "스테이징"서버가있을 수도 있습니다.
링크를 상대 링크로 만들면 이전 버전과 새 버전을 동일한 서버에서 병렬 실행하여 다른 컨텍스트 루트로 배포 할 수 있습니다. 대규모 시스템의 경우 이는 매우 유용합니다. 사용자의 다른 커뮤니티를 새로운 시스템으로 축소하여 점진적으로 배포 할 수 있습니다.
서버가없는 단위 테스트도 중요하지만 때로는 사용자가 서버에서 실행해야하는 새 버전을 사용자에게 허용하기 전에 동의합니다.
특정 언어 나 기술 또는 일반적인 것일 수 있습니까?
내 작품은 지금은 회사 전체 소스 트리 체크 아웃 내 로컬 컴퓨터에 내장되어, 자바와 파이썬
자바 코드에 대한에서 대부분의 웹 애플리케이션이고, 나는 테스트 할 때, Jetty 웹 서버를 로컬로 실행하여 배포를 테스트합니다.
우리 코드에는 모두 단위 테스트가 있으며, 사용되는 공용 언어에 대한 단위 테스트 패키지가 있습니다.
파이썬 들어, 내 작품은 대부분 장고에 포함되어 있으므로 포함 된 테스트 서버를 사용합니다.
일반적으로 웹 물건을 테스트하기 위해 로컬 인스턴스 인 lighttpd을 실행했습니다. 가볍고 구성하기 쉽습니다.
예상대로 동작하는지 확인하기 위해 실제 UI를 테스트하거나 사용자가 문제를 일으키지 않았는지 확인하려면 Selenium 또는 Mechanize을 로컬로 설정할 수 있습니다.
회사의 경우 크게 두 가지 환경, 즉 QA 샌드 박스와 프로덕션 환경이 있습니다. QA 샌드 박스는 개발자가 먼저 응용 프로그램을 배포 한 다음 프로덕션에 배포하기 전에 모든 것이 제대로 작동하는지 테스트하는 서버입니다.
버전 관리에서는 subversion을 사용하지만 대부분의 개발자는 변경 사항을 중앙 Subversion 서버로 다시 보내기 전에 로컬 컴퓨터에서 버전 제어를 수행 할 수 있도록 git-svn 또는 hg-svn을 사용합니다.
파일에 구성 매개 변수를 설정하여 URL이 손상되지 않도록하고 테스트 환경과 기본 환경간에 이동할 때 구성 파일 만 변경하십시오. 환경의 일부가 끝나고 상자를 빠르게 전환해야하는 경우에 대비하여 라이브에 가기 전에이 기능을 원할 것입니다. DB 연결 문자열, 환경 종속 URL 및 환경간에 변경되는 사항을 포함시켜야합니다.
단위 테스트, 단위 테스트, 단위 테스트. 더 높은 수준의 테스트가 필요한 경우 작업을 수행 할 가장 낮은 수준의 테스트를 작성하십시오. 모의 (mock)를 사용하여 다른 구성 요소와의 상호 작용을 테스트하려는 구성 요소로만 제한하십시오.
정기적으로 일종의 테스트 환경에서 테스트하고 싶지만, 수행해야하는 빈도와 테스트에 의존하는 방법을 제한하여 제품의 현재 그림을 제공 할 수 있습니다 위의 기술로 품질.
가상 인스턴스를 사용하는 것을 선호합니다. 인프라를 표준화하면 서버의 "프로덕션"인스턴스를 로컬 시스템으로 복사하는 것만 큼 간단합니다. 이것은 "흠 ... 내 컴퓨터에서 작동 중"이라는 문제의 대부분을 제거합니다.