如何在大型Lotus Notes项目中集成版本控制(Git) [英] How to incorporate version control (Git) in a large Lotus Notes project

查看:235
本文介绍了如何在大型Lotus Notes项目中集成版本控制(Git)的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们正在维护基于Domino服务器8.5.3上运行的Lotus Notes的大型网站。最近我们已经厌倦了我们项目中缺乏源代码管理,所以我们以为我们会尝试Git的东西一点点。但是如何做到这一点?

We are maintaining a large website based on Lotus Notes, running on Domino Server 8.5.3. Recently we have been fed up with the lack of source control in our project, so we thought we would try to Git things up a little. But how to do this right?

由于种种原因,我不会进入这里,我们无法在开发PC上本地运行我们的应用程序。我们只能在开发,分段和生产服务器上运行它们。 (不幸的是,在开发PC上运行的本地Domino服务器不是一个选项。)

For various reasons that I will not get into here, we cannot run our applications locally on the development PCs. We can only run them on the development, staging and production servers. (Local Domino server running on the development PCs is not an option, unfortunately.)

此图说明了当前的情况:

This figure illustrates the current situation:

在生产(和分期)中,有多个网站都具有相同的功能。它们基本上是相同的设计,但内容不一样。每个站点由许多Notes数据库(新闻,存档,讨论等)组成。这些数据库的设计对于所有站点都是一样的,所以他们都从同一组主模板(NewsTemplate,ArchiveTemplate,DiscussionTemplate等)继承他们的设计。

In production (and staging) there are multiple web sites that all have the same functionality. They are basically the same site with the same design, but with different content. Each site consists of a number of Notes databases (News, Archive, Discussion etc). The design of these databases is the same for all sites, so they all inherit their design from the same set of master templates (NewsTemplate, ArchiveTemplate, DiscussionTemplate etc).

A主模板的副本集位于开发服务器上。当我们部署新功能时,所需的代码更改将添加到Dev上的模板中。服务器(以下详细信息)。然后将这些模板复制到Staging服务器进行测试,最后复制到生产服务器。这部分工作得很好。

A set of replicas of the master templates resides on the Development server. When we deploy new functionality, the required code changes are added to the templates on the Dev. server (more details on this below). Then these templates are replicated to the Staging server for testing, and finally to the production server. This part works quite well.

问题可能在图的下半部分找到。我们目前是两个开发人员,我们都在同一组开发工作。数据库(新闻,存档,讨论等)在开发。服务器。自然地,我们不断绊倒彼此的工作,这是非常令人沮丧的。当它是时候部署时,要部署的代码被选择性地从该组开始复制/粘贴。数据库到dev。模板。这是手动完成的,因此错误的风险很高。我们不能简单地用模板替换模板的设计。数据库,因为dev。数据库始终包含正在开发的代码。所以我们必须非常小心只部署完成的代码。此外,我们没有变化的历史。这是一个可怕的,可怕的,可怕的(添加尽可能多的可怕的你认为合适的)软件开发的方式,我们知道。

The problems may be found in the lower part of the figure. We are currently two developers, and we both work in the same set of dev. databases (News, Archive, Discussion etc) on the dev. server. Naturally we keep tripping over each others' work, which is quite frustrating. When it is time to deploy, the code that is to be deployed is selectively copied/pasted from the set of dev. databases to the dev. templates. This is done manually, and thus the risk of mistakes is high. We cannot simply replace the design of the templates with that of the dev. databases, because the dev. databases at all times contain code that is under development. So we must take great care to only deploy code that is "finished". Also, we have no history of changes. This is a horrible, horrible, horrible (add as many horribles as you see fit) way to do software development, and we know it.

现在,使用Git,本地复制品,数据库副本或什么,什么是实现更加简化的开发和部署方案的最佳方式?

Now, using Git, local replicas, database copies or whatnot, what would be the best way to achieve a more streamlined development and deployment scheme?

推荐答案

说明了一个可能的解决方案:

This figure illustrates a possible solution to the problem:

