Search Unity

How is your setup in terms of CI? (Jenkins, fastlane, ...)

Discussion in 'Testing & Automation' started by bdovaz, Mar 10, 2019.

  1. bdovaz

    bdovaz

    Joined:
    Dec 10, 2011
    Posts:
    1,052
    First, thank you for this subforum. I was waiting for a space where I could interact, share and ask for features in everything related to testing and CI.

    Next, I'll explain the evolution of this topic in my organization.

    I'm in charge of my organization's code base for years and two years since we started using continuous integration. We have adopted it with the help of:
    • Jenkins: from where we execute all the jobs.
    • Sonarqube: for static code analysis so we can be sure that we wrote the best code possible from the rules perspective.
    • u3d: automation of Unity editor and modules installation.
    • fastlane: related to everything that has to do with Android or iOS releases and their management of certificates, provisioning profiles etc... We use the internal, alpha and beta channels in Android and Testflight in iOS.
    We have gone from having to manually publish everything to being able to automate the entire publishing flow of all the platforms we use: Windows, macOS, Linux, Android, iOS, WebGL and UWP.

    It is key in projects in which we need to publish for several platforms at the same time, for iOS (really painful workflow by Apple...) or for platforms that require or we want to publish in IL2CPP (really consuming build times).

    We have several nodes in Jenkins so we can have parallel executing jobs or jobs that are partially executed by one machine and the rest from other machine.

    Apart from the workflow for "real" projects we have the following setup for our codebase where we run Jenkins pipeline parallel steps:
    • Run all tests.
    • Run a static code analysis and publish it in Sonarqube. We check for code smells or bugs.
    • Run a build on all platforms. That way we can test that our code successfully compiles on all platforms without issues.
    • Publish in separate unity packages.
    • We also have specific jobs for building our custom native plugins for: Windows, macOS, Linux, Android, iOS, WebGL and UWP.
    To achieve all of the above we have custom groovy shared libraries on Jenkins

    We have an Alienware and an iMac with SSDs on our CI setup. We only have one executor on each node (machine) because I don't like running multiple Unity builds on one machine in case there are collisions or weird problems.

    What I want to do in the next months is:
    • Start using private scope registries with package manager so we can start publishing our own private packages. I want to automate it with Jenkins. I did a setup of verdaccio and a few manual package publishing tests with promising results.
    • Start using Unity's code coverage but I need to wait for it's release.
     
    IARI, mkg2w, tonybf and 1 other person like this.
  2. JJJohan

    JJJohan

    Joined:
    Mar 18, 2016
    Posts:
    214
    We're also using Jenkins, currently using two dedicated Windows slaves to do our builds. I've experimented with using a linux Docker container with a stripped down Unity install i.e. remove most of the debug-only build files. In addition I've also symlinked a lot of duplicate files. For example, there are 4 identical 40MB binaries in the WebGL build support files :(.

    Ultimately we end up with a 700MBish (350mb compressed) Docker container for Windows/Mac/Linux and WebGL builds. Unfortunately we've kind of shelved it for now because it's been a pain in the ass to get Unity to activate/deactivate headless instances, and seemingly impossible to get a headless instance to use 'free' licenses paralleling internal builds - although we've heard there were plans for a license server solution from Unity to be announced at some stage. The idea is then to simply run our CI through Jenkins instances hosted in AWS.

    Most of our unit testing is done via NUnit outside of Unity with a bit of effort gone in to abstract Unity code from the complex logic to allow it to be unit-testable at all outside the Unity editor, although we do have some integration tests done via the Unity editor although we haven't really found these to be as easily deployable with our existing solutions.

    Similarly we're also keen to start using private scope registries when we move to the 2018.4 LTS version (currently on 2018.1 for our product). I gotta say I was a little perplexed to read a recent Unity blog post stating the Unity staff were surprised that people want to use CI/CD with the Unity editor when it's been going on for years.
     
    tonybf and emilmarian like this.
  3. liortal

    liortal

    Joined:
    Oct 17, 2012
    Posts:
    3,562
    We are using TeamCity, not Jenkins (yeh, i'm THAT GUY that likes TeamCity!)
    Our setup is currently 9 x build machines (mix of Windows and MacOS).

    The build environment takes care of everything from building clients (mobile, WebGL), building asset bundles and running tests (mostly play mode tests, some unit tests) as well as some other tests (static analysis, etc).

    I would actually love to move most of our tests to be pure NUnit unit tests that are possible to run even outside of Unity (like @JJJohan suggests) to cut on running time, but this is a pretty difficult thing to achieve without starting to break down the entire codebase as it is right now.
     
    tonybf and emilmarian like this.
  4. IARI

    IARI

    Joined:
    May 8, 2014
    Posts:
    70
    @bdovaz thanks for sharing.
    This post might come a bit late - but this is our ci setup so far:
    - we use gitlabs ci/cd
    - using game.ci docker containers for builds
    - fastlane for android/ios deployment

    The one thing I've been struggling to get to run is sonarqube.
     
    Last edited: Nov 27, 2021