Before being the awesome platform you know…
eXo platform is approximatively (excluding comments) 900 000 lines of code (Source : SonarQube) like this:
In this set of articles I will present how we are managing our sources and various tools that helping us.
In this first part, we will see the organization and dependencies between platform components. In a second article we’ll discover where to find all sources repositories. In a third part we’ll cover workflows used by our teams to manage our codebase. Then in a last post we’ll see the tools we are using to manage our sources (edition, code review…).
As shown below eXo platform isn’t a unique project including all these lines of code. This is the arrangement of various subprojects for various reasons :
- Historical (we are talking about many years ago) : The product was more fragmented and was offering various independent services (CMS, Forum, …) on top of a standard platform (JCR/Portal). Nowadays we are offering an homogenous integrated platform built on the top of these historical services.
- Architectural : Under the large set of features offered by the platform there are many technical pieces with their own lifecycle, their own constraints that we have the possibility to compound for our needs. Also it enforces teams to clearly define the frontier of each component and to design backward compatible APIs exposed to others. Also it avoids to rebuild all the platform for each change (while our teams are focusing on the stability of each project and its integration with others, our continuous build/integration/deployment platform will describe in a future article is taking care to validate the whole platform).
- Organizational : With several dozen of developers working on platform (and related projects), and nearly 900k lines of codes it could be quickly a nightmare to manage all of this in a unique code base. It avoids to have too many people working on the same lines of codes (even if it is really more easier today to manage branches in DVCS systems) and thus we have little teams (3-6 persons) working on projects with fewer lines of code.
We’ll see in a second article that this fragmentation of the code base doesn’t have only positive points and brings it’s set of drawbacks especially to manage feature or maintenance branches.