How to architect packages of large project?

[puradawid]

Hey,

in my experience every AEM project was based on approach to have one package for components (including templates, bundle with models and other services, etc.), one for demo content and one for test content. When there are 10 or 20 components structure of such package is not that bad. With 100 components its starting to be quite hard to maintain:

- code coupling (reusing same templates in many ways)

- deployment is risky (rollbacks are even more)

Generally speaking, too many features are going in at once which has pros and cons. AEM does not have the "feature switch" implemented so far, so this might be a quasi-solution for this problem.

I am considering splitting up one package into smaller ones (one for "basics" and rest of them are components that are covering specific journeys exclusively) and deploy once they are needed. What I am worried about:

- wouldn't be too complex to test deployments with many configurations?

- wouldn't require some specific deployment process to install packages one-by-one?

- what about versioning dependencies?

Also: how are you managing such packages and projects?

[wimsymons]

Great question. I would love for adobe engineers to tell their story. When you look at something like a cumulative fix pack or a service pack it’s pretty much the same problem.

For our own projects we are also coming back from a small number of large packages and switching to a lot of small but functionally contained packages. And indeed, dependecies are a burden to manage. Having a lot of packages is also complex to install. Especially when starting from a blank instance.

Sling does contain something like feature flags (Apache Sling :: Feature Flags ).

[smacdonald2008]

I have asked some of our Eng team members to look here.

In mean time - here is a Support KB on this subject -- How to Work With Packages

[Jörg_Hoh]

Regarding the missing "feature switch". Depending what you mean with that, but with proxy components you can pretty much achieve it quite easily.

/apps/myapp/proxy-components/component/v1/component.html

/apps/myapp/proxy-components/component/v2/component.html

/apps/myapp/proxy-components/component/v3/component.html

and then

/apps/myapp/components/component/ (with the resourceSuperType being either the v1, v2 or v3 component).

That's the approach suggested by the AEM Core Components, and it helps you to decouple the latest development version of components from the ones used by authors.

Splitting up the deployment into multiple packages which can evolve independently is a good approach. Of course should try to keep the dependencies very small, which is not always easy to make (assume that you have a complex JS/CSS frontend, which has some explicit but more implicit dependencies).

But at this point you should have automated testing in place, which should be able to provide the test-coverage of the package versions you want to deploy.

On an OSGI bundle level, the situation is different. Here you should focus in building internal APIs which you can version. Splitting API and implementation and applying semantic versioning is crucial here. Architect your APIs and don't let it just happen (as I have seen on many projects ...)

Jörg