Source Control with Domino Designer 8.5.3 and Git (my talk at DanNotes, November 2012)
November 29th, 2012The 48th DanNotes conference took place yesterday and today.
I had 2 sessions. My first session was on the subject of XPages for administrators. My second session was on the topic of source control with Domino Designer 8.5.3 and Git. Here is my presention from that session:
Source Control with Domino Designer 8.5.3 and Git (DanNotes, November 28, 2012) from Per Henrik Lausten
Tags: DanNotes, Lotus Domino, Lotus Domino Designer, Presentation, XPages
I am an independent web developer at 
November 29th, 2012 at 23:00
[...] on Lotus Notes, Lotus Domino, XPages and more « DanNotes 48th conference in November Source Control with Domino Designer 8.5.3 and Git (my talk at DanNotes, November 2012) [...]
September 19th, 2013 at 12:43
What is the reason for having to use a copy of the database and not a replica. Let's say we have a few templates on the development server. What I had in mind was that each developer should have his own set local replicas (no auto-replication) on his PC of all the templates on the dev. server. These local template replicas would then be synchronized with on-disk-projects, which would be under source control with Git. Each developer would then push to / pull from a central Git repo. Before replicating changes in a local replica to the dev. server, the developer would pull the latest changes from the central Git repo, and then push his own changes. Finally, he would replicate to the dev. server. Do you see a problem with this approach? Why should we be using local copies instead of replicas?
September 19th, 2013 at 12:55
Hi Øystein, the developers need to work in local copies for at least these reasons:
- huge risk of overwriting others work when replicating your changes back to the server
- sessionAsSigner issues: if you use sessionAsSigner then the database must be signed by one id only in order for this to work. If not, then your code fails.
- Git branching: you can not handle branching if you work on the same replica. If one or more developers branch (which they should do to handle new requirements, bug fixes, etc.) then the code changes/diverts from the master branch - and on the same replica this would create version control issues. Furthermore, you would not be able to test the different branches on the server.
In general, it's very bad not to work on copies when using source control.
September 19th, 2013 at 13:33
Øystein,
Just about the whole point of Source Control is that your source control system handles all the code throughout the applications development lifecycle. If you were to use database replicas instead of database copies then source code could get to another database via notes replication and not through the Source Control tools. This will ruin you day, week and month if that happens.
It's easy for use to want to replicate because we know how simple it is and that replication "just works". But in a source control system, the Source Control does the "replication" for us. This is the way it should be.
Dave
September 24th, 2013 at 09:10
Thank you very much for your replies!
Per, I am not sure you understood me completely, or (perhaps more likely) I did not understand you. We do not intend to work on the same replica. Each developer would have his own local replica on his dev. PC, and replication would be manual and one-way only, from PC to dev. server. We have two sets of test databases on the dev. server as well, so we can refresh the design of those at any time (with design from templates on dev. PC) in order to continuously test during development.
But I guess we can use local copies of the templates instead of local replicas, and then use "replace design" rather than replication to upload code changes to the dev. server templates. Is this what you would recommend?
I picture the following work flow:
1. Each developer makes code changes on his local templates (on his dev. PC). He can commit and branch at will. Test databases on dev. server inherit design from the templates on dev. PC. Developer must refresh design of test databases in order to test the application.
2. When ready to push:
- Pull from central Git repo
- Push to central Git repo
- If on master branch: Replace design of templates on dev. server with that of the dev. PC templates.
Following this procedure, the master branch of the central Git repo will always be in sync with the dev. server templates, even though there is no direct connection between them, and the dev. server templates are always ready to be deployed (replicated to staging and/or production server). Make sense?
September 24th, 2013 at 09:56
Hi Øystein, yes - that makes sense.
I would also add to the workflow that each developer tests his own changes on a local dev server on his own machine. Once ready to be tested, he then follows the workflow that you have described.
September 24th, 2013 at 10:33
Thanks again for your reply. Unfortunately our customer will not allow us to install local Domino servers, so we are unable to test the application locally.
I feel the discussion of how to set up a streamlined development and deployment architecture (incorporating version control) for a large Lotus Notes project is a conceptually interesting one, so I posted a question on StackOverflow, and added my own answer with a proposed solution as well: http://stackoverflow.com/questions/18976503/how-to-incorporate-version-control-git-in-a-large-lotus-notes-project/18976504#18976504
Feel free to comment and/or add your own answers if you want.
September 24th, 2013 at 20:42
Interesting discussion. I've been looking for an explanation on how to really use source control in a Domino environment.
My concerns are mostly for the demand of having a local database in order for the source control to work and the refresh design step on a local dev server for every change you want to test. This is killing the RAD we are used to.
Is there a workaround or just accept it as a fact?
I know I will have a lot of concerned coworkers wondering why we have to do this in case I decide to deploy.
We are in great need of source control for our product. I see tremendous value because we have customers with special enhancements, we have release of new versions for al clients, we have demo databases and so on.
I would love to see an eval on the process, Öysten!
September 24th, 2013 at 21:05
Mikael, if the developer uses a local dev server - or has *his* own replica of *his* dev app on a server for *his* testing- then you can work on a replica. This eliminates the refresh design step during the dev process. The developer is then still working on his own copy of the database - but he is replicating his changes to his own local server or replicating his changes to his own copy on a shared server.