2009-06-23 3 views
0

저는 웹 사이트 솔루션을 고객에게 판매하는 중소기업이 있습니다. 웹 사이트는 동일한 목적을 수행합니다. 고객이 SMS 메시지를 보내고 예약하도록 허용합니다.여러 고객을위한 웹 사이트 배포/관리

각 웹 사이트는 약간 다릅니다. 예를 들어 주소 세부 정보 및 그룹 이름과 같은 필수 정보가있는 사이트 1 개와 사용자의 IP 주소 로깅과 같은 다른 요구 사항은 있지만 주소 세부 정보는 필요하지 않은 사이트가 있습니다.

모든 웹 사이트는 LINQ TO SQL을 사용하여 작성되었으며 웹 응용 프로그램이 아닌 웹 사이트입니다.

각 웹 사이트는 내 서버에 자체 데이터베이스가 있습니다.

각 웹 사이트는 exe를 사용하여 메시지를 보냅니다. 그 exe는 같은 exe이지만 각 웹 사이트는 사이트의 bin 디렉토리에 위치한 자체 복사 및 예약 절차를 가지고 있으며 Windows 예약 작업을 사용하여 해고됩니다.

각 웹 사이트는 동일한 웹 서비스를 사용하여 메시지를 보내고 응답을 보내는 중앙 서버와 통신합니다.

고객은 ASPX 페이지를 변경할 수 있지만 코드는 배제 할 수 없습니다. 순간

, 내가 좋아하는 뭔가를 읽어 내 dev에 컴퓨터의 파일 구조가 있습니다 이

Client2Dev 이

을 Client2_Published Client1_Published

Client1Dev을 ... 등등

별도로 폴링 애플리케이션 (Windows 콘솔 앱)이 있습니다.

변경을 수행 할 때 클라이언트 사이트를 _Published 디렉토리에 게시 한 다음 bin 디렉토리에서 프로덕션 서버로 DLL을 복사합니다.

제 질문은이 물건을 관리하는 것이 무엇입니까? 클라이언트 1이 변경되면 dev 사이트로 변경하고 게시 된 파일로 복사 한 다음 프로덕션으로 FTP로 변경합니다.

새 사이트를 구축 할 때 새로운 고객에게 유용 할 수있는 다른 클라이언트 프로젝트의 변경 사항이있을 수 있으므로 악몽입니다.

버그를 발견하면 실제 악몽이므로 모든 사이트를 1을 기준으로 1로 업데이트해야 버그 수정으로 특정 프로젝트가 중단되지 않습니다.

이것에 대한 조언이 필요하십니까?

답변

1

소스 제어, 자동화 된 테스트. 간단히 말해서, 프로세스.

주 개발 라인이 있고 클라이언트 당 하나의 브랜치가 있어야합니다. 클라이언트 브랜치에 대한 일부 변경 사항은 메인 브랜치에 병합 된 다음 다른 클라이언트의 브랜치에 병합되기를 원합니다.

자동 테스트를 실행하여 이러한 변경 사항을 테스트하고 다른 클라이언트에 대해 이러한 테스트를 버전 관리해야 할 수도 있습니다.

실제로 클라이언트가 많은 변경을 할 수 있도록 노력해야 할 가치가 있는지 스스로에게 자문해야 할 수도 있습니다.당신은 당신의 온건함을 유지하기 위해 그들이 할 수있는 변화의 수와 종류를 제한해야 할 수도 있습니다.

0

나는 비슷한 설정 일한 그것은 밖으로 쉬운 방법으로, 악몽이다.

하나의 옵션은 변경 사항이있는 경우, 당신은 다음 추적 할 수 있습니다 SVN을 사용하고 각 클라이언트에 대해 지점을하는과와 중앙 트렁크에서 복사 할 것입니다. 이것은 "표준 분기 패턴"중 하나가 아니지만 많은 클라이언트와 함께 거대한 코드 기반에서 사용되는 것을 보았지만 정상적으로 작동합니다. 고객이 유지 관리비를 얼마나 지불 하느냐에 달려 있습니다.

개인적으로 난 당신이 제공하는 더 나을 것이라고 생각 [유연한 CMS] [1] 및 각 클라이언트를 별도의 데이터베이스 및 테마를 제공합니다. 당신이 그것을 천천히 굴리기를 원할지도 모르지만 장기적으로는 훨씬 쉬울 것입니다. 집과 오픈 소스 CMS에서 일하면서 오픈 소스 경로가 많은 이점을 갖는 것으로 보입니다.

당신은 잘 핵심 코드로부터 분리 된 클라이언트 코드를 유지, 각 클라이언트의 사용자 정의 기능에 대한 특정 모듈을 가질 수 있습니다. 또한 이렇게하면 cms 코드가 고객 별 코드와 별개이므로 코드 유지 관리 문제를 해결할 수 있습니다.

다른 포스터에는 자동화 된 테스팅과 관리를 이야기 할 때 포인트가 있다고 생각합니다. 그러나 길어진 길 끝에는 작은 규모의 웹 사이트에서 노력을 정당화 할 수 있는지 모르겠습니다.

+0

CMS 방식의 문제점은 변화는 단순한 표현보다는 기능적입니다. 예를 들어 1 클라이언트는 휴대 전화 번호를 가지고 다음 다른 사이트가 없지만 신원을 확인하기 위해 그 번호로 문자를 보낼 필요가있다. SVN에서 분기를 사용하는 방법에 대한 좋은 동영상이나 일반적인 문서가 있습니까? – Paul

+0

나는 stratergies를 설명하는 것을 돕기 위해 이것을 편집했다. Svn 분기는 svn docs http://svnbook.red-bean.com/en/1.5/svn.branchmerge.html에서 설명합니다. –

0

는 소스 제어 가이드 에릭 싱크의를 살펴 않았다 가지고 다음 빌드 프로세스를 개선하기 위해 크루즈 Control.net 같은 것을 봐있다. 대부분의 자동 빌드 도구는 스크립트 등으로 사용자 정의하여 코드를 푸시하기 전에 필요한 맞춤 단계를 수행 할 수 있습니다.

0

복잡성을 최소화하기위한 한 가지 방법은 소스 코드 저장소에 분기를 하나만 넣은 다음 SOLID에 명시된대로 the Open Closed principle을 혼합하려고 할 수 있습니다. 그렇게하면 소스 트리를 분기하지 않고 고객이 요청한 변경 사항을 제공 할 수 있어야합니다. 내 마음에 떠오른 첫 번째 아이디어는 "공장 패턴 사용"이었지만 내가 보는 문제가 발생하지 않도록 패턴을 던지지 않는 어려운 방법을 배웠습니다.

관련 문제