正如 here ,每个开发人员应该有自己的COPY(不是复制品)的数据库/模板(或在我们的案例中设置的模板)来开发。 PC有一组模板,每个模板与磁盘项目同步。一组磁盘项目将由Git源代码控制。

As explained here, each developer should have his own COPY (not replica) of the database/template (or in our case set of templates) to develop in. So on each dev. PC there is a set of templates, and each template is synchronized with an on-disk-project. The set of on-disk projects will be under source control with Git.

开发人员将无法在本地运行应用程序,因此他需要一组测试数据库在开发服务器。每个开发人员将有一个这样的集合。测试数据库将从开发人员的模板继承他们的设计。 PC。因此,为了测试他的代码更改,开发人员必须使用他的模板(驻留在他的PC上)刷新他指定的一组测试数据库的设计。

The developer will not be able to run the application locally, so he needs a set of test databases on the dev. server. There will be one such set for each developer. The test databases will inherit their design from the templates on the dev. PC. Thus, in order to test his code changes, the developer must refresh the design of his designated set of test databases with that of his templates (which reside on his PC).

每个开发人员的工作流程如下:

The workflow for each developer will be as follows:


  1. 在开发人员自己的PC上的模板集中进行代码更改。通过刷新设计上的测试数据库的设计来不断测试。服务器。开发人员准备推送到远程Git回购:
  1. Make code changes in the set of templates on developer's own PC. Test continuously by refreshing the design of the test databases on the dev. server. Sync with on-disk-projects, commit and branch "at will".
  2. When developer is ready to push to remote Git repo:

a)从远程Git repo拉取更改。

a) Pull changes from remote Git repo.

c)将更改推送到远程Git备份。同步数据库与磁盘项目。

c) Push changes to remote Git repo. Sync databases with on-disk-projects.

d)如果当前在开发分支:替换设计的模板集的设计。服务器与dev上的一组模板设计。 PC。这将确保远程Git repo的开发分支始终与dev上的模板一致。服务器,即使它们之间没有直接的连接。

d) If currently on develop branch: Replace design of the set of templates on the dev. server with the design from the set of templates on the dev. PC. This will ensure that the develop branch of the remote Git repo is always consistent with the templates on the dev. server, even though there is no direct connection between them.

从这里可以通过从开发人员复制模板将更改部署到分段和生产。服务器。在部署到生产之前,应该将开发分支合并到 master 分支中,以便 master 始终反映当前的生产版本。 >

From here changes can be deployed to staging and production by replicating the templates from the dev. server. Before deploying to production, the develop branch should be merged into the master branch, so that master always reflects the current production version.

如果有任何人有任何意见,补充或异议,我很乐意听到他们的意见。

If anyone has any comments, additions or objections, I would love to hear them.

编辑:
要缩短上述第1点的反馈循环,可以直接在开发人员的测试数据库中完成开发。服务器。这样就无需在每次需要测试更改时刷新测试数据库的设计,尽管您必须小心将所有更改复制回设备。模板定期保持代码的安全,并保持Git的更新。通过执行数据库和模板的元素元素比较,可以快速完成此操作。这也是在提交之前检查您的更改的机会,这是一个非常好的习惯。

To shorten the feedback loop in point 1 above, development can be done directly in the testing databases on the dev. server. This removes the need to refresh the design of the testing databases every time you need to test your changes, though you must be careful to copy all changes back to the dev. templates at regular intervals to keep your code safe and keep the Git repo updated. This can be done pretty quickly by doing an element-by-element compare of the database and the template. This also serves as an opportunity to review your changes before making a commit, which is a very good habit.

将更改复制到模板的另一个选项是使测试数据库上的dev。服务器一个主模板,并临时设置模板上的模板。 PC从该主模板继承设计。然后可以通过开发人员的刷新设计复制更改。 PC的模板,之后您可以再次删除继承。

Another option for copying the changes back to the template is to make the testing database on the dev. server a master template and temporarily set the template on the dev. PC to inherit the design from that master template. Then the changes can be copied with "Refresh design" on the dev. PC's template, after which you can remove the inheritance again.

这篇关于如何在大型Lotus Notes项目中集成版本控制(Git)的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