MCET-SEC 2: Repo
This is the second part of the series MCET-SEC where we create a modern cost-efficient toolchain for a small but savvy software engineering company. I run a small development company of 10+ developers. We specialize in Microsoft .NET development (desktop, web, services) but we are doing a lot of in modern web (like Angular/TS) and mobile (Xamarin, native Android and iOS). It was a while since I’ve written “Continuous Integration in .NET” and build the toolchain for my company. It is time to renew it. Lets start with the repo.
Repo it is a common name given by software developers to the most important tool in our toolset: a source code repository. The place where we store the fruit of our loom: the text that creates the software.
It is fascinating to watch the development of source code management tools over the years. I remember using Visual SourceSafe at the beginning of my journey as a software developer. Then there was Subversion in a form of VisualSVN server we’ve used. It was a great tool. Simple and reliable. One central server plus the local repos at the developer machine. But then there was Git that took the art of keeping the source files to another level. The idea was to distribute the repository storage. Every developer is keeping the complete history of the repository on his computer. Committing and branching happens locally. But to work in a team and to have one definite truth about the sate of the source code in any given moment, there was natural need to have one central server. We’ve started to use SCM-Manager. It was a nit small server that let us keep SVN and Git repos alongside each other. Nothing more and noting less. We’ve used it to keep the code for years and we would use it for the years to come but there came GitHub. A tool that took Git to yet another level. Beside simply storing the code, it let the developers discuss the code as it was written. The notion of a pull-request as a way to do a peer code review became a crucial. We’ve used an on premise Bitbucket installation from one of our partners for one of our largest projects, but we wanted to have something like that for our own projects. I went for a search.
I’ve considered those types of source control management systems:
- Commercial cloud based.
- On premise commercial solution.
- On premise free solution.
Cloud based systems like GitHub or BitBucket all let you have private repositories to store our projects. They all are rich with functions and super easy to maintain (or better: there is no need to maintain anything since the service providers are maintaining everything). They have few minor disadvantages that might or might not be a problem: you do not have control over where the code is physically stored (if the fact where you store the code is an issue for you or your customer) and how much you can store. But their tend to be costly. You typically pay on per developer basis. From few to over a dozen of dollars. For a month. So the costs are not scaling good if you get more developers.
You can fight those disadvantages if you choose to install such a service yourself on your machine. BitBucket lets you do this. GitLab seems to be a very good option too. You have almost everything under control. Except the costs. It cost a pretty penny to use. And the licensing is still for a user. It was not an option for us.
I’ve decided to really have everything under our control. The only way was to search among free (open source or not) tools.
As usual while searching for a new thing I made a list with everything that was relevant in a source code management system for my company:
- Does it have a web based interface?
- Is there an integrated pull request / code review functionality?
- How about CI integration?
- We need AD (LDAP) integration!
- Does is have repo based access control?
- Or even better branch based access control?
- Does it have branch listing?
- Is there a personal dashboard (everything that concerns “me”)?
- Is it easy to install and maintain?
- Is there a sound backup/restore strategy?
- Is there integrated project board present?
- Any tooling for road mapping?
- Can we do release notes there?
With he list present we’ve went on a search for the tools. I cannot say it was an abundance of tools. Not really. In end effect we’ve considered two RhodeCode and Gogs.
| Feature | RhodeCode | Gogs |
| Web based? | Yes | Yes |
| Pull request | Yes | Yes |
| CI integration | Yes | Yes |
| AD/LDAP | Yes | Yes |
| Repo based access control | Yes | Yes |
| Branch based access control | Yes (only in Enterprise Version) | Not really |
| Branch listing | Yes | Yes |
| About “me” | Yes | Yes |
| Easy to install and maintain | If you are Linux geek | Yes |
| Sound backup | Ditto | Yes |
| Add: project bard | No | No (or use build in wiki) |
| Add: road mapping | No | Ditto |
| Add: release notes | No | Ditto |
RhodeCode comes with a flock of additional functionalities (like chats, geolocation or full text search. It would let us keep the SVN and Mercurial based repos (not that we are intending but its nice to be able to). Additionally the name of the main developer looked nice to me (it was Marcin). Since we are Windows minded in my company my natural choice was to use Windows Server as a host for our new source control management tool. And then the disaster happened. RhodeCode is basically Linux based. The is virtually no way to install it on Windows. You can pull the complete virtual machine and set it up on you Hyper-V. Which I did. It kinda worked. The AD integration was to be done in a crude text file (well of course!). RhodeCode comes under a dual license. You can choose a paid enterprise version which is richer than a free community version. Then during evaluation there came the moment when the enterprise license expired and I needed to set it up to work in a community mode. There is whole tutorial how to make it. Log-in into Linux machine. Issue those 3 commands, restart this and that. And it seized to work at all. The problem was of course between my ears but it was enough Linux for me. I went for Gogs.
The installation was super easy. Just make sure Git is in the system PATH and download the ZIP according to the “Install from binary”. Simply download, extract to any given directory and run “gogs web” from command line. The LDAP configuration was a bit tricky (as usual) but is was done in 100% from the web “Admin Panel” like this:
Keep in mind you will have to create the user first in the Gogs Admin Panel to gain access to your Gogs using you AD user.
SSL configuration is a matter of editing gogs app.ini file switching protocol and setting cert and key file paths like it is described in Gogs FAQ.
Last thing I’ve done I’ve switched off the explore functionality for the anonymous users (I do want to have the repos available outside my organization but not the listing on my developers). It can be done in app.ini using the switch:
[service]
REQUIRE_SIGNIN_VIEW = true
Voila! Everything is set. I’ll keep you posted about the adoption rate among my developers.