Ci Cd doubts | Official Unity Discord | Page 1

silk rampart Apr 17, 2024, 4:55 PM

#

Just a sec !

#

Im back, @vague sequoia

#

So first question is;
How is CI/CD defined in terms of UnityAPI since the build tab provides for much automation for the target platform (Gradle management in android, XCode export for IOS sure sucks though but still there is some level of 'one click finish' function with build button) .

vague sequoia Apr 17, 2024, 5:03 PM

#

So you can google up on a build script that you can write in C# that can do everything (via code/the API) that unity does from the menus, and in fact, this is how you do builds from the command line

silk rampart Apr 17, 2024, 5:04 PM

#

I am familier with the API, my question actually orientes more towards 'why' rather than 'how'.
Pardon English is not my first language !

vague sequoia Apr 17, 2024, 5:04 PM

#

For example, I have a script called "Build.cs" that basically looks like this:

public static class BuildScript
{
    [MenuItem("Build/Build Android")]
    public static void BuildAndroid() { .. bunch of stuff .. }
    
    [MenuItem("Build/Build iOS")]
    public static void BuildIos() { ... bunch of stuff ... }
}

And from the command line I can call the unity exe to execute those methods:

                $UNITY_HOME/Contents/MacOS/Unity \
                    -batchmode -quit -logFile -projectPath . \
                    -executeMethod BuildScript.BuildAndroid -buildNumber $UPDATED_BUILD_NUMBER -nographics

#

why? that's a big question..

you can do all the builds without needing to sit at your computer for an hour
you can automate it so you're less likely to fuck something up
you can put passwords, keystores, signing keys, etc in a repo so they aren't exposed in plaintext or shared with everyone on the team (who could then publish their own apps with your company's signature)

#

consistent builds that don't vary based on configuration differences from machine to machine
automatically triggered and deployed builds so whenever you check in a branch the builds are automatically kicked off and distributed to your company/testers/beta testers/etc

#

lots and lots of reasons to automate it

silk rampart Apr 17, 2024, 5:07 PM

#

Hmm hmm. So these reasoning is pretty much similar to what I thought.
Basically to reduce the 'human error fuckup' factor correct ?

vague sequoia Apr 17, 2024, 5:07 PM

#

as well as all of the above, which are just as important for companies at different stages of growth

silk rampart Apr 17, 2024, 5:07 PM

#

vague sequoia * consistent builds that don't vary based on configuration differences from mach...

I have followup questions in this but Ill let you complete first.

vague sequoia Apr 17, 2024, 5:07 PM

#

fire away

silk rampart Apr 17, 2024, 5:11 PM

#

consistent builds that don't vary based on configuration differences from machine to machine

I am unable to think of examples for Configuration differences. Say there is a need to build for android platform. And the android build support is installed with unity and it successfully builds the project.
This doesnt require much configuration as these are simply one click installs.
So what other stuff would entail in Configurations ?

vague sequoia Apr 17, 2024, 5:13 PM

#

NDK version
JDK version
unity version
packages mistakenly installed on one machine but not on another
bad using statements which resolve on your machine but have dependencies that aren't on the target devices (ie - unityeditor)
try to build an ios app on windows - apple explicitly tries to make this hard/impossible
all the configuration options in the player menu - versionCode, resolution, app icons, company name, etc - lots of this stuff will be in your repo but can be difficult to coordinate if you have more than one engineer

#

basically by doing a cloud based build you just eliminate all the configuration management - it's much more work up front but after it's done it's completely automated.. I literally have builds go off every night automatically, in the morning I just open the app and it's ready to test.. if I didn't have them go automatically it would be at least 60 minutes+ of work every morning just to get the latest app on my phone (and all the testers phones)

silk rampart Apr 17, 2024, 5:15 PM

#

hmm hmm.

vague sequoia Apr 17, 2024, 5:15 PM

#

#

slack notifications, links for anyone to download the android app if they want, etc

#

usually by the time I wake up the latest app has already been pushed to my phone even so I don't have to manually update

silk rampart Apr 17, 2024, 5:16 PM

#

I see the big part also includes the freeing-up pc by waiting for builds

vague sequoia Apr 17, 2024, 5:16 PM

#

(since phones tend to update apps overnight based on some magic assessment of when to do so)

#

yes.. time is limited, builds take time, the last thing i want to do is sit and stare at a progress bar for 15-30 minutes and be unable to really do much

#

i already spend enough time staring at this every time i make a tiny code change

silk rampart Apr 17, 2024, 5:18 PM

#

Regarding versions, resolutions and packages version controlling simply takes care of but build times resoning is sensible.

#

Okay next part of questions.

#

So I read that you setup the builder such that builds kick off every night and in the morning there is a fresh build ready.
I understand it must the schedule we want and emmv.
But does the building take place from a 'master' branch. i.e. The one which is production.
And If so.. It must be enforced to only merge it when everything is tested/verified ?
Or is there any other approach to it.

Oh I mean how would one manage when there are 4-5 programmer working on the project, roughly ?

vague sequoia Apr 17, 2024, 5:21 PM

#

you can build from any branch you want

#

i build from builds/latest and merge into that when i want a build

#

but you can set this up however you want.. some common strategies:

Build from master every day, gitflow merge and PR into master
Build from a set of release branches: builds/latest or builds/version-1.0-production or builds/latest-internal or whatever you want
Build trigger on master (or any other branch) any time a PR/merge is completed

#

For my team (3 devs, 1 artist, 1 level designer) and my current project, we all use master as the "latest stable", and branch from and PR back to master as work is completed. Every day, I merge master into builds/latest if it's stable (just as a personal preference since sometimes things go wrong with master - someone [including me] checks in a bunk file or whatever).

Builds go automatically every night from builds/latest and push to google play so any work from the previous day are visible in the next day's build. If someone wants something more quickly I can still manually kick off builds

#

once we go to production, we'll probably use builds/latest as just our internal QA testing version and periodically name a release and do a manual build from that branch. EG: builds/version2.0 which I'd run the same CI/CD script on

#

we use codemagic.io, which I like - i used github actions last year for another product and it was a lot more fickle

silk rampart Apr 17, 2024, 5:27 PM

#

Hmm hmm hmm

#

So the above 3 approaches you mentioned.
If a certain build has faults, lets say some logical runtime bugs. Some text not updating or some non fatal error. QA would report it post testing.
Programmer merges changes and that kicks off build but few issues remain to solve. Wouldnt this enforce programmer to merge only when 100% Pr are covered ?

silk rampart Apr 17, 2024, 5:31 PM

#

vague sequoia we use codemagic.io, which I like - i used github actions last year for another ...

I was thinking of TeamCity but Ill lookinto this one! Thanks!

vague sequoia Apr 17, 2024, 5:31 PM

#

what do you mean 100% Pr are covered

#

If there's bugs, fix them and merge into master 🙂

#

Bugs happen, and there's various severity of bugs, but that's unrelated to CI/CD really.. devs (and even artists and level designers in my company) are still responsible for high quality work.. doing lazy work that isn't tested is either a symptom of it being difficult to test (in which case you gotta spend some engineering time making it easier to test) or lazy effort; both of which won't be solved by CICD automated builds

silk rampart Apr 17, 2024, 5:59 PM

#

No no, I understand bugs happen.
What I meant is.
Having the branch set to build upon merge would enforce the state of the branch to be 'stable'.

i.e. you dont merge till everything is atleast accounted from devs(art/code/design) and then proceed to merge and then QA takes over ?

Then incase of bugs, What do you do ? Does QA Halt the testing till next build arrives ? Or list all the bugs in the current one. Then upon next merge QA tests the new build all over again ?

#

.

Another thing:
Also if there are 2 consecutive merges with 30 min gap.Say bug fix from coder then fix from lev designer.That would result in 2 builds. How would QA proceed in this scenario ?

vague sequoia Apr 17, 2024, 6:03 PM

#

Yes, build/latest is "stable". But in general we're early enough in dev that there's very few bugs so I merge master into build/latest every day. Later in dev we would have master get merged into something like a release candidate branch, test the crap out of it, fix bugs in it, and only then move it into a production branch

#

If there's bugs in the build, we just fix them in master (and merge master into build).. but none of our bugs are hard to fix.. they take minutes, usually, and 90% of them are "oops I put the wrong art in" or something trivial like that

#

We don't do builds from master so two consecutive merges aren't a problem.. in fact, I'm the gatekeeper for master so any PRs have to go through me to get into master at all - once they do, I merge master into builds

#

If there's any merge conflicts when I do the PRs that's up to the developers/artists to figure out - ie, who is responsible for which file or which is the "best" one to check in

silk rampart Apr 17, 2024, 6:05 PM

#

vague sequoia We don't do builds from master so two consecutive merges aren't a problem.. in f...

This answers my doubt. So you merge all only when everything is ready andd that kicks off the production build .
Also You do the production build manually ? or via pipeline.

vague sequoia Apr 17, 2024, 6:06 PM

#

you can do it however you want 🙂

#

personally I do production builds "manually" (but still using CI/CD)

#

i never build on my machine

silk rampart Apr 17, 2024, 6:06 PM

#

vague sequoia you can do it however you want 🙂

Ik ik Im just asking how you do it. Just to have some baseline and make sense around it

vague sequoia Apr 17, 2024, 6:06 PM

#

i log into codemagic and press build 😛

silk rampart Apr 17, 2024, 6:07 PM

#

vague sequoia i log into codemagic and press build 😛

XD I expected this !

vague sequoia Apr 17, 2024, 6:07 PM

#

#

#

#

#

if it's an internal build, i'm done - it just goes automatically out to people's phones when it's ready

#

if it's a production build i'd check it out, then manually "promote" the build to production in the google play console

#

but if you want, you can build directly to production, if that makes sense for your app

silk rampart Apr 17, 2024, 6:08 PM

#

Great! Thank you SIRR!
This answers many of my questions and helped me wrap my head around the whole thing.
Rather than doing for the sake of it I wanted understand the problem and judge the pros cons.
And your wisdom was helpful !

vague sequoia Apr 17, 2024, 6:08 PM

#

gl

silk rampart Apr 17, 2024, 6:09 PM

#

vague sequoia if it's a production build i'd check it out, then manually "promote" the build t...

This makes sense as it adds a sanity layer.
Hmm Hmm Ill think of something in this line too

silk rampart Apr 17, 2024, 6:09 PM

#

vague sequoia gl

GL ? ?

vague sequoia Apr 17, 2024, 6:12 PM

#

good luck

#

👍

#Ci Cd doubts