For those of you that are making larger scale games, do you all do CI/CD? Why or why not? And if you do, what's your tool/approach?
For those of you that are making larger scale games, do you all do CI/CD? Why or why not? And if you do, what's your tool/approach?
I don't do CI/CD for any games I make because they're generally one-man projects that can be built fairly quickly and don't really have any complex dependency management. If I was working on a team alongside 3 or more developers (like in my day job) then I would use CI/CD because we're working on different things (both different subsystems, as well as different tickets) in which case it helps to have a central "source of truth" build that can be used by QA teams.
Slint approves of me! | "This is Newgrounds.com, not Disney.com" - WadeFulp
"Sit look rub panda" - Alan Davies
At 6/26/23 12:20 AM, Gimmick wrote: I don't do CI/CD for any games I make because they're generally one-man projects that can be built fairly quickly and don't really have any complex dependency management. If I was working on a team alongside 3 or more developers (like in my day job) then I would use CI/CD because we're working on different things (both different subsystems, as well as different tickets) in which case it helps to have a central "source of truth" build that can be used by QA teams.
Cool beans. I ended up deciding it was worth it in my case, just because the scope and build time's gotten big enough that I want to run tests with every change. It's not perfect though: for some reason unity's CLI produces builds that are broken for me, so I still have to build manually for now.
At 6/26/23 12:20 AM, Gimmick wrote: I don't do CI/CD for any games I make because they're generally one-man projects that can be built fairly quickly and don't really have any complex dependency management. If I was working on a team alongside 3 or more developers (like in my day job) then I would use CI/CD because we're working on different things (both different subsystems, as well as different tickets) in which case it helps to have a central "source of truth" build that can be used by QA teams.
But yeah, I agree, for smaller projects the overhead isn't worth it.