Deploy Ember master and multiple journey as a separate engine from different repo?

Hi,

I’m thinking of to use ember for my new project. Before setting up the architecture i have below questions. Is it possible to build and deploy each journey as a separate engine from each repo then the same can be loaded on request in the master app? The reason behind this is we have multiple teams is going to work. each time we may have to release as they complete their journey which is the engine. We dont want to release the master app in compiling the entire engines which will become more dependent on master. We can release master if that repo has any change else no. please clarify.

We don’t want to release the master app in compiling the entire engines which will become more dependent on master.

I’m not sure I understand this part. But I’ll try to explain how this would work with engines…

Engines are their own addons, so you could have any number of engines in their own separate repos and work on them independently, etc. When you consume an engine it is “mounted” in the host app. If you enable lazy loading it will bundle the engine’s dependencies in separates assets files and not load them until the engine is “visited”. The main app must be rebuilt with the newest engine versions to function properly though. So if by the above you mean you don’t want to re-deploy the main app each time an engine is modified you may be out of luck. You might be able to hack something together to swap out the engine bundles but I’m not sure how that would work exactly and I wouldn’t recommend it without considerable knowledge of the engines build process.

If you don’t want to deploy master app each time an engine is modified would you elaborate on why?

Thank for you response. I’m planning to have the CI/CD Process to build the master app for every release. In that case i can build completely including engine. I dont want to update the master app unless there is a required code changes. For engine version update, i’m thinking of to use the latest version so that i can avoid changes in package.json master app. Please correct me if im wrong… The reason behind this thought is, each team as their own release they may release whenever they complete/fix a journey(engine). In that case they can just take a release tag and initiate the build in CI/CD

I think that could definitely work if you set up the dependencies and repos correctly, and engines seem like a good fit for the use case.

1 Like