Domino Upgrade

VersionSupport end
Upgrade to 9.x now!
(see the full Lotus lifcyle) To make your upgrade a success use the Upgrade Cheat Sheet.
Contemplating to replace Notes? You have to read this! (also available on Slideshare)


Other languages on request.


Useful Tools

Get Firefox
Use OpenDNS
The support for Windows XP has come to an end . Time to consider an alternative to move on.

About Me

I am the "IBM Collaboration & Productivity Advisor" for IBM Asia Pacific. I'm based in Singapore.
Reach out to me via:
Follow notessensei on Twitter
Amazon Store
Amazon Kindle
NotesSensei's Spreadshirt shop
profile for stwissel on Stack Exchange, a network of free, community-driven Q&A sites

« Serving Single Page Applications with Domino | Main| SAML and the Command Line »

GIT deploy your static sites - Part 1

When you, in principal, like the idea to serve SPA from the http server, you will encounter the pressing question: where do babies come from how to get your application deployed onto the http server? This applies to nodeJS applications too, but that is part of another story for another time.
On Bluemix that's easy: just use a Pipeline.
For mere mortal environments there are several options:
  • Just FTP them - insecure unless you use sftp/scp. Big pain here: deleting obsolete files
  • Setup rsync. When done with a ssh certificate can be reasonably automated. Same pain applies: deleting obsolete files
  • Use a GIT based deployment. This is what I will discuss further
I like a repository based deployment since it fits nicely into a development based workflow. The various git gui tools provide insight what has changed between releases and if things go wrong, you can roll back to a previous version or you can wipe data and reestablish them from the repository. Designing the flow, I considered the following constraints:
  • The repositories would sit on the web server
  • Typically a repository would sit in .git inside the site directory. While you could protect that with access control, I decided I don't want to have it in separate directories
  • When pushing to the master branch, the site should get updated, not on any other branch. You can extend my approach to push other branches to other sites - so you get a test/demo/staging capability
  • Setting up a new site should be fast and reliable (including https - but that's part 2)
The "secret" ingredients here are git-hooks, in specific the post-receive. Hooks, in a nutshell are shell scripts that are triggered by events that happen to a git environment. I got inspired by this entry but wanted to automate the setup.
So I devised the following shell script:
# Script to establish a git driven static site 

# Check if we have a parameter. We expect the base URL only
if [ -z ${SITENAME+x} ]; then
  echo "You need to provide a site name:";
 echo "Site to be created '$SITENAME' with alias 'www.$SITENAME'";

# Create the web root directory and .wellknown for letsencrypt
mkdir -p $WEBROOT/$SITENAME/.wellknown
echo "

Site root for $SITENAME

" > $WEBROOT/$SITENAME/index.html # Create the repository and add the index file git init --bare $GITROOT/$SITENAME git -C $WEBROOT/$SITENAME --git-dir=$GITROOT/$SITENAME --work-tree=$WEBROOT/$SITENAME add --all git -C $WEBROOT/$SITENAME --git-dir=$GITROOT/$SITENAME --work-tree=$WEBROOT/$SITENAME commit -m "automatic creation of ${SITENAME}" # Create the commit hook HOOKNAME=$GITROOT/$SITENAME/hooks/post-receive echo "#!/bin/bash" > $HOOKNAME echo "if [ \`git rev-parse --abbrev-ref HEAD\` == 'master' ]; then" >> $HOOKNAME echo " git --work-tree=$WEBROOT/$SITENAME clean -fd" >> $HOOKNAME echo " git --work-tree=$WEBROOT/$SITENAME checkout --force" >> $HOOKNAME echo "fi" >> $HOOKNAME chmod +x $HOOKNAME echo Done creation of $SITENAME

You need to adjust the path variables to your environment. Next stop:Create the nginx site with SSL.
As usual: YMMV


This site is in no way affiliated, endorsed, sanctioned, supported, nor enlightened by Lotus Software nor IBM Corporation. I may be an employee, but the opinions, theories, facts, etc. presented here are my own and are in now way given in any official capacity. In short, these are my words and this is my site, not IBM's - and don't even begin to think otherwise. (Disclaimer shamelessly plugged from Rocky Oliver)
© 2003 - 2017 Stephan H. Wissel - some rights reserved as listed here: Creative Commons License
Unless otherwise labeled by its originating author, the content found on this site is made available under the terms of an Attribution/NonCommercial/ShareAlike Creative Commons License, with the exception that no rights are granted -- since they are not mine to grant -- in any logo, graphic design, trademarks or trade names of any type. Code samples and code downloads on this site are, unless otherwise labeled, made available under an Apache 2.0 license. Other license models are available on written request and written confirmation.