A month ago I came across a customer who was considering source code management system for an enterprise consisting of couple of thousand users. I wrote him an email which covered up my concerns on what things should be considered when assessing such system. I think I covered the topic quite thoroughly so I wanted to share the same ideas here with a bigger audience. Over ten years of experience in implementing and providing source code management systems for large enterprises - biggest serving over 10 000 users - has taught us couple of things.
Note: I’m not going through the question of self hosted vs. SaaS based source code management at this post. That would require a post on its own.
1. What source code management systems are you using?
Typically in smaller companies - meaning less than 50 users, source code management practices are somewhat unified. This means everyone uses Git, Mercurial, Subversion or some other system. However within larger, more scattered or more dispersed companies the variety of source code management systems differs.
If you require support for all Git, Mercurial and Subversion, there are actually few systems that support all of them. In the worst case scenario you might end up needing separate servers and licenses for each different version control system. This naturally means higher costs for infrastructure and maintenance. Deveo supports all of the aforementioned systems out of the box, which means that there are costs savings for licenses and needed maintenance for hosting Git, Mercurial and Subversion repositories.
2. Extensibility and integrability
Usually it's not enough to just host the source code. Integrations to other systems such as continuous integration servers and issue trackers are needed. Nowadays continuous integration is de facto tool in nearly every software project, however even slightly more heavy continuous integration systems can drain the juices out of your source code management system - if configured in wrong fashion. Typically when you configure e.g. a Jenkins job, you want the feedback to be as fast as possible. With a single Jenkins job and one repository this wouldn’t be a problem. You can set up the polling interval as low as every second. However when you have hundreds of repositories with multiple jobs attached to each one of them, the traffic towards source code management system will be enormous. The problem caused by constant polling of changes can be solved using push notifications from source code management system, however it needs to support this functionality.
Deveo offers over 80 hooks to other tools. Hooks can be used to trigger actions in 3rd party systems after certain actions happen in Deveo. As an example a change to code could be set to automatically trigger a continuous integration build instantly. This will make the feedback loop almost instant and the source code management system doesn’t suffer from flood caused by constant polling.
Sometimes it is also beneficial to provide information from other systems to source code management system. Maybe you want to automate the setup of projects or get the status of builds to your system. In Deveo everything is an API: Anything you can do through Deveo web client, you can also do via programmable API's. One example I use is if you would like to add users automatically when a project is created in some other system, you can do this using the API's.
3. High availability and scalability
SCM system for large amount of users requires high availability. If SCM system is unavailable for any reason in any period of time it affects its users immediately. Especially Subversion users, who are unable to commit or fetch any changes during an outage. Deveo tackles high availability with clustered architecture; you may set up Deveo to be run in multiple application nodes offering 100% availability. Software updates to Deveo are also done in zero-downtime manner meaning that no "maintenance windows" are required.
Using aforementioned clustered architecture allows Deveo to scale according to enterprise needs. You may add unlimited amount of database and application nodes. A load balancer will then take care of the scaling between different nodes.
4. Authentication and authorization
Authentication needs to be fast and seamless. Most proprietary systems support both SSH-key based and HTTPS based authentication to SCM operations. SSH-key based authentication offers additional security and minor performance increase. However in some environments SSH connections are blocked by firewalls.
Authorization should be handled in distributed manner. In some self-setup source code management systems, only a limited amount of persons are able to create new repositories and grant access rights. In these kind of systems authorization maintenance becomes a bottleneck. I believe that there should be as little maintenance overhead as possible for granting rights to repositories or setting up new repositories.
In Deveo authorization has been designed to support scalable and distributed usage. Any user with an account can set up a new project. The user will then become administrator for that project and can add/remove other users to the project. In this manner, the authorization is delegated to project managers instead of IT support. Repositories are created inside projects, meaning that each user in a given project has rights to repositories in it. In Deveo you may also create groups of users and assign them to projects. Naturally there are also Company administrator accounts in Deveo. Company administrators can do and see everything to be able to be in control of things.
5. Different authentication methods
Depending on the size of the company there might be need to control authentication in different ways. In very small companies local accounts to individual systems are bearable way to cope. In large organizations with hundreds of users however, LDAP, Active Directory or similar is used. Authentication to Deveo can be done using local accounts that are created to Deveo or using LDAP-passthrough authentication. LDAP-passthrough authentication authenticates against corporate LDAP (or AD). Authentication can also use a so-called hybrid model, where both local and LDAP accounts can co-exist. This comes handy in situations where external consultants or temporary workers need accounts quickly for say two weeks.
Authentication and authorization is such a wide topic that it would require more in-depth explanation. I will open the topic in a following blog post.
I hope my answers bring some new insights when assessing a source code management system. I would also love to hear what are your needs based on the size and complexity of your company?