Brainstorm long-term architectural solution to avoid CE->EE conflicts
Solutions discussed here should be long-term solutions.
This issue is currently a stub, we should start by gathering information on how others deal with this issue. And then discuss solutions.
Feel the pain
We should do daily CE->EE merges, and not a single person should be responsible of them. This way everyone would feel the pain more regularly, leading to everyone wanting this problem solved!
Similar proposal: #25870 (closed)
Paradigm shift
Original proposal by @vsizov: https://gitlab.com/gitlab-org/gitlab-ee/issues/715#note_15020398
Work on EE and merge EE into CE regularly. CE to EE merges will still have to be done since community contributors will continue to work on CE.
Pros
- conflicts will mean removing code, which is usually easier
- developer won't forget to update EE (https://gitlab.com/gitlab-org/gitlab-ee/issues/715#note_17358450):
one case where working on EE first would really help is where we develop something that has an impact on something in EE, but we forget about it because there's nothing mentioning that code in EE! For instance, if we add something that needs to be in ElasticSearch, or something that will impact on approvals.
Cons
- everyone on the team will have to work on EE, but issues would remain in CE...
- community contributors will still work on CE
Models
-
Reduce the size / responsibility of models by using dedicated classes & composition: #23786 (moved) (+ historical discussions in #13484 (moved)) -
Put EE code into an EE
module, see https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/910
Controllers
Services
-
Put EE code into an EE
module, see https://gitlab.com/gitlab-org/gitlab-ee/merge_requests/910
Views
-
Consider bringing view decorators back: #23563 (closed) -
Use more partials!
Notes:
- The mid-term solution will be to refactor some part of the code that conflicts often: gitlab-org/gitlab-ce#23864