Hi all. So, in short, currently working on a project that has some specific deployment type and thus needs a new way (at least to my small CI/CD knowledge) of implementing the CI/CD pipeline. So feel free to share ideas and suggestions. Imagine this type of project: - We want to implement a humanoid as an assistant, to help the user somehow. - The project is to be implemented for several clients, (you can think of a shopping mall, where each store have its own humanoid, with its own clothing and look and feel) - The logic/ codebase for the humanoid is shared across projects: connections with API, backend, etc. - The humanoid visual is specific to each store. Clothes, badges, Logo, - Some humanoid assets might be shared between projects. Animations, Base model, Animator, etc - Client A might want to update the model and add more animations and new features and client B might just want to keep things as they are. The challenge: - How should we create this, in order to: A) Be easy to deploy a new project with minimum process repetition, and reusing as much as possible. B) Be able to roll back to a specific version of the codebase combined with a specific version of the humanoid. Imagine, i've updated the code base (remember is shared between projects) and the humanoid with some animation, but i might want to roll back so i can debug a weird thing that is happening on the client deployed version. C) Be able to have this in Jenkins (platform agnostic this exercise is high level) Our current approach: - We have a base project where the code base is developed, and that code base is shared via Package. - For each client, we have a repo, that fetches the package and we implement there the humanoid part. Animations, Scene setup, etc. - For each client, we have a Jenkins job that fetches the specific repo and builds the final build. The problem with this approach. - Sometimes we end up copy-pasting assets from one project to another, because 90% of the work is the same except for the Visual/Branding part. - If a project stays still for a long time, and after it requires a new feature, updating the latest code base, might take some setting up to accommodate the changes made over time in the package. The "new approach" - We were aiming to have everything in one project, use addressable, and build against a addressable group The "new approach" problem - The project will grow indefinitely, and for each final build, the job would have to take all the assets, just so then it would pick a few to build upon. - Difficult to version the different projects/code base. If you got to this point you are my hero. Any idea how would you guys sort this out?