2008-10-23 4 views
5

어쩌면 저는 조금 오래된 학교 일 수도 있지만 과거에 웹 사이트를 만들었을 때 개발 서버에서 사이트를 개발 한 다음 페이지를 게시하거나 홍보했습니다 파일을 프로덕션 서버로 전송합니다. 이것은 항상 사용자가 엉망인 페이지를 보지 못하게하거나 (God God 'sbased) 서버가 다운 된 서버를 보지 못하게하는 좋은 방법 인 것처럼 보였습니다.MOSS '07 사이트를 Dev에서 Production으로 승격

그러나 SharePoint를 만들 때 Microsoft가이 아이디어를 염두에두고있는 것 같지 않습니다. 적어도 정의 된대로 인프라에서이를 수행 할 수있는 방법을 찾을 수 없었습니다.

SharePoint 개발을위한 관리 전략이 있는지 아는 사람 있습니까? 저는 온라인을 통해 개발 환경을 백업하고 프로덕션 서버로 복원 할 수 있다고 읽었습니다. 처음에는 작동하지만 프로덕션 서버의 모든 업데이트는 프로덕션 서버의 데이터 손실 위험 없이는 수행 할 수 없습니다. 목록 내용, 페이지 및 문서를 한 서버에서 다른 서버로 마이그레이션하기위한 도구를 보았습니다. 아직까지는 조사하지 않았습니다.

하지만 내 관심사 중 하나는 맞춤 콘텐츠 유형입니다. 목록에서 콘텐츠 형식을 사용하면 목록에서 항목을 삭제하거나 콘텐츠 형식의 연결을 해제하거나 콘텐츠 형식을 다시 연결하지 않고도 목록을 업데이트 할 수 없습니다. 콘텐츠 형식을 업그레이드 할 수있는 방법이 있습니까?

어쨌든 이러한 현재 딜레마에 대한 제안 사항이 있으면 알려 주시면 감사하겠습니다. 사전에

감사합니다,


은 빠른 답변 주셔서 감사합니다.

우리 사이트에는 이미 만든 여러 가지 기능과 기본 사항 (콘텐츠 형식, 열 등)에 대한 기능을 묶는 솔루션 패키지 및 브랜딩 (페이지 레이아웃, 마스터 페이지 등)과 관련된 기능에 대한 또 다른 솔루션이 이미 있습니다. .)

그러나 이것은 일회성 촬영 인 것처럼 보입니다. 기본적으로 서버가 설정됩니다. 맞습니까? 사람들이 프로덕션 환경을 사용하기 시작하면 문서, 페이지, 목록 항목이 모두 콘텐츠 데이터베이스에 존재하므로 콘텐츠 형식, 열과 같은 항목을 업데이트 할 수 없습니다.

새로운 기능을 설치하고 정품 인증하려면 먼저 비활성화하고 제거해야합니다. 맞습니까? 기능 정의에서 Version 속성을 보았습니다. 그러나 내가 말할 수있는 한 가까이에서, 이것은 아무 것도하지 않습니다. 솔루션은 버전 번호를 증가시켜 업그레이드 할 수있는 것처럼 보이지만 특히 콘텐츠 유형 및 열 (특히 사용중인 경우)을 수정하지 않는 것 같습니다. 또한 솔루션을 통한 업그레이드가 얼마나 광범위한 지 잘 모르겠습니다.

이런 종류의 문서에는 소중한 문서가 있습니다. 제가 읽고있는 모든 것이 마치 처음에 SharePoint 서버를 설치하는 방법입니다. 장기적으로 관리하지는 않습니다.

어떤 조언이나 제안이 있습니까?


귀하의 제안에 감사드립니다.

하지만 Google은이 사이트를 1 년 넘게 사용해 왔습니다. 저는 여러분이 대부분 추천하고있는 것에 따라 우리가 이미 설치되어 있다고 확신합니다.우리는 이미 콘텐츠 형식, 열, 마스터 페이지, 페이지 레이아웃 및 워크 플로 등을 설치하는 몇 가지 기능을 갖추고 있습니다. 이러한 기능의 대부분은 솔루션 패키지에 포함되어 있습니다. 우리는 모든 개발 환경을 VPC 서버로 설정했습니다.

그래서 초기 배포가 거의 완료되었습니다. 내가 정말로 알고 싶은 것은 컨텐트 유형 및 컬럼과 같은 것들을 업그레이드 할 수있는 방법입니다. 사용중인 콘텐츠 유형을 변경할 수 있습니까? 그것은 나의 초기 테스트에 기초하여, 이것이 가능하지 않기 때문에 보이지 않기 때문에. 어셈블리를 걱정할 필요는 없습니다. 스왑 아웃을하는 것처럼 보이지만, 컨텐트 유형을 업데이트하는 유일한 방법은 참조하는 항목 (즉, 내 페이지 라이브러리의 모든 페이지)을 삭제하고, 콘텐츠 유형을 선택한 다음 다시 추가하십시오.

초기 배포 후에 콘텐츠 형식을 업데이트하는 방법이 있는지 알고 있습니까? ... 이미 배포 한 콘텐츠 유형을 기반으로 사용자가 이미 항목을 만들었습니까?

는 (내 질문의 다른 부분은 실제로 생산 개발 서버에서 기존 페이지를 이동했지만, 나는 그없이 살 수 있습니다. 내 큰 걱정은 콘텐츠 형식입니다.)

답변

5

개발하고 이동하는 가장 좋은 방법은 기능이 있습니다. 기능이 완료되면 솔루션 패키지 (WSP라고 함)를 사용하여 기능을 배포하십시오.

남아있는 유일한 일은 해당 기능을 다시 활성화하는 것입니다. 그렇게하면 프로덕션 환경에서 모든 작업을 수행하지 않고도 새로운 기능을 점진적으로 출시 할 수 있습니다.

WSPBuilder은 WSP를 작성하는 데 도움이되는 응용 프로그램입니다.

이 모든 것을 자동화하려면 ... 행운을 빈다. 많은 작업이 필요합니다.

업데이트 : 콘텐츠 유형 및 열 배포는 까다 롭습니다. 일단 웹 사이트가 생성되면 기능을 통해 더 이상 웹 사이트를 업데이트 할 수 없습니다. 코드를 살펴보고 모든 사이트를 반복적으로 살펴보고 이름과 일치하는 특정 콘텐츠 형식을 수정해야합니다.

우리는 시도했지만 정상적으로 기능을 수행 할 수 없습니다. 이것은 내가 "코드로 배포"라고 부르는 것을 통해 갈 필요가 있습니다.

1

크리스 오브라이언 가장 최근의 포스트에서 살펴 본다, 그의 훌륭한 콘텐츠 배포 마법사 추천 : it's not all about Features!

+0

감사합니다 ...이 부분을 확인해 보겠습니다. 전에 사용해 봤어? 잘 작동하는지 알고 있습니까? – Dan

+0

그래, 잘됐다! –

1

맥심 (오른쪽 솔루션에 싸여 않는 기능을 통해 배포해야하는 대부분의 항목에 WSP 파일을). 전략은 솔루션과 어셈블리가 관련 기능 비트로 분리되어 있는지 확인하는 것입니다. 이는 사이트 및 웹과 같은 특정 수준에서 기능을 격리 할 수 ​​있다는 점에서도 유용합니다. 콘텐츠 업데이트를 업데이트 할 때 기능 활성화 코드, 비활성화 코드 및 기능 스테이플 링을 사용해야합니다. 콘텐츠 배포도 의미가 있습니다.

기억해야 할 점은 업데이트가 코드에만있는 경우 기능을 다시 활성화하거나 솔루션을 수축 및 재배포하지 않고도 어셈블리를 업데이트 할 수 있다는 것입니다. 필요한 것은 재설정 할 응용 프로그램 풀뿐입니다.

Microsoft는 개발 환경에 대한 몇 가지 기사를 가지고 있으며 환경을 권장하는 많은 사람들이 Google에 참여할 수 있습니다. 우리는 가상 시스템에 대한 개발을 수행하고 대부분의 항목을 가상 통합 서버에 배포합니다. 일단 우리가 테스트를 연기하면 QA에 솔루션을 배포합니다. 기능 및 솔루션의 이점은 취소하기 쉽습니다. 일단 생산에 들어가면 시험을 마쳐야합니다.

SharePoint에서 개발하는 것은 당연한 말이지 만, 지금까지 나는 이점이 문제를 초과 실행하는 것으로 나타났습니다.

Team-Based Development in Microsoft Office SharePoint Server 2007

2

당신은 정말 각 콘텐츠 형식이 설정 GUID를하고 같은 이름을 사용하여 데이터베이스에 저장됩니다 그런 식으로하기 때문에 기능을 사용하여 콘텐츠 형식을 정의 할 필요가있다. 이것은 사이트를 통해 CAML 쿼리를 실행할 때 중요 해지고, 컨텐츠 유형이 "무언가"로 만들어지면 몇 가지 작은 문제가 있습니다.

나는 맞춤형 콘텐츠 유형을 사용하여 솔루션을 출시하기 위해 STSDev을 선호합니다.

서버의 페이지를 편집하는 방법에는 두 가지가 있습니다. 주 및 부 버전을 포함하도록 페이지 라이브러리를 정의 할 수 있습니다. 이를 통해 편집자는 페이지와 게시자를 편집하여 게시 할 수 있습니다. 이것은 내부 사이트에서는 좋지만 공개 사이트에서는 권장되지 않습니다. 당신은 내가 생산 릴리스에 앞서 가기 전에 당신이 콘텐츠 유형에 대한 기능을 가지고 있는지 확인 충분히 강조 할 수 Content Deployment

사용해야합니다 공공 직면 사이트

.

여기에 언급 된 것처럼 Chris O'Brian에는 필요하지 않은 한 기능을 사용해서는 안된다는 내용의 게시물이 있습니다. 그의 이유 중 하나는 개발이 느려진다는 것입니다.

나는 이에 동의하지 않습니다. Developement 은 기능에 익숙하지 않은 경우에는 더 느리며이지만 일단 지식 수준에 도달하면 중요한 요소는 아닙니다.

백업 및 콘텐츠 이동 방법을 청취하십시오. 이렇게하면 개발 중에 작성한 콘텐츠 유형 및 필드와 웹의 모든 엉망진창이 항상 프로덕션 사이트로 이동하게됩니다.

모든 것이 일관된 좋은 깨끗한 사이트를 만드는 대신, 오래된 버그를 해결하기 위해 버그와 사이트의 일부 영역이 다르게 작동하게됩니다.

0

사이트 모음의 콘텐츠 형식과 필드를 업데이트하는 사용자 지정 솔루션을 개발했습니다. 코드 밑에서 SharePoint를 사용하면 필드 및 사이트/목록 콘텐츠 형식의 값뿐만 아니라 필드도 수정할 수 있습니다.

실제 콘텐츠를 QA에서 Prod로 이동하는 경우 에코를 사용합니다.

+0

질문은 MOSS 2007 사이트를 Dev에서 Production으로 이동하고 사용자 지정이 Dev에서 Production으로 이동하지 않는 것에 관한 것입니다. 웃긴만큼 최대 점수를 얻은 사람은 다른 대답을 한 사람이고 여기에 참여한 사람은 -1 점입니다. 감사합니다 ... – Ganesha

관련 문제