This weekend has been quite busy for me. In addition to umpiring my first National Premier League netball match of the season, I decided to build two things. One was a new rabbit hutch and the other was a source control management system. I’ve never been that good at practical exercises. I’m very adept at finding new and interesting ways to go wrong. So both needed to be easy.
The rabbit hutch was easy. Front, back, roof, floor tray, all different. Two sides, with holes for dowels from the front panel to attach to. 12 screws attached to cardboard and clearly labelled. Instructions with four easy steps. Nice and easy, so my bunny has a new hutch for the winter.
Onto the source control management system. The key requirement for us as a team was an on premises solution, although I’ve used both GitHub and BitBucket for personal projects. My initial attempts last week were with GitLab which had a Bitnami image for install into a Linux VM. The install itself was pretty easy. Where I failed quite spectacularly in a number of ways was getting it working. Perhaps that is because of limited experience of Linux, but when I hit problems I struggled to find quick good answers.
So I turned to Atlassian’s Stash, which Rene Winkelmeyer pointed me towards. This appealed for a number of reasons. Atlassian provide BitBucket which I’ve used. Although more expensive than GitLab (which is free), because of the size of our team we’re unlikely to go over the 10 user limit for a one-off $10 cost for on premises install. It’s also by the same company who provide the Git and Mercurial client SourceTree, which is my preferred Git client. The same company also provide Jira (for an additional licence) and there are a whole host of add-ons available. There are evaluation licences as well, allowing us to check it out before we go ahead – though at $20 for both products, I’ve spent more on iOS apps I’ve only used a handful of times!
It provides a single end-to-end solution that integrates with on-disk projects from Domino Designer as well as OSGi plugins from Eclipse. It also installs onto Windows, which I am much more familiar with. And following my experience of installation and configuration, the documentation is excellent and allowed me to quickly overcome every (minor) issue I have encountered within five minutes.
There are a few pre-requisites, but the installation instructions clearly tell you how to test for them and where to get the installs: an up-to-date Java JDK and setting the relevant system environment variables and installing Git. For all the installs I found that ensuring there are no spaces in the relevant filepaths for installs is the safest approach, so I’ve installed outside the “Program Files” folder. The install and configuration can use an internal database and that’s what we’re using currently, although it’s apparently easy to switch to an external server at a later stage. The only bit that’s not totally explicit is what is required for the STASH_HOME setup. The instructions talk about not putting that in the Stash install folder, so I’ve presumed it just needs to be a separate folder somewhere. I also found that when you start Stash and it creates the relevant sub-folders, the lib folder was read only, which the (in-built) Tomcat server warns about. So I just changed it to full access and restarted the server. There are steps for setting up SSH, but it appears to install by default, if you don’t want to use http to connect to Stash (and Jira). The only disappointing bit of the install is that Domino is not a supported mail platform.
Installing Jira is just as easy. Connecting the two is again fully documented and easy to do. It can be done when installing Stash, if Jira is already installed. Or just go to Application Links in the Administration area of Stash and add a new Application Link to Jira. It’s very easy and also allows the User Directory from Jira to be used for Stash as well. That means you can set up users once and use across both. One gotcha is that, if they’re installed on the same server, you can get login and session conflicts – basically one application hijacks the cookies of the other. But again, a search on Google got me very quickly to the documented solution of changing the context path.
At the moment, the experience has been very painless and pleasant – even for one as practically challenged as me. I would recommend it for small teams who want a good Git client with a graphical user interface and want on-site source control management.
We’ve been playing with the JIRA/Stash eco-system of late also. It is a perfect fit for a small team. We’re running this system on a Linux VM and have experienced some difficulties, mainly with resources.
We started with a 2 processor, 2GB RAM VM. This VM kept crashing and would occasionally bring down the host also. We have since upped the resources to 4 processors (8 available on host) and 6GB RAM (16 available on host). This seems to have stabled out the entire system.
Since we required an http-proxy in order to reach this system, that setup required different context paths to begin with so we never hit that issue.
But thought you might like to be aware of managing the resources if you’re running in a VM. If not I still suppose you’ll want a decent box to run it on as the experience is much better when the system isn’t already strained just from running these products.
Thanks, we are using a VM so your advice about performance is useful.