Project background

Working in DevOps for a company, tried out some Git products many years ago, but didn’t meet our process needs. So I developed this product in my spare time and used it internally, which was well received. Since then open source, has been maintained up to now. Can be used to build your own Git service, with kanban and CI/CD.

Project address: github.com/theonedev/o…

How does it compare to GitHub/GitLab?

Out of the box symbol search and jump

While the IDE can do these things, we often need to switch to the previous commit search (such as the commit for an issue), which is a bit cumbersome and slow in the IDE to switch the working environment and is not as convenient as simply opening the OneDev search.

This feature uses ANTLR to analyze the syntax of mainstream languages and extract symbolic definitions for incremental storage, which is fast and takes up little space. Currently supports Java, JavaScript, C, C++, CSharp, Go, PHP, Python, CSS, SCSS, LESS and R. GitHub added this feature in the last couple of years, but it seems to be only for the main branch; GitLab needs to do LSIF-related configuration in CI, which is quite troublesome and will take up a lot of space.

It is also common to jump to the definition of a symbol during code reviews.

Regular expression search for repository code

You can switch to any COMMIT and do a regular expression search. The warehouse code uses Lucene word segmentation and incremental storage as needed, with the regular expression itself first performing word segmentation for a rough query, and then performing exact matching in the results to improve speed.

Static analysis results are annotated directly on the source code as supplementary information for Review

Of course, GitHub has a number of third-party tools to do this, but the problems found are displayed on their own sites, separate from the code review process, which can be very inconvenient. For example, we sometimes need to review problems found in static analysis on the source code. In addition, these third-party tools generally require additional fees.

Customizable Issue field and status, and deep integration with CI/CD

Here the simple open/close status of GitHub/GitLab is completely inadequate for our needs, especially when it comes to customer-created issues. If the developer closes the issue when committing the code, the client is notified that the issue has been resolved and asks which distribution we should update to; If the relevant issues are closed when the product is released, the testers will also be confused when they get the beta version, because the relevant issues are still in open state and they don’t know which issues should be tested. To solve this problem, we customized four issue states: Open, committed, Test Ready, and Released. When a developer commits code, the issue is automatically migrated to the committed state; When the code containing these commits is built and deployed to the test environment, the issue is automatically migrated to the Test Ready state and notified to QA. QA can find out which test environment is deployed in the issue details page. When the test passes the release, the issue is automatically migrated to the released state and notified to the customer, who is informed of the associated release in the issue details page.

Commit/Issue/Build/Pull Request query language

This is also based on ANTLR, which predicts grammar rules to achieve automatic prompts. This allows you to do complex queries without having to learn the syntax, such as what our customers often do to see what changes have been made between the current version and the latest version before upgrading. Queries can be saved and subscribed so that they can be notified when events that match the criteria occur.

Fully functional CI/CD, no need to know Yaml syntax, very easy to get started

CI/CD is the most effort, and while the definition of CI/CD is also stored in the repository as a Yaml file, a UI is provided to generate the file and the user can configure it without knowing any relevant syntax.

You can run CI/CD tasks directly from the Commit page, making GitOps more intuitive. The flexible and customizable CI/CD options page makes deployment easy for non-developers.

It is extremely convenient to deploy a cluster for building, just a helm command can be deployed to Kubernetes, each build task will run as a Pod, Windows and Linux support; In the environment without Kubernetes, a docker command can start a built Agent, and Agent is free from maintenance, automatic upgrade.

Discard Organization and organize projects in a tree structure for easy inheritance

Since GitHub has used Organization, it seems that all similar programs have adopted this approach to organizing projects. This approach may be appropriate for a public-service oriented cloud platform, but it doesn’t feel necessary for internal use. Our approach is to organize projects in a tree structure, with subordinate projects automatically inheriting the Settings of their parent projects or overwriting them as needed. This makes configuration and maintenance of a large number of projects very easy.

Feel free to annotate and discuss your code without relying on a Pull Request

You can initiate an instant discussion of any block of code while browsing source code or Diff. The discussion will be part of the code documentation (even if the code is later changed or even renamed) so that others can read and understand the code later. Unlike other Git tools, code Comment is displayed on the side to avoid fragmentation of code context.

In addition, each discussion is organized into a separate topic, making it easy for interested parties to know where new changes or responses are coming in.

Compared with GitHub/GitLab, resource occupancy is much smaller and faster

For personal use, a 1 core 2 GB machine is sufficient by default, adjust the memory Settings in conf/wrapper.conf, or run on a 1 core 1 GB machine. That’s a lot more than Gitea/Gogs, but if Gitea/Gogs were to do something similar, Golang’s ecosystem would probably require enabling microservices written in other languages (various Language Servers, Elastic Search, etc.). The ultimate resource consumption must not be small.

Another advantage is that the main service can run on Linux, Mac, Windows, FreeBSD, etc., can use the built-in file database, Also can make full use of the company’s existing resources to connect to the MySql/MariaDB/PostgreSQL/Oracle database SQL Server thereof.

Other features such as automatic recommendation of appropriate code reviewers based on Commit history, synchronous scroll preview for Markdown editing (not simply scroll bar percentages, but context synchronization), customizable issue associations, detailed permissions, and more are added to the list.

Technology stack

Not hip enough, but Java from head to toe. All the code is in a Maven project (about 400,000 lines of code), regardless of the front and back ends. Using Wicket (probably not many people have heard of it) encapsulates interface interaction and back-end logic in a component, and the configuration interface is generated automatically through annotations. The dependency injection and plug-in architecture is based on Guice. It takes about 20 seconds to start a project in Eclipse, but most of the time it’s hot deployment, and you can see the changes by refreshing the page after changing the code.

Thank you for your attention, interested friends here five minutes tutorial (create the react demo, and configure a CI) : zhuanlan.zhihu.com/p/103410072