Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Blueprint: Working in CE and EE codebases


Blueprint: Engineering workflows

Design: Releases overview



GitLab is released as two flavors to the public, Enterprise Edition (EE) and Community Edition (CE). EE has a proprietary licence while CE has an open (MIT) licence. EE is a superset of CE and all CE code gets consumed into EE. Each of these two editions has its own project repositories, with separate codebases.

By the end of reading this page, you should have an understanding of:

Features development and release

All GitLab Inc. developers work in both CE and EE when developing features. CE also receives community contributions.

A common development flow is represented in the table below:

Feature Development Release
CE feature CE repository CE and EE
EE only feature EE repository EE
EE feature expanding on CE feature CE and EE repositories CE and EE

For example, for a feature available in CE, development is carried out in the CE repository but the release needs to be done for both CE and EE to make the same feature available in both editions. Furthermore, to release EE all changes from CE need to be brought in before the release. These workflows are represented with the following diagram:


This presents some challenges in both the development speed and release. Let's take a look at required time for a CE feature to land in EE:

This would mean that, based on current pipeline size and runtime, the best case scenario when there are no flaky specs or other failures, we take 125 minutes for every commit created.

What was done to improve the situation?

We've invested time in speeding up the specs and significant effort went into automating merges between CE and EE codebases.

In CY18, we went from a daily manual task to merge one days worth of work, to automated CE-to-EE merge requests that would run every 3 hours (and ultimately every hour).

This attempt, while a huge improvement overall, was still fraught with challenges:

In response to these challenges, Delivery team created the Merge Train. The guiding idea was that we need to automate the task to remove human manual participation and run the tool more frequently. This tool merges changes automatically and resolves conflicts by throwing away CE changes in favour of EE changes. This process works somewhat as long as developers setup an EE counterpart in case their code conflicts.

However, the Merge Train tool is also not without its challenges:

At its core, the problem is that we have two different repositories with similar (but not identical) code. As long as this split exists, getting your CE changes into EE is painful and time consuming. As such, we seem to be down to only two possible solutions:

Improving Merge Train

As previously mentioned, Merge Train is a custom one-off tool made by Delivery team to try and resolve the challenges of merging two codebases. As is often the case with one-off tools, investing time and effort in them is only worthy up until one point.

The tool took some time to think through the problem and develop, and also taught us some painful lessons.

While it helped us merge CE commits into EE commits faster, it is still not resolving a few larger issues:

Due to the above, more work is required in Merge Train but also in both codebases to support quicker merging of codebases:

Based on the above, we can make some conclusions about investing time in this solution:

Merge CE and EE codebases A.K.A Single codebase

Whenever development time suffers due to working on two dependent separate codebases, the topic of merging two codebases is raised.

There were number of discussions raised about this, most notable ones are in:

Based on the discussions in issues listed above, we created a design document on merging the two codebases.

Applying GitLab values

Let's try to apply GitLab Values to the problem described above: