Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.

Discussion [Help] CI/CD Brainstorm - please step forward dear DevOps Eng.

Discussion in 'General Discussion' started by JPFerreiraVB, Aug 19, 2022.

  1. JPFerreiraVB

    JPFerreiraVB

    Joined:
    Sep 18, 2017
    Posts:
    39
    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?