DevOps with XPages on Premesis or PaaS like Bluemix

Question

What is the best way to achieve DevOps with XPages.

Multiple Developers working as a team, On Premises Servers [Dev, QA, Prod] can we replicate to Bluemix? Source Control Automated Testing UI / Application, Unit testing business logic with testing framework, Automated Deployment

IDE/Tools Domino Designer; are there other ways?

Note: Use of Views when the data is in a NSF, otherwise data is in the cloud, or SQL. No Forms or other classic Notes design elements.

What are your approaches to this?

Answer 1

This is a high level overview of the topics required to attempt what you're describing. I'm breezing past lots of details, so please search them out; I've tried to reference what I'm currently aware of as far as supporting documentation and blog posts, etc. of others. If anyone has anything good to add, I'm happy to add it in.

There are several components involved with what you're describing, generally amounting to:

1. scm workflow
2. building the app (NSF)
3. deploying the built app to a Domino server

Everything else, such as release workflow through a QA/QC environment, is secondary to the primary steps above. I'll outline what I'm currently doing with, attempting to highlight where I'm working on improving the process.

1. SCM Workflow

This can be incredibly opinionated and will depend a lot on how your team does/wants to use source control with your deployment / release process. Below I'll touch on performing tests, conceptually, during/around the build step.

I've switched from a fairly generic scm server implementation to a GitLab instance. Even running a CE instance is pretty fantastic with their CI runner capabilities. Previously, I had a Jenkins CI instance performing about the same tasks, but had to bake more "workflow" into the Jenkins task, whereas now most of that logic is in a unified script, referenced from a config file (.gitlab-ci.yml). This is similar to how a Travis CI or other similar CI config file works.

This config calls some additional helper work, but ultimately revolves around an adapted version of Egor Margineanu's PowerShell script which invokes the headless DDE build task.

2. Building an NSF from Source

I've blogged about my general build process, with my previous Jenkins CI implementation. I followed the blogging of Cameron Gregor and Martin Pradny for this. Ultimately, you need to:

1. configure a Windows environment with Domino Designer
2. set up Domino Designer to import from ODP (disable export), ensuring Build Automatically is enabled
3. the notes.ini will need a flag of DESIGNER_AUTO_ENABLED=true
4. the Jenkins CI or GitLab CI runner (or other) will need to run as the logged in user, not a Windows service; this allows it to invoke the "headless dde" command correctly, since it runs in the background as opposed to a true headless invocation
5. ensure that Domino Designer can start without prompting for a user's password

My blog post covers additional topics such as flagging the build as success or failure, by scanning the output logs for being marked as a failed build. It also touches on how to submit the code to a SonarQube instance.

Ref: IBM Notes/Domino App Dev Wiki page on headless designer

Testing

Any additional testing or other workflow considerations (e.g.- QA/QC approval) should go around the build phase, depending on how you set up your SCM workflow. A lot of the implementation will revolve around the specifics of your setup. A general idea is to allow/prevent deployment based on the outcome of the build + test phase.

Bluemix Concerns

IBM Bluemix, the only PaaS that runs IBM XPages applications, will require some additional consideration, such as:

• their Git deploy process will only accept a pre-built NSF
• the NSF must be signed by the account owner's Bluemix ID

Ref: - IBM XPages on Bluemix - Bluemix Docs: Building XPages apps for the Bluemix Runtime

3. Deploy

To Bluemix

If you're looking to deploy an XPages app to run on Bluemix, you would want to either ensure your headless build runs with the Bluemix ID, or is at least signed with it, and then deploy it for a production push either via a git connection or the cf/bluemix command line utility. Bluemix's receive hooks handle all the rest of the deployment concerns, such as starting/stopping the server instance, etc.

To On-Premise Server

A user ID with appropriate level credentials needs to perform the work of either performing a design replace/refresh or stopping a dev/test/staging server, performing the file copy of the .nsf, then starting it back up. I've heard rumors of Cameron Gregor making use of a plugin to Domino Designer to perform the operations needed for OSGi plugin development, which sounds pretty useful. As most of my Domino application development is almost purely NSF based, I'm focusing more on an approach of deploying to a staging/dev/test server, which I can then perform a design task on to do the needed refresh/replace; closer to the "normal" Domino way of doing things.

Summary

Again, there are a lot of moving pieces involved here, some of which gets rather opinionated rather quickly. For example, I'm currently virtualizing my build machine, so I can spool up a couple virtual machines of it, allowing for more than one build at a time. If there are major gaps in the process, let me know and I'll fill it what I can.