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:
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:
|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:
masterbranches will run for 20 minutes (job runs every 15 minutes + 5 minutes to finish the merge job)
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.
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:
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.
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:
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.
Let's try to apply GitLab Values to the problem described above: