将 MOSS '07 站点从开发提升到生产
所以，也许我有点守旧，但是当我们过去创建网站时，我们会在开发服务器上开发网站，然后将页面和文件发布或推广到生产服务器。 这似乎一直是一种好方法，这样用户就不会看到混乱的页面或（上帝保佑）服务器宕机，因为我们中的一个人搞砸了。
但微软在创建 SharePoint 时似乎并没有考虑到这个想法……至少，我还没有找到一种方法在定义的基础设施中做到这一点。
有谁知道SharePoint开发是否有管理策略？ 我在网上看到我们可以对开发环境进行备份并恢复到生产服务器。 这可能第一次会起作用，但是对生产服务器的任何更新都无法做到这一点，否则就会面临生产服务器上数据丢失的风险。 我见过一些用于将列表内容、页面和文档从一台服务器迁移到另一台服务器的工具——尽管不可否认，我还没有研究过它们。
但是，我的另一个担忧是自定义内容类型。 似乎一旦列表使用了内容类型，您就无法更新它，除非从列表中删除项目、取消关联内容类型并重新关联内容类型。 难道不应该有某种方法来升级内容类型吗？
无论如何，如果您对当前的困境有任何建议，我很想听听您的意见。
提前致谢，
丹，
感谢您的快速回复。
，以及与品牌相关的功能（页面布局、母版页等）的另一个解决方案。
我们已经为我们的网站创建了几个功能，以及一个针对基础知识（内容类型、栏目等）的捆绑功能的解决方案包 看起来这是一次性的...基本上，它可以设置我们的服务器，对吧？ 一旦人们开始使用生产环境，我们的内容数据库中就会存在所有文档、页面、列表项，并且无法更新内容类型、列等内容。
您必须先停用并卸载功能，然后才能安装和激活新功能，对吗？ 我在功能定义中看到了 Version 属性，但据我所知，这没有任何作用。 解决方案似乎可以通过增加版本号来升级，但它似乎不会修改内容类型和列等内容——尤其是在使用它们的情况下。 另外，我不确定解决方案的升级范围有多大。
关于此类事情的文档很少。 似乎我正在阅读的所有内容都是如何最初设置 SharePoint 服务器......而不是长期管理它。
您有什么意见或建议吗？
谢谢大家的建议。
但我们在这个网站上的工作已经一年多了。 我非常有信心我们已经按照你们大多数人的建议进行了设置。 我们已经有一些功能可以安装内容类型、列、母版页、页面布局和工作流程等内容。 大多数这些功能都包含在解决方案包中。 我们将所有开发环境设置为 VPC 服务器。
所以，我已经基本完成了初始部署。 我真正希望了解的是如何升级内容类型和栏目等内容。 使用后是否可以更改内容类型？ 因为根据我的初步测试，这似乎是不可能的。 我不担心程序集，因为看起来它们交换得很好，但我更新内容类型的唯一方法是删除引用它们的任何项目（即我的页面库中的所有页面），删除内容类型，然后重新添加它。
你们中有人知道是否有办法在初始部署后更新内容类型吗？ ...当用户已经根据我们已经部署的内容类型创建项目时？
（我的问题的另一部分实际上是将现有页面从开发服务器移动到生产环境，但我可以没有它。我主要担心的是内容类型。）
So, maybe I'm a bit old-school, but when we created websites in the past, we'd develop the site on a development server, then publish or promote the pages and files to the production server. This has always seemed to be a good way to go so that users didn't see messed up pages or (God forbid) a downed server because one of us screwed up.
But it doesn't seem that Microsoft had this idea in mind when they created SharePoint...at least, I haven't been able to find a way to do this in the infrastructure as it's defined.
Does anyone know if there's a management strategy for SharePoint development? I've read online that we can make a backup of the development environment and restore to the production server. That might work the first time, but any updates to the production server can't do that without risking data loss on the production server. I've seen some tools out there for migrating list contents, pages and documents from one server to another--although, admittedly, I've not yet investigated them.
But, another concern of mine is custom content types. It seems that once a list is using a content type, you can't update it without deleting the items from the list, disassociating the content type, and reassociating the content type. Shouldn't there be some way to UPGRADE a content type?
Anyway, if you have any suggestions for any of these current dilemas, I would LOVE to hear from you.
Thanks in advance,
Dan
Thank you for your quick reply.
We already have several features created for our site and a solution package bundling features directed at the fundamentals (content types, columns, etc), and another solution for features having to do with branding (page layouts, master pages, etc.)
But it seems like this is a one-time-shot...basically, it gets our server set up, right? Once people have started using the production environment, we're going to have documents, pages, list items all existing in our content database, and it'll be impossible to update things like content types, columns.
Features you have to deactivate and uninstall before you can install and activate the new feature, right? I've seen a Version property on the feature definition, but as near as I can tell, this doesn't do anything. Solutions seem like they can be upgrade by incrementing the version number, but it doesn't seem to modify things like content types and columns--especially if they're in use. Plus, I'm not sure how extensive the upgrade with solutions is.
There's precious-little documentation out there for this sort of thing. It seems like everything I'm reading is how to get your SharePoint server set up initially...not managing it long term.
Do you have any advice or suggestions?
Thank you all for your suggestions.
But we've been working on this site for over a year now. I'm pretty confident that we're already setup according to what most of you are recommending. We already have several features that install things like content types, columns, master pages, page layouts, and workflows. Most of these features are contained within solution packages. We have all of our development environments set up as VPC servers.
So, I have the initial deployment pretty much set. What I'm REALLY hoping to find out is how I can upgrade things like content types and columns and stuff down the road. Is it possible to change content types once they're in use? Because it doesn't seem, based on my initial testing, that this is possible. I'm not to worried about the assemblies because it looks like they swap out just fine, but the only way I've gotten a content type updated is by deleting any items referencing them (i.e. all the pages in my pages library), removing the content type, then re-adding it.
Do any of you know if there's a way to update a content type AFTER the initial deployment? ...when users have already created items based on the content types we've already deployed?
(The other part of my question was actually moving existing pages from the development server to production, but I can live without that. My major worry is the content types.)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
最好的方法是使用功能进行开发。 完成这些功能后，您可以使用解决方案包（称为 WSP）来部署它们。
唯一剩下要做的就是重新激活这些功能。 这样，您就可以逐步推出新功能，而无需在生产中执行所有操作。
WSPBuilder 是一个帮助您构建 WSP 的应用程序。
为了使这一切自动化......祝你好运。 这涉及到很多工作。
更新：
部署内容类型和列很棘手。 网站创建后，您将无法再通过功能更新它们。 您需要遍历代码并递归地遍历所有站点并修改与名称匹配的特定内容类型。
我们已经尝试过了，但通常用功能来做到这一点是不可能的。 这需要经历我称之为“用代码部署”的过程。
The best way to go is developing with features. Once the features are done, you ca deploy them with Solution package (called WSP).
The only thing left to do is to reactivate those features. That way, you can progressively roll-out new features without having to do everything in production.
WSPBuilder is an application that helps you build WSP.
For automating all of this... good luck. There is a lot of work involved.
UPDATE:
Deploying Content Types and Columns are tricky. Once the website has been created, you can't update them anymore through features. You need to go through the code and recursively go through all the sites and modify the specific content type that match the name.
We've tried and it's not possible to do that normally with features. This need to go through something I call "deploying with code".
您确实需要使用功能来定义内容类型，因为这样每个内容类型都会有一个设置的 GUID，并且会使用相同的名称存储在数据库中。 当在网站上运行 CAML 查询时，这一点变得很重要，并且如果您愿意的话，当内容类型创建时还会出现一些其他小问题。
我更喜欢 STSDev 使用自定义内容类型推出解决方案。
在服务器上编辑页面有两种方法。 您可以将页面库定义为具有主要版本和次要版本。 这允许编辑者编辑页面并允许定义的发布者发布它们。 这在内部网站上很好，但不建议在面向公众的网站上使用。
对于面向公众的网站，您需要使用内容部署
我必须强调一点，在继续发布产品版本之前，请确保您拥有适合内容类型的功能。
正如此处提到的，Chris O'Brian 有一篇文章说，除非必要，否则不应使用功能。 他的原因之一是它会减慢开发速度。
我不同意这一点。 如果您不熟悉功能，开发速度就会变慢，但一旦达到一定的知识水平，这就不是主要因素了。
请听他讲述移动内容的备份和恢复方法。
如果您这样做，您在开发过程中可能创建的内容类型、字段和网络中的所有混乱（对我来说总是相当多）都将被转移到您的生产站点。
您不会拥有一个一切都一致的干净整洁的网站，最终会出现一些小错误，并且网站的某些区域的行为与其他区域不同，仅仅是因为旧的开发缺陷。
You really really need to define your content types using a feature because that way each content type will have a set GUID and will be stored in the database using the same name. This becomes important when running CAML queries over the site and there are a few other little gotchas when content types are created "will nilly" if you will.
I prefer STSDev for rolling out solutions using custom content types.
There are two ways to edit pages on the server. You can define the page library to have major and minor versions. This allows editors to edit the page and a defined publisher to publish them. This is good on an internal site, but is not recommended for a public facing site.
For a public facing site you will need to use Content Deployment
I cannot stress enough that before going ahead with a production release you make sure you have features for the content types.
As mentioned here, Chris O'Brian has a post saying that you should not use features unless necessary. One of his reasons is that it slows developement.
I disagree with this. Developement is slower if you are unfamiliar with features, but once a level of knowledge is reached, it is not a major factor.
Do listen to him about the backup and restore method of moving the content.
If you do that, all mess in the content types and fields and webs you may have created during developement (for me that is always quite a bit) will be moved to your production site.
Instead of having a nice clean site where everything is consistent, you will end up with little bugs and some areas of the site behaving differently to others simply because of old development cruft.
我建议您查看 Chris O'Briens 最近的帖子，以及他出色的内容部署向导：这不仅仅与功能有关！
I recommend taking a look at Chris O'Briens most recent post, and his great Content Deployment Wizard: it's not all about Features!
Maxim 是正确的，大多数项目应该通过解决方案（WSP 文件）中包含的功能来部署。 您的策略应该是确保您的解决方案和程序集被分解为相关的功能部分。 这也是有益的，因为可以在某些级别（例如站点和网络）隔离功能。 更新任何内容时应使用功能激活代码、停用代码和功能装订。 内容部署也很有意义。
需要记住的一点是，如果更新仅在代码中，则可以更新程序集，而不需要重新激活功能或撤回和重新部署解决方案。 所需要做的就是重置应用程序池。
Microsoft 有几篇关于开发环境的文章，您可以通过 Google 搜索许多其他推荐环境的文章。 我们在虚拟机上进行开发，并将大多数项目部署到虚拟集成服务器上。 一旦我们进行了冒烟测试，我们就会将我们的解决方案部署到质量检查等等。 好处是功能和解决方案很容易撤回。 一旦投入生产，就应该进行彻底的测试。
在 SharePoint 中进行开发有其问题，这是不言而喻的，但到目前为止我发现好处大于问题。
Microsoft Office SharePoint Server 2007 中的团队开发
Maxim is right in that most items should be deployed via features that are wrapped in solutions (WSP files). Your strategy should be to make sure your solutions and assemblies are broken into related bits of functionality. This is also beneficial in that features can be isolated at certain levels like sites and webs. Feature activation code, deactivation code and feature stapling should be used when updating any content updates. Content deployment can also make sense.
Once thing to remember is that if the updates are only in code then the assemblies can be updated without requiring the feature to be reactivated or the solution retracted and redeployed. All that is required is the Application Pool to be reset.
Microsoft has a couple articles on Dev environments and you can Google many others who recommend environments. We do development on virtual machines and deploy most items to an virtual integration server. Once we smoke test it we then deploy our solutions to QA so on and so forth. The benefit i sthat features and solutions are easy to retract. Once it goes out to production it should be thouroughly tested.
Developing in SharePoint has it's issues, that goes without saying, but so far I have found that the benefits outweight the problems.
Team-Based Development in Microsoft Office SharePoint Server 2007
我们开发了一个自定义解决方案，可以更新网站集的内容类型和字段。 在幕后，SharePoint 允许我们通过代码修改字段以及字段和网站/列表内容类型中的值。
为了将实际内容从 QA 转移到 Prod，我们使用 Echo
We developed a custom solution which would update content types and fields for a Site Collection. Underneath the covers, through code, SharePoint allows us to modify the Fields as well as values in the Fields and Site/List Content types.
For moving the actual content from QA to Prod we use Echo