Hybris Extension based development

Speed Vs Complexity

We are often challenged to deliver quickly.  "develop in parallel teams" , "double the team size" is usually the battle cry. As an architect that means design in parallel and then the system that get integrated at the end. As the design and delivery challenges are won , the effort in code merges mount exponentially, especially when multiple team ended up building code in silos. I have recently faced this situation in a Hybris development project.

Traditional Hybris development

The developers in multiple teams were working on copies of the same code with limited control over who changed what.

While merging, the process included

- merging of global object definition as a super set of both the developments

- merging of facades and controllers for the web front end.

- merging of core classes caused the developer to use a file diff software to trace what has been changed.

With the current code base at a critical of 10 million lines of code - it is understandable why it took so much time to merge.

Using extensions to separate code

We found the answer to the problem with a simple re-structuring exercise. Simple !!! Not really !! The exercise was not simple - but the concept is. The burden was legacy code. However allow me to explain the concept:

  Instead of using one web extension, we create a series of extensions that can be categorized into three categories.

• web based extension that had a URL / context and can act as a channel. All the JSP's, controllers and facade are present in this extension
• Extension (web without URL) that allowed implementation of business level services and owned by a team. This extension had a one or more interface that implemented a business logic for other extensions to consume.
• integration level extension that allowed to build integration code with third party systems and can be stubbed for ease of development. 

One additional extension was created to store and manage the domain object definitions for the entire stack. This extension is tightly managed by the designers. This allowed to keep governance on the objects created, defined and persisted across the entire system thus restricting individual teams  to create domain objects at will.

Pattern Enforcement and ownership

The concept of communication was codes in one extension can call codes or interfaces either in same layers or in the layers below. This patterns enforced are:

• Facade pattern
• Chain of command pattern

Along with the pattern enforcement each team was given the responsibility to own and deploy their own extension. If a business extension is owned by the team, the team is responsible for releasing the code with the appropriate interfaces from time to time.

	Extension 1	Extension 2	Extension 3
Team 1	Own	Use	Update
Team 2	Use	Own	Update
Team 3	Use	Update	Update
Team 4	Use	Use	own

When a team launched a new version of the code, it will use the matrix to inform the necessary team for the changes and its impact. The changes are again manged by release plan as opposed to random updates.
For example , Release A will have Extension 1 (V 1.2),Extension 2 (V 2.2) and Extension 3 (V 1.0), where as release B will have Extension 1 (V 1.3),Extension 2 (V 2.2) and Extension 3 (V 1.0). The project that updates the extension 1 to 1.3 lists the service class changes and communicates the changes to other teams.

Benefits in merging

The Merging is not chaotic anymore.
From the configuration management plan  for the release, we know know which version of the code to check out. Along with the global modules, its a matter of placing the directories in the right folder, updating the extensionsinfo.xml, and running the ant scripts.
Of course the web extension may need merging of the controllers and JSPs but a different domain and and project intials appended to the jsp pages will reduce copying conflict.