如何将 Liferay 门户置于版本控制之下?
将 Liferay 门户置于版本控制之下的好方法是什么?我的意思并不是对我们编写的 portlet 进行版本控制,而是对正在运行的站点的实际布局和配置进行版本控制。
设置新站点时,布局和配置的所有更改都是通过管理控制面板进行的。我希望通过版本控制实现的目标是:
- 使站点能够恢复到之前的任何状态。
- 使开发人员之间的同步变得容易,以便在启动开发实例时,它反映生产中的状态(或特定修订版的任何其他实例)。
当然,内容的状态或多或少是动态的(同步数据库状态将是一个不同的问题),这里的重点更多是布局、主题、页面和 liferay 固有的其他内容,如用户组等。
What's a good way to put a Liferay portal under version control? By this, I don't mean versioning the portlets we wrote, but the actual layout and configuration of a running site.
When setting a new site up all changes to layout and configuration are made through the admin Control Panel. What I'm looking to achieve with version control are:
- Make it possible to revert the site to any of its previous states.
- Make it easy to synchronize between developers so that when a dev instance is launched, it reflects the state of what's in production (or any other instance at a particular revision).
Of course the state of content would be more or less dynamic (syncing database states would be a different issue), the focus here is more of the layouts, themes, pages and other things inherent in liferay like user groups, etc.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
在 Liferay 的下一个版本中,我们在“Staging”中包含了一项名为“分支和版本控制”的新功能,可为您的站点提供 VCS 支持。
每个站点将能够拥有无限数量的“分支”(其中包含值得更改的整个树),而在给定分支内,每个页面可以具有任意数量的“修订”,这些“修订”可以随时标记为“标题”修订。
那么,这对您的问题意味着什么:
是的,只要您将每个变更集保留为分支,您就可以做到这一点。
即从使用分支 A 的站点开始,您可以发布分支 B,然后重新发布分支 A,然后发布分支 C,然后再次重新发布分支 A,依此类推。
我不确定我是否正确回答了这个问题,但如果我的理解是并发开发,那么是的。如果除此之外,您想查看网站在某个分支的某些修订版中的样子,那么是的,您也可以这样做。除此之外,更改和暂存包含在一个给定的门户实例中,该实例实际上是“暂存”环境。该环境可以与产品完全集成(实际上同一门户实例/数据库中的所有内容),也可以远离产品(不同的服务器、不同的实例、不同的数据库,其中“暂存”内容的所有发布均源自暂存并发布成为远程操作,无缝集成,在这里您需要 LDAP 与 Staging 上的内容开发人员同步。
In the next release of Liferay, we've included a new feature within "Staging" called "Branching & Versioning" that provides VCS support for your site(s).
Each site will be able to have unlimited number of "Branches" (which comprises an entire tree worth of changes) while within a given Branch each page can have any number of "Revisions" that can be at any time marked as the "Head" revision.
So, what this means in terms of your questions:
Yes you will be able to do this provided you keep each changeset as a Branch.
i.e. starting with the site using Branch A, you can publish Branch B, and later republish Branch A, later Publish Branch C, and again later republish Branch A, and so on.
I'm not sure if I'm answering this one correctly, but if my understanding is to have concurrent development then yes. If beyond that you want to see what the site looks like at some revision in some branch, then yes, you can do that as well. Beyond that the changes and Staging is contained within one given portal instance which in effect is the "Staging" environment. This environment can either be completely integrated with prod (effectively everything in the same portal instance/database) or it can be remote from prod (different server, different instance, different database, where all publishing of "staged" content originates within Staging and publishes become remote operations, seamlessly integrated. Here you'll need LDAP sync with prod for the content developers on Staging).