是否可以使用持续集成技术来开发共享点?
我们正在准备一些相当严肃的 Sharepoint(MOSS 2007)开发,包括自定义 Web 部件、列表、母版页和布局等等。
我们正在评估版本控制,似乎讨论还没有比这更深入。 我热衷于我们可以轻松地从源代码控制部署到我们的测试和生产服务器,尽可能少的人为接触,最好是在每次签入后完全自动进行。
我以前没有使用过 CI,所以感觉有点无知Sharepoint 的可能性,以及过于复杂而不合理的地方。
我担心,如果我们走上一条过于“简单”的道路,那么当我们在发布一些新功能后不得不花半天时间设置每个环境时,我们很快就会后悔。
我什至还没有开始在脑海中解决当用户添加的列表中存在实际内容时会发生什么以及这将如何影响我们在开发方面所做的工作。
欢迎链接到博客/文档。 非常欢迎个人经历。
We are gearing up for some pretty serious Sharepoint(MOSS 2007) development including custom web parts, lists, master pages and layouts etc etc and etc.
We are evaluating version control and it seems that the discussion has not got much deeper than that. I am keen that we can easily deploy from the source control to our test and production servers with as little human contact as possible, and preferably entirely automatically after every check in.
I have not worked using CI before and so am feeling a bit ignorant as to what is possible with Sharepoint, and what is too complex to be sensible.
I fear if we head off down a too 'easy' path then we will come to regret it pretty swiftly when we have to spend half a day setting up each environment after we release some new functionality.
I have not even started to address in my head what happens when there is actual content in the lists added by users and how that will affect what we do on the development side.
Links to blogs/documentation are welcomed. Personal experiences VERY welcome.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
我最接近的经验是在一个使用 STSDEV 构建发布解决方案的项目中。 自定义构建操作使我们能够从目标服务器中删除共享点解决方案,安装新的解决方案并重置所需的应用程序池。
建造花了一段时间,但效果很好。
我们没有发布测试使用此过程,但它可能是可能的。
这是目标文件的示例。 不幸的是,它有点复杂。
The closest I have experience is on a project that used STSDEV to build solutions for release. Custom build actions allowed us to remove the sharepoint solution from the target server, install the new solutions and reset the required application pools.
Took a while to build, but it worked well.
We did not release to test using this process, but it may be possible.
Here is an example of a targets file. Unfortunately, it is a bit complex.
看看 Powershell……不幸的是,这是对 SharePoint 的主要抱怨之一,因为缺乏良好的开发和部署流程。 所有内容都应该打包到解决方案中并通过 powershell 进行部署,powershell 还可以管理任何信息的清理。 要版本化,只需将解决方案部署为升级,并使用 Powershell 在您的应用程序中适当更新(如果您更新版本号)。 这是很多额外的工作,但效果很好。 在最近的一次升级中,我必须对两个 Web 部件进行版本控制,然后使用 powershell 循环遍历我的所有约 1,500 个网站,删除旧的 Web 部件并添加回新的 Web 部件。
当您开始工作时,您应该开始开发一个强大的 Powershell 库来执行强大的更新任务。
Look at Powershell ... unfortunately this is one of the major gripes with SharePoint is a lack of a good development and deployment process. Everything should be packaged into solutions and deployed via powershell, powershell can also manage any clean up of information. To version simply deploy the solutions as an upgrade and use Powershell to update in your apps as appropriate (if you update your version number). It is a lot of extra work but works well enough. In a recent upgrade I had to version two web parts and then used powershell to loop through all ~1,500 my sites removing the old web parts and adding back in the new ones.
As you go you should start to develop a strong Powershell library to perform powerful updating tasks.
唯一需要通过某种持续集成来使用 SharePoint 的是当您使用功能和解决方案包 (wsp) 时。
您只需要以某种方式将您的 wsp 与所有必要的文件/DLL 和配置打包,然后部署它。 部署后,您可以创建批处理脚本来自动重新激活所有功能。
请注意,所有已自定义(非托管)的文件都不会更新。 您必须确保重置站点定义(代码为“SPFile.RevertContentStream”)。
祝你好运!
The only was to work with SharePoint with some kind of continous integration is when you are working with features and solution packages (wsp).
You just have to somehow get to package your wsp with all the necessary files/DLLs and configuration and then deploy it. Once it's deployed, you can create a batch script to automatically reactivate all features.
Please be aware that all file that has been customized (unghosted) will NOT be updated. You must make sure to make a reset to site definition (by code it's "SPFile.RevertContentStream").
Good luck!