Recently I have been setting up some infrastructure for a small distributed software development team. Some of the things that struck me as necessary, nice to have, or makes-sense requirements include:
- Centralised authentication — log into every application with one username and password rather than having a different password for each application.
- Everything in the cloud — so that people can work from office, home, or wherever they happen to be around the world (as long as they can get online).
- git based source code control.
- Ticketing system.
- Real time chat.
- Open Source and/or Free Software.
Obviously there are a number of solutions to all of the above and I spent some time picking out what I thought were the best for my team’s requirements.
389 Directory Server
This works for centralised authentication. I previously wrote an article on setting that up here and it works pretty well. I also added a self service password manager and a web based administration program (which I have since replaced with Apache Directory Studio) to allow me to easily create new users.
Of course I could have used Active Directory but that costs money and requires a Windows server. OpenLDAP is another option but I currently think that 389 Directory Server has better features for the money (which is of course $0 as it is free software).
Gitlab
This was a bit of a bold choice. Github is the obvious choice for distributed teams using git, but I needed a lot of private repositories with quite a number of developers working on them in separate teams, and github can get quite expensive when there are both large numbers of developers, teams, and private repositories. So it made sense to deploy our own.
Gitlab has most of the basic features of github including the usual git features such as branching & merging, as well as teams & team permissions, code reviews, etc. Also deploying our own private gitlab server means we can tie authentication into LDAP.
Having now used both gitlab, github and bitbucket extensively, I have to say that I prefer the UI/UX of gitlab over the others. Where you have multiple teams working on multiple repositories across multiple projects, the groups/projects model of gitlab makes more sense. Also I find that the process to create and merge pull requests in gitlab a lot more user friendly than the other two.
Redmine
Rather than going down the path of using JIRA (which also gets expensive for large teams, including the annual maintenance which is 50% of the purchase price), I settled on Redmine. I have to admit that the more I use JIRA on other projects, the more I like Redmine. As a ticketing system I find that Redmine’s interface is far superior to that of JIRA for programmers, even though JIRA has some project management features that project managers might prefer.
Redmine needs quite a few plugins to make it more usable on agile projects, and so I installed this list (in alphabetical order):
- Clipboard image paste — allows us to upload images via copy-and-paste from the clipboard, for non-technical users.
- Redmine Agile plugin (Light version) from redminecrm.com
- Redmine CKEditor plugin — for projects that want to use a WYSIWYG editor rather than the wiki style editing that comes by default with Redmine.
- Redmine per project formatting plugin — definitely necessary, because not every project wants to use WYSIWYG formatting.
- Redmine Rocket.chat — for rocket.chat integration. This allows us to have “feed” channels in rocket.chat for each project where ticket updates can be announced, rather than having to have everyone listen in via email.
- Redmine Tagging Plugin — although the project manager who asked for this plugin has never used it, except to repeatedly ask me to install it (even though it’s already installed).
- Redmine User-Specific Theme Plugin — allowed me to install a number of Redmine themes and allow users to select their own. Project managers have a weird idea that themes allow extra functionality (they don’t, they just change the look and feel such as colours and fonts) so they often ask for weird themes to give them better access to features (apparently some features can’t be accessed unless they are in exactly the correct colour, who knew), whereas developers usually just want a plain theme where they can see the tickets that are assigned to them.
I spent quite a bit of time getting redmine set up correctly with LDAP authentication and all of the themes and plugins, and it’s proven to be worth the effort.
Jenkins
It made sense to have this by default for deployment and continuous integration. Again I added a few plugins but the plugins that you want to use for your projects may be different to mine. I did add the rocket.chat plugin so that our “feed” chats can be notified of successful builds, and the gitlab plugin so that builds are automatically triggered each time there is a push to gitlab.
Rocket.Chat -> Slack
I think that the days of email are over — everyone is moving to more real-time chat applications and this was my pick. This seemed to be simpler to set up than some others, and the LDAP integration was reasonably easy.
Initially I installed Rocket.Chat which served its purpose with useful integrations into Redmine as well as Jenkins. This application and the desktop and mobile apps that go with it are not without their bugs but they work well enough for us.
Later I found that team usage of Rocket.Chat was declining and so to save the cost of the server that Rocket.Chat was running on, I scrapped it and replaced it with a free instance of Slack. The free instance comes with limitations (10,000 message history, messages older than that are discarded) but that limitation didn’t seem to be an issue for the use case that we had — immediate, fast, and impermanent communication between team members.
ownCloud
It will probably make sense to replace this with nextCloud at some point, but the package installation of ownCloud made it a little easier to set up.
There were some issues with LDAP integration — in particular it seems to be set up mostly for AD integration. 389 DS doesn’t make use of the displayName attribute, and out of the box the LDAP integration in ownCloud required that to be able to find the users. A bit of fiddling with the advanced and expert settings had that fixed, including having to restart ownCloud a few times.
Again I get complaints from a certain project manager saying that this is too hard for him and why can’t he email his 120MB project dashboard files to everyone on the project every day? I try to ignore that sort of thing although I’m wondering whether it would not just be a significant improvement to replace every project manager in the software industry with a to-do list.
Email Server
We don’t have one of those!
Seriously though, I have no idea why anyone would want to run their own mail server any more. Gmail is perfectly OK for this sort of thing, and if you don’t trust google then try one of the more boutique providers such as 25mail.st. If I was going to set up a team email server then I would probably use Zimbra but it’s a headache to set up and maintain and I would rather not have that amount of extra work on my plate.
Email communication is inherently problematic for a bunch of reasons (including security) and I try to discourage it amongst my development teams.