I always hear “Hey its free in the beta” , but what is going to happen after the beta?
Its unlikely thats it will be free after that, so what kind of subscription will there be?
One Price per platform , or A specific number of builds included into a fixed price?
i don’t like to start integrating a service into my work flow if i cant see how it might be changing dramatically in one or two month.
If it’s another $1500 or $75/month license, that will probably be a dealbreaker. OTOH, if it’s $500 or $25/month, it would probably be worth it.
Hi @fffMalzbier and @StarManta - I totally understand. Our plan is to offer a free tier of the service after the beta, as well as paid tiers.
We haven’t announced the pricing plans yet, but we’re always interested to know what you think.
Will this work the same as the iOS and Android licenses - e.g. if you are using Pro, you’ll be required to use the Pro/paid tier of UCB? Or will I, as a Pro user, have the option of choosing the free tier of UCB if it suits my needs?
This should be included in the Team license!
The problem is , this is a service and as a service you have running cost and a one time pay does not work this way.
A time limited trail version could be included, that sound like a good idea.
As a customer I don’t want to invent reasons as to why I shouldn’t have or get X or Y. Of course you’re right, but let Unity come to that decision themselves. Anyway, there is Team subscription already.
Given that UCB doesn’t support Unity’s own Asset Server (the thing you currently gain access to with the Team License), it makes little sense to include UCB with the Team License. It would make a lot more sense if it were made compatible, though.
Does it make more sense to add even more types of licenses? 
No part of UCB’s relationship with UAServer (as currently planned, anyway) makes sense, frankly.
I feel the monthly subscription should be around $15-25, but I am sure in order to do that you would need good subscriber numbers.
In order to get good subscriber numbers I think you need to hold the hands of more hobbyist and solo developers to start using version control with their Unity projects. Right now, I think it is sort of a challenging puzzle to figure out what is the best solution and how to start using it.
I am a solo developer and had been using the Asset Server with my projects as I only had limited experience with Git in the past. I wanted to use cloud build it took me a while to figure out a solution. I ended up with Perforce hosted on a Digital Ocean droplet. It is working fine now, but I struggled with almost every step to make it happen from research to server implementation, to using in Unity. You all need some training videos on setting up and best practices for using the different version control solutions with Unity in order to make this more popular.
Other suggestion would be to offer Perforce (And possibly others) hosting for Unity projects as well as making the service free for owners of Team Licenses since the Asset Server is sort of useless now.
I guess the question for Unity will be “how much do you think your developers will pay before they just start spinning up Jenkins/Digital Ocean droplets”.
I like what I see with the Cloud Build, but I also know how to automate most of this stuff using Jenkins and platform specific build slaves. So the question for me (and probably many others) is how much is the convenience of letting that process be in the cloud so that I don’t have to maintain the Jenkins build jobs to run the infrastructure.
Considering it’s a service that is obviously going to cost to run considering the storage and compute power required I totally understand some kind of pricing scheme based on usage. Some large projects and teams could really hit the system!
I’d like to see tiers that depend on the amount of use most probably measured in build time and or build binary and cache size.
What I would like to see before that is further tools to help people manage how often builds are done. For example I can see us opting for a low or free plan, but would not want to necessarily alter our work flow / checkin processes too much.
Obviously we could decide to manage an extra build branch and only push to that when we want a build.
Alternatively I’d like some simple rules on the cloud side:
1.) Minimum time between builds - An automated build will not start until this amount of time has passed since the last build.
2.) External trigger / manual. Allow us to trigger builds instead of relying on when something is checked in, this would allow people to create their own logic to trigger builds.
3.) Regular build times. A schedule of when builds will occur if a change has been made. This could be set to the end of the day for example or allow for finer grain control.
Any other suggestions from others along these lines?
If Unity implements the custom build configurations feature talked about in their recent blog post AND integrates it with UCB, that would be a truly killer feature, worth paying for.
But UCB is currently not fast enough for useful continuous build integration. Waiting 30 min to an hour to know if you broke the build is too long.
If they cannot improve the speed, they should implement a schedule for the builds or some sort of build trigger (like a keyword in the comment on the commit action). If a build fails, UCB could automatically cycle through the older project revisions to find the specific commit that first broke the build.