Skip to content
GitLab
Menu
Projects
Groups
Snippets
Loading...
Help
Help
Support
Community forum
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
Menu
Open sidebar
gpt
large_projects
gitlabhq1
Commits
6f1f8d98
Commit
6f1f8d98
authored
7 years ago
by
Tiago Botelho
Browse files
Options
Download
Email Patches
Plain Diff
Adds the first draft for the documentation of how to port a feature from EE to CE
parent
fcea5fc8
Changes
1
Hide whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
46 additions
and
0 deletions
+46
-0
doc/development/porting_a_feature_to_ce.md
doc/development/porting_a_feature_to_ce.md
+46
-0
No files found.
doc/development/porting_a_feature_to_ce.md
0 → 100644
View file @
6f1f8d98
# Porting a feature from Enterprise Edition (EE) to Community Edition (CE)
Porting a feature from one version to the other can sometimes be a complicated process
with many pitfalls, this document lays out some lessons learned and common pitfalls to avoid.
## The EE counterpart should always be the superset of all changes
There should be no change in the CE version that is not in EE.
If a table being ported has extra columns in EE than in CE make sure you add those columns
in a separate EE-only migration.
## Scope
You should always try to reduce the scope as much as possible, to keep the changes intuitive
and easy to review.
A good example would be if there are a few methods in a model that need to be ported over
to another model. In that case, a good possibility would be to begin by delegating every method
to that model, and then, make a separate merge request that finishes the port of those methods.
## Migrations
Migrations can become quite a complex matter at GitLab's scale so they should always be handled with
extreme care.
Make sure you read the
[
What requires downtime guidelines
][
downtime
]
and the
[
Background migrations guidelines
][
background
]
.
If a table needs to be migrated, you should always base yourself on the actual state of the schema
rather than looking at each migration related with the table in question.
If we are dealing with a large volume of data that needs to be ported, batching should be considered.
For more information refer to the
[
iterating tables in batches guidelines
][
batches
]
.
Always make sure the database changes are MySQL compatible.
## Pipelines
The EE specific pipelines, such as
`ee_compat_check`
,
`ee-specific-lines-check`
and
`ee-files-location-check`
become especially useful when porting a feature over to CE since they will be able to help you prevent
possible conflicts when a CE-to-EE merge takes place.
[
downtime
]:
https://docs.gitlab.com/ee/development/what_requires_downtime.html
[
background
]:
https://docs.gitlab.com/ee/development/background_migrations.html
[
batches
]:
https://docs.gitlab.com/ce/development/iterating_tables_in_batches.html
This diff is collapsed.
Click to expand it.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
.
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment