Does Unity have any options for dealing with licensing on build machines?
I’m currently at a small studio that has a Mac Mini with Jenkins on it. Jenkins takes care of continuous integration, but in order for it to build Unity projects, we need to activate a license on that machine. Currently, this means that someone at the company needs to “give up” their secondary license install, which isn’t ideal. Another problem: we’re hoping to get a few more build machines, but it seems we’d have to force employees to give up their secondary licenses, or buy Unity Pro licenses specifically for those build machines.
Is there any solution besides buying more licenses for the build machines? Considering those machines don’t have real people using them, and they use Unity in headless/batch mode, it seems to be a bit much. Has anyone else had to deal with this scenario?
That’s an interesting question. We do the same, build machines and even dedicated bundling machines. But given our size, we just get licenses for each. But for a smaller studio, that cost may not justify the return. The license is pretty clear when it comes to “users”, I’d be curious what the official answer is as well.
Isn’t there 8 or 16 or more core machines that could do this? It’d be cheaper and likely faster too, certainly than the lot of you on MacMinis all buying Unity Pro licenses.
You may have misunderstood. He’s talking about a separate computer(s) with unity installed that is automated, doing continuous builds (or other tasks). Builds and some tasks are done on it, so developers don’t have to locally build each time. So if I make changes to the game, I commit them and either tell the build machine to build or it is automated to do it on schedule. Everyone else can just update their device to see the current build. Rather than pulling, building locally. Or for our bundle machine, if I commit asset changes, I can keep working and the build machine will create new bundles for all devices and push them to the server. It is very fat and convenient with multiple devs.
Hmmmm, that sounds like what I meant, developers committing changes to a server machine to do builds, those are built, pushed to the QCs & testers with their test devices, yah or nay with report back to the developers and on to the next bit of functionality.
However, I’m not sure what he means be secondary licenses unless it’s for those Pro licenses needed for each Pro platform. He doesn’t say what version of Unity but Unity Pro seems designed to enable that type of workload distribution and network storage sharing among properly licensed machines.
All that seems sub-optimal though. Are the developer machines beefy enough to do distributed headless builds locally on network storage while the developer continues to work in the Editor on the same machine? 4 or 6 cores should be more than enough of course with Macs if that means new HW for each developer it’s like buying 2 Unity Pro licenses. They have to write the built scripts to built on the machine with the relevant Pro license is all after the changes are pushed via the network to their machine. I know Unity already does lots of lighting and other things in parallel. Or would even doing a headless build while still using the editor violate the license somehow? Don’t know if they are on a fast lan or an iffy wan though but I guess they are already sharing large resources over that network. They get the additional bonus of redundant storage if the network files are copied to a local disk, built, and copied back.
Unity can tell them the allowable setups for such a thing since they have Pro licenses. I’d open a Premium Support ticket to get his team setup using their HW & Unity Pro licenses optimally.
Even with a fast machine it’s not efficient to do locally. It would be possible, but no where near as fast and not without slow down, potential problems and hit on the network. You can easily run multiple instances of unity on a single machine, but if you have one in the background doing builds it will slow down even a fast machine. Especially if you have many or large assets (and/or baking), doing it across a network. Moreover, you would have to still have checks in place to ensure that changes don’t occur to assets on the server by someone else mid build. A build server/machine handles all that if it is the one doing the builds. Also decentralizing adds risks and other challenges like different settings and platforms and scheduling and conflicts. And also, in our case, often folks making changes and doing builds aren’t even using unity in the first place. Art or design may be submitting assets or data to be in the build.
I believe what he means by secondary licenses, is that unity allows two installs per person. So one or more users are giving up their second install to the build server(s). Meaning they can’t, for example, have it installed on thier desktop and laptop.
Oh, I know it will cause slowness due to network bottleneck but on a machine with sufficient SSD storage and CPUs/GPUs it should fly. However Intel needs to step up their GPU design and give a bigger and dedicated bank of GPU memory separate from CPU memory. I think the better and cheaper solution that can be done now is to have the builds and packaging kicked off as needed by the QC / Tester. We’re talking small potatoes here. What’s that 15 or 30 minutes of build and packaging time on an app of the total of the many hours they should be designing, developing, and testing that app with? It’s indicative of insufficient design time before development and testing begins.
If secondary licenses mean 2 installs per user then if Unity could elegantly switch back and forth without restarting between Pro and Free licenses by local license sharing between the Developers’ editor machines and the headless build machines that’d seem to do the trick but the license should only be able to be shared between the specific developer that owns that license and the build process. I don’t think logistically, for the hassel it would be for Unity to develop such a license sharing mechanism, they’d bother. Really if they are using Unity 5 Pro there is precious little that Unity 5 Free won’t build on a shared built machine already. Just the custom splash screen is all they’d loose I think.
They can pay for Premium support ticket to learn how to better utilize Unity team tools that Unity Pro has. That Unity are adding a Team License for monthly sub to Unity 5 Free shows they have been already confronting this issue and have decided with Unity 5 the need to impede Unity 4 Free users from leveraging Unity 4 Pro features via team collaborations is gone because, except for the skinning and the splash screen, there isn’t any.
If you want to run Unity for a build machine you don’t need a special licenses but you will need an additional Pro license (if you’re team is running Pro).
If you are also running Pro at the moment, you get 12 Months of Cloud Build for free with every license so I would suggest trying it and see if it fits your needs (if you haven’t already), that would also mean you don’t need to use up someone activation or buy a new license. https://build.cloud.unity3d.com/landing/
Hi @ , thanks for the data! While we’re intrigued by Cloud Build, our repository is currently ~24GB, so we’d have to use the enterprise tier, based on current restrictions. I may be able to reduce that repository size to make Unity Build an option - something that I’ll consider. But currently, it makes more sense for us to have in-studio machines doing the build process. I’ll pass along to the owners the notion of following up with a Sales Contact.
The idea of using developer machines is intriguing, but I don’t want to use developer CPU during the day and interrupt their work. Additionally, even in batch mode, Unity will add an icon to the dock, and is slightly disruptive to the machine, so doing it on a machine being used by a developer would probably be inconvenient, at best. An additional snag, though a system like Jenkins CAN execute multiple jobs in parallel, is that only one Unity instance can be open when in batch mode (though I don’t think this is a limitation in normal mode?).
Anyway, this is one of those scenarios where a viable technical solution just doesn’t seem to work with the business model. When it comes to continuous integration, adding additional nodes to your “build farm” is a pretty common, distributed approach, but it’s a more difficult option with Unity involved.
I am certainly biased, but a reasonable solution might be adding a third “build” seat to a license, which can maybe only be used in batch mode. But of course, I am also a customer who doesn’t want to spend more money than I have to, so of course that sounds great to me :). There are probably reasons that it isn’t possible from Unity’s perspective.
Anyway, thanks again for all the data! It seems that, for the time being, we’ll have to continue using additional licenses to fuel our build machines. We’ll try following up with Unity Sales and see if there are any other options we can pursue.
Cloud build is not suitable for all projects and is not without it’s problems and limitations. Many of us don’t want to upload a project when we can just build it locally.
You could also do builds using developers’ machines at night when there is exactly 0 people in the office. Just instruct your team to leave computers on, only turn screens off and use some scheduling software, (Widows has one built-in, Linux has cron, not sure about OSX) so Unity can built in batch mode.
I definitely appreciate the various suggestions for alternative solutions or workarounds to using dedicated build machines. I was mainly curious as to whether there is an “official” way to deal with licensing on build machines, since it seems like a problem that would come up frequently. It seems like the solution, at this time, is to just use secondary seats of licenses, or buy dedicated licenses for build machines.
I think that Unity Cloud Build, or co-opting developer machines during off-hours could certainly be good solutions for some situations, but they don’t feel like great solutions in my case.
I’d love some way to run Unity in batch mode as part of my pro license, but even if everyone agrees that’s a great idea, it would no doubt take a lot of time to implement!
It takes nothing to implement, it’s just it isn’t going to happen. All they need to do is include additional seats for command line only access for doing builds. I appreciate you get two licenses with a Pro license, which is really needed as you can’t do everything from one platform but having a local build server is much better/reliable than cloud build.
Yeah, do I need 1 license per build machine? I currently have 6 (1 per platform, Windows, Linux, Mac, X1, PS4, Switch)
Those are very limited hardware in a 1U rack, with only a SDD. They have Jenkins running, pull a SVN changelist, compile in no graphic mode, then put the result on a FTP. The hardware of those machine is less than 500$ each.
Our game SVN right now is about 50Gb which creates an extra 25Gb library, and output an ~10Gb game build. Before we are done with our game, we except our depot to reach ~70-80Gb. We can’t use Unity cloud service because clearly I don’t have 10-12 hours to wait for your service to pull out our database. Just the initial library recompiling is an hour and half.
I’m really not a fan of 6x 25$ or 125$ per month, for licenses that only get used 2-3 times a week. And before you ask, if I was to compile those 6 platforms on my own computer, with the 1.5h of switching between them, and about another hour of compiling… I get waste a full day only doing 1 build for 6 platforms, while now I just remote desktop to 6 very cheap PC, and bam! An hour later my FTP is full of builds.
How about a license that are only for running Unity headless?
We’re also facing this same issue… Unity Cloud Build is not a viable option for us. As we grow we’ll need more build instances but with each instance requiring a new license, it’s just not going to be sustainable having so many unused licenses burning a hole in our budget. It’s an easy solution Unity, have batch mode only licenses!