Deveo has been built up over 10 years of experience in the complex domain of Software Configuration Management. We have been lucky to be part in building self-service platforms for managing code repositories, delegating access management and enabling collaboration for some of the biggest companies in the world. When we started developing Deveo 5 years ago, we took the learnings from those 10 years and built Deveo for the needs of professional companies; an alternative to the more high profile code hosting platforms, such as Github, where the focus is mostly on the needs of the open-source community.
As a small company, we are constantly in touch with both potential and existing customers. We are often asked how we differentiate from Github.com, which is probably the most known player in the field. In this blog post, I'm going to list some of the differences that distinguish Deveo from other code hosting solutions out there. In addition, I'm going through why we consider the differentiators are essential to professional for-profit companies.
As a disclaimer, some of the differentiators in the blog post are present in other code hosting platforms. If you find any conflicts in this post, do submit a comment at the bottom. In this blog post, I'm only going to cover SaaS version of Deveo and thus, any comparison is made between SaaS versions of other services, mainly GitHub, Gitlab, and Bitbucket. Going through the differences from the on-premises installation point of view would require a post of its own.
In Deveo, users always belong to, and login to a specific company account. All of the information within the company, including the user accounts, are isolated, allowing professional organizations to protect their IPRs rather tightly by limiting who has access to their company data. When a new employee is added to the team, a Deveo account is created with access to appropriate projects. When employees leave the company, the Deveo user account is deactivated and the employee is no longer able to login to that company or access any of its information.
This is not the case in most of the SaaS services, such as GitHub, Gitlab nor Bitbucket. In these services, users have an account, and thus access, for the whole service, which is then limited by "organizations" and repositories. The approach has the following problems.
For an open-source project, it's probably ok to have "excalibur2000", "johnsmith" and "powercowboy1986" contributing in the same project. In companies with hundreds of employees and distributed teams, this causes evident problems, when you don't know who is behind that change because of ambiguous username. The same problem applies to email addresses. Gmail.com and Yahoo.com email addresses might be valid contributors for open-source projects, but in the professional environment, it's typically a must, that developers use the email address associated with their company.
The situation becomes even more tedious with leaving employees. Think about a situation where an employee leaves and you are the IT manager managing 200 users with "scriptkiddie217" and "ilmari2k" usernames. Which one do you remove and how much additional work does it generate to find out? In most of the cases, do you even get notified? Remember that the service is publicly available so the employee is still able to access all the data unless the access is revoked. In Deveo, the user account is always a unique entity within a company, so it can be tied to the company email account and can be safely disabled when the employee leaves.
If you are interested in reading about how you can avoid exposing your code using strict multi-tenancy, we have written a separate blog post that you can read here
Ability to configure SAML 2.0 for each company
SAML 2.0 is commonly used solution for providing single sign-on functionality for services outside the company firewall. In Deveo, SAML 2.0 authentication can be configured per company, which means that you can authenticate against your organization's SAML 2.0 based single sign-on provider. This allows you to limit Deveo usage to only those users who are found from the organization's user directory. In addition, you don't need to explicitly add people to the Deveo company as Deveo automatically creates the user account upon successful authentication against the SAML 2.0 identity provider (IdP).
Support for Git, Subversion, and Mercurial
Deveo natively supports three different version control systems. Without going further into the debate which one of the version control systems should be used, Deveo aims to tackle the needs of such organizations that wish to consolidate all of their code-hosting needs under one platform. This is possible with the support for multiple version control systems.
The benefits of hosting all the code under one platform are the ability to offer similar user experience, access management, integrations and other functionalities to all users regardless of the choice in version control system. To note here, Bitbucket.org supports managing Mercurial repositories in addition to Git repositories.
WebDAV is an extension of the Hypertext Transfer Protocol which provides a framework for users to create, change and move documents on a server, typically a web server or web share. In short, WebDAV is a cross-platform network share that works seamlessly in Windows, OSX and Linux alike. WebDAV repositories can be used for multiple purposes, such as storing release binaries or large graphical assets within the team, all of the stuff you should not put into your version control system. You can watch a demo of WebDAV in action below, or read the full blog post why it's such a cool feature.
External collaborator accounts with limited access rights
There is sometimes need to invite someone outside of your company to collaborate in one or few projects you are doing. Typically, you might not want to give the external collaborator visibility or access to all of the functionalities, however. For example, a typical use case for inviting someone outside of your company could be for them to have in-depth visibility, and the ability to affect the project; or a multi-vendor sub-contracting situation where multiple parties, even competitors, develop the same codebase.
Deveo solves this problem with collaborator accounts. Collaborators in Deveo are a special type of accounts that have no visibility outside of the project scope they are added. Collaborator accounts do not see, for example, a listing of users in a given Deveo company, nor any projects that are public to regular users. This means that you can safely invite a customer or even a competitor to your environment without the risk of revealing your secrets to outsiders. Collaborator accounts are an added security layer for software companies on top of multi-tenancy, which already limits the visibility and adds protection.
In addition to collaborator accounts, Deveo has another unique feature related to access management, which is bot accounts. Bot accounts are non-user accounts that can be used for allowing programmatic access to different components in Deveo. Typical use cases for using bot accounts are continuous integration and deployment servers, other environments where the code is deployed and any integration that uses Deveo APIs. The bot accounts in Deveo can have multiple owners and users, so the ownership can be shared. In addition, the bot accounts can be added to multiple projects, which guarantee that it's easy to setup credentials for tools that are shared among projects. Read more from the bot accounts from another post.
Support for mirroring Android open-source projects
Android open source project, or AOSP in short, uses mostly Gerrit for code reviews and workflows. There are organizations who wish to host mirrors of their internal android open source projects within their own premises. With Deveo, it is possible to setup and host a mirror for the android open-source project repositories without any additional modifications to any configuration files. Doing this in Github.com, Gitlab.com or Bitbucket.org would require modifying the
manifest.xml file that stores the paths for the repository URLs. This naturally makes things more complicated. For in-depth details on mirroring android open source projects locally, read the full instructions on how to setup a local android open source project in Deveo.
Triggering repository hooks based on reference and file patterns
Deveo has the ability to trigger repository hooks based on reference and file patterns. With reference pattern triggers, you are able to notify your team chat tool, such as Slack, HipChat or Flowdock about new commits only to your main branch, or start different automation runs based on the branch. With file patterns, you can notify about changes to release notes or trigger certain builds if for example migration scripts have changed.
Define your team's workflow for issue tracking
In Deveo, issue tracking is milestone based. You can define the states and priorities for each milestone separately. This means you can more closely define the workflow of your team, and model it to your tool. Hosting platforms, such as Github.com and Gitlab.com allow you to only use "open" and "closed" states, which prevents you from seeing what is currently in progress, whether a task is blocked, or if it’s in review phase.
The benefits of custom states allow us to visualize the issues within a milestone in a task board view. The task board view was released in Deveo 3.11 and you can see it in action below:
If you are interested in the issue tracking, you can read a full comparison of Issue trackers of different SCM platforms.
Multiple repositories inside one project
Deveo's focus has always been on delivering the tools for professional software projects. Because of this approach, everything in Deveo is project based. At first, you might think this is a negligible detail, but it's actually not. In Deveo, you create a project and multiple repositories under the project. The project scope has shared issue tracking and Wiki functionalities. This means if your issues touch both backend and front-end repositories, you find both repositories as well as the issues under the same project. By categorizing information under projects and especially having all related repositories under the same project, as well as the issue tracking and documentation, it's much faster to find what information belongs to which project, as well as to find the exact information you are looking for.
Side-by-side editor for Markdown-based Git powered Wiki
Most of the code hosting platforms offer a repository based wiki for storing repository related documentation. As explained above, In Deveo, the Wiki is always project based, meaning it can contain information that spans across multiple repositories. Besides the typical linking between pages, attachments, and everything else you might expect from a Wiki, the Wiki editor in Deveo has a real-time preview, or side-by-side editor, as we call it. This helps to concentrate on producing the documentation, and from time to time check that the changes are as you would expect. With Deveo side-y-side Wiki editor, you no longer need to spend time thinking whether that markdown formatted table is correctly typed or not. See the example below:
Deveo is relatively small company and a young product. As a small company, we have the ability to collaborate extremely closely with our customers and have the ability to match our roadmap based on our customer needs. The above are examples of such needs our customers have had, and that we have listened to.
For more in-depth analysis of why Deveo is the no.1 alternative to GitHub, GitLab, or BitBucket, visit: