Thursday 16 January 2014

Some thoughts on Source Control Management for XPages development

In my career as a Domino developer I have been playing with various Source Control Managent solutions already. I used TeamStudio Ciao! for many many years and this tool proved to be a life saver in many occasions already. So I owe some drinks to the guys from TeamStudio... (don't tell them!!)

Since IBM started opening Domino Designer in Release 8.5.3 (was it 8.5.2 ???) towards the "standard" SCM systems (Git, SVN, Mercurial) I have been playing with these options a lot. There was quite some pain involved, I lost source code, my repositories lost the link to the NSF/ODP, etc... No pain, no gain! The good news for me: Today I have a working environment which fits my needs :-)
My first steps were with SVN, but I admit that I was not able to get this setup running properly. Additionally, I was not too happy about the centralized approach. That said I started using Mercurial. Finally I ended up using Git, first the implementation in Domino Designer and nowadays using SourceTree. This setup provides me with such a high flexibility with regards to my work-related projects as well with my pet-projects.

The last missing bit so far was a proper SCM system. I have been looking around for a while and playing with various systems. As I am a corporate developer, using a hosted environment was not an option at all. So I was looking for a solution to run my self-hosted SCM server for my code coming from both, work-related projects as well as pet-projects. Finally, I think my journey has ended successfully (or at least I have reached an intermediate stop). I have played with GitLabHQ for a a while now and it looks very promising to me. I got it up and running relatively painless on a local Ubuntu VM. If you are looking for a self-hosted SCM server, I can highly recommend looking into GitLab (it is very focussed on SCM though).
There is a lot of useful information available in- and outside the XPages community. In the upcoming weeks I will describe my environment and approaches and specifically GitLab a little more in detail and hopefully add some more useful bits. So stay tuned!

2 comments:

  1. Michael, allow me to share with you a valuable lesson that it took me a long time to learn. It's a very surprising fact about git servers. It took me about 6 months of banging my head against the wall trying to set up an internal git system for about 25 developers before I realized this, and it would have saved me a lot of trouble had I understood it from the start.

    You ready?

    Here we go...

    A "shared git repository" is just a folder.

    Let that sink in.

    You don't need to stand up a specialized git repository server to support a central origin for your repositories. All you need is a file server. Odds are good that you already have one. If you don't, any WebDAV server you can find that supports remote folder creation will do the trick.

    If you have a background in SVN, you tend to think that you need some sort of specifically engineered server to act as your git server. But you don't. Git is a peer-to-peer protocol, so even when you use SourceTree to sync with a repository at Github, it's SourceTree doing all the work. It pulls file contents from Github over normal https GET requests, resolves the signatures and deltas, and then POSTs the resulting updates back to Github. The web service itself is, at it's heart, just a basic file content server. All the extra bells and whistles that you get from Github are just a website that understands the git folder structure and so can do things like draw history graphs for you. (So does SourceTree, so you really don't need this on a server.)

    You can save yourself a lot of trouble if you just have a basic file server in place. In fact, you could probably use the Quickr or Connections connectors for Windows if you put a little research into it.

    Good luck! And drop me a line: ntf@redpilldevelopment.com if you have further questions.

    ReplyDelete
  2. I agree with Nathan, however if you're determined on having a git "server" per-se, take a look at Atlassian's Stash. It's $10 a year for 10 developers or less and it has a nice web UI to look at your code remotely via a browser. https://www.atlassian.com/software/stash/overview

    ReplyDelete

Comment Form Message