With the transition to a new project on Unity with a relatively large development team, the need for automatic assembly and delivery of the application to devices for testing has sharply arisen. Here's how the situation was with this when I came to the project (on iOS):
- On a separate mac-machine, the project was manually pumped out of the repository (Asset Sever).
- Manually ( File-> Build Settings-> Build & Run ) started the build into the xCode project.
- Further in xCode the archive ( Archive ) became.
- The archive was exported to an ipa-file, which was manually uploaded to TestFlight.
- Further, already in TestFlight access was provided to the necessary testers.
Everything described above is automated with the help of so-called continuous integration (eng.
Continuous Integration ,
CI ). For my previous projects, TeamCity from JetBrains (the creators of the convenient Resharper code refactoring tool) was used for these purposes.
TeamCity (TC) is a very powerful software product that fulfills the goals set for the continuous integration system, at 100%. He can even more. But this article is not about him (there are already
articles on him ), but about the new
Unity Cloud Build service , especially for developers on the Unity engine.
UPD . Unity released Unity Cloud Build to the light, and I updated the article :) Read about changes and innovations below.
First I want to warn you that some of the links below require access to the Unity Cloud Build, its forum and documentation.
Problem
We have a large project, and the whole procedure described above took
half an hour or more . The Mac on which the builds were made was slow. Programmers rarely installed the application on the device (everything was checked mainly in the editor). And therefore, one approach was usually not enough, because after downloading to the device in the application, suddenly (according to the law of meanness) errors were detected. In addition, there was no normal QA. In addition, all this was done on Friday night - i.e. we get all unfavorable conditions for such an important thing :)
')
It is clear that this could no longer continue. The solution had to be, of course, complex, and as one of its parts I set the task: to introduce CI into the development. The task was set as follows:
- the CI system should be as free as possible;
- Must support the assembly of Unity-projects;
- its setup should be very simple;
- for everything about everything - no more than one working day.
Last time, in TeamCity, I killed just about a day to set up the first build, but then I set up and maintained these builds for a long time. In addition, it requires hosting on its server, its configuration and support. And this time I decided to try the Unity Cloud Build. Recently, I heard a lot about him and first of all I bought what I don’t need to have my server and mac as a machine for building, everything is done on their side.
Unity acquired the Tsugi platform and built the Unity Cloud Build on its base. Now the service is already publicly available, any Unity developer, even the owner of the free version, can register and use the system on the free plan by default. I registered with UCB on their page and started setting up the first build.
Customization
It took me about 15 minutes to set up. It is interactive and goes through several stages.
- Enter the project link in the repository . Supported svn , perforce and git . The type of repository is automatically determined by reference. It turned out that UCB does not support Asset Server , which is strange - not to support its own version control system. When I came to work on the project, he was just at AS. When meeting with AS, I was killed first of all by the fact that there is no support for branches (and for a large project this is important), and their merger is based on the time of change ( time-based ), and not on the changes. The lack of AS support from UCB was another reason for the project being transferred to the git repository.

- Configure access to the repository . In the case of git, UCB generates an SSH key that you need to register, for example, in the admin area of ​​a project on a bitbucket or github . After gaining access, UCB allows you to select the branch from which the project will be built.
- Setting up the project . At this stage it is possible to choose the version of Unity, with which the project will be built. UCB now has all versions up to Unity 5
beta inclusive. At the moment, UCB supports Web , iOS and Android platforms , and you don’t need to have Pro-licenses for iOS and Android platforms to access them, at least for now;) In the future, they plan to add Standalone platforms and Windows Phone . You can also specify a specific folder in the repository, as a folder of the Unity-project. 
- Customize the build and subscription applications . At this stage, the certificate is specified for the application subscription in the p12 format. In the case of iOS, the profile is also indicated ( provision profile ) and you can select the xCode version - 5 or 6 (6.0.1 is currently used).

After that, the system will automatically start building the project. At the end of the process, a compact and detailed log of the assembly, the application itself + packed
dSYM (for iOS) will be available.
UPD . As it turned out, in the case of Android, UCB is not able to split apk into expansion files. So in this case, you can use UCB for testing only, and release the build to build manually.

Distribute the collected application
UCB has several options for “sharing” an assembly:

- Collaborators . This is a list of all who have access to the project. At the end of the assembly, each of this list will receive a message in the mail with a link to install. You can navigate through it on the device and install the application in one touch. And you can go to the admin area from a browser on your computer and download the ipa- file and continue to do whatever you want with it. This method has one drawback - all of this list have access to the build settings and all assembled applications.

- Share via Link . A link is generated, according to which it will be possible to download a specific assembly. Anyone can download / install the application using this link. It is permanent, i.e. over time does not change for a specific assembly.

- UPD . Options Push to TestFlight is no more. Apple closed Testflight in its old form (having previously banned the download of Android applications for testing) and proposed, based on it, its version of the distribution of test applications through iTunes Connect. The perversity of Apple's new method is that in order to give an application to an external test ( External Testers , up to 1000 testers), it must pass an internal test - Beta App Review . How long it lasts - I do not know, have not tried it yet, but the application must meet all the same criteria as before sending it to the AppStore. For internal tests ( Internal Testers , not more than 25) testers should have access to iTunes Connect in the role of Technical or Admin, and this is not always possible.
Other features
- The number of assemblies is unlimited . For example, in a free TC there are restrictions on the number of agents (as they call machines for assembly) and the number of assemblies. For more you need to buy additional licenses.
- Unity Cloud Build manifest . I learned about the assembly manifest when I tried to embed in a debug assembly the ability to display in the application information about the commit from which the application was assembled. This is very convenient when testing. It turned out that the guys from UCB are building into a project a “manifest” in JSON format, from which you can get a lot of useful information for tests: commit, branch name, build number, etc. But if you need to build an application for the store, this manifest will go together with him on sale :(
Additional settings
In the settings there is an
Advanced Settings section. Most recently, it was available only on request, in test mode. Now available for paid subscription holders.
- Development Builds . Corresponds to the build options BuildOptions.Development + BuildOptions.AllowDebugging , and the corresponding settings in File-> Build Settings , so that you can debug the assembled application. By default, release is set.
- Pre / Post-Export Method Name . These methods are invoked before building the project and after creating the xCode project, respectively. Here they just allow you to work wonders! It should be noted that the class file for these methods must be in the Editor folder (not necessarily in the root of the project). This is not indicated in the certificate and took my time until I achieved a working assembly.
- Scripting Define Symbols is a very handy thing. You can not set them in the project settings, but set separately for each assembly. For example, to use preprocessor symbols like DEBUG , RELEASE , STORE , and so on in the code.
- Scene List - you can separately specify a list of scenes for assembly. It can be useful, for example, if there are special test scenes for tests.

Subscriptions and price
With the release of the Unity Cloud Build system,
subscriptions have been introduced. There are 4 types of subscriptions, each new one includes the previous one:
1.
Free .
- As the name implies - this is a free plan.
- 1Gb is allocated for a project, and the entire space occupied by the project folder during assembly is considered.
- At least 60 minutes between assemblies, i.e. Before the next assembly (automatic or manual start), you will have to wait at least an hour. But Library Caching is enabled by default.
- Ability to simultaneously collect only 1 project.
- You cannot add other people to the project ( Collaborators ). But you can share assemblies using the links generated by them ( Share via Link ).
- Advanced settings are not available.
2.
Pro .
- $ 25 per month.
- 2Gb to the project.
- At least 30 minutes between assemblies.
- Up to 3 projects can be collected simultaneously.
- Up to 5 people can be added to the project.
- Additional options available are Development Builds and Custom Scripting Defines .
3.
Studio .
- $ 100 per month.
- 5Gb per project.
- At least 5 minutes between assemblies.
- Up to 6 projects can be collected simultaneously.
- Up to 20 people can be added to the project.
- Optional options are Pre- / Post-Export methods and Custom Scene Lists .
- Perforce support.
4.
Enterprise .
- Separate plan. On the price you need to negotiate.
- There are separate machines for assembling your projects.
- Theoretically - the fastest time to build projects.
- All restrictions above are removed.

Disadvantages or anything else you want
- The project is going relatively long . This means a free subscription. It also has a limit of 1 hour between assemblies. Now the project, which is locally collected in 5-10 minutes, is collected on UCB in 15-50 minutes. The reason is that UCBs do not allow it to be stored at home, and each time it is reloaded from the repository. The only optimization that is available is the option Cache Library Directory - it allows you to cache the Library folder for the project, so with the new build you do not have to export everything again. In general, this time is not so critical for development, if programmers have the opportunity to build a project locally for their tests. In paid plans, the time between assemblies is reduced , and the most expensive is the so-called “dedicated build machines” ( Dedicated Build Machines ), in which they promise a very fast build by allocating individual machines for the company and caching the entire project on these machines. Please unsubscribe in the comments, is this true if someone had time to try.
- It is not possible to customize an assembly from a family of branches , such as feature / * . This is a possibility in TC, and UCB always collects from a strictly specified branch. If someone is familiar with the git-flow paradigm, it can be very useful for development, when programmers get different branches for tasks and can (they or testers) test it right away on an assembled application. As a result, we have managed several projects in UCB that are configured for different branches, for example, master (Release-build separately for tests and downloads to the store), develop , release branch for continuous testing of the current release and specific branches of current features ( feature ). Naturally, these projects have different settings, such as Development Build , Scripting Define Symbols . Respectively, the Release-assembly for tests and AppStore automatically gathers as soon as the release-the flow joins master (according to git-flow ).
- There is no possibility to include automatic testing into the process , although Dmytro Mindra at the last DevGamm in Minsk swore that such an opportunity exists) Naturally, this can be done manually, using the Unity Test Tools and the Pre-Export Method option, but I want more serious native support, with a table of test results and graphs)
- Not always the project assembled on the local machine corresponds to what is collected on UCB , and such an application will not always work on the device. For example, we used a plug-in for in-game purchases from Soomla. The application compiled locally worked fine, and the compiled at UCB was “hung up” on the plug-in function Initialize . As a result, Soomla turned out to add the `-ObjC` flag to Build Settings> Other Linker Flags and it is misused by UCB . The problem has already been fixed, but because of it we couldn’t test assemblies from UCB for some time, we had to build the project locally, in the old-fashioned way).
- UPD . No support for split application binary. If Split Application Binary is enabled in the project settings to get an add-on file for Google Play, in case the application takes more than 50Mb, you will have to disable it, otherwise in UCB the output will be a non-working apk without an add-on file. While support for add-ons is not implemented.
Summary
So, I liked the Unity Cloud Build. The project is developing, the forum is asked about current requests from developers and they are gradually implemented, technical support responds fairly quickly. If you are developing projects on Unity and are thinking about CI, I recommend trying Unity Cloud Build. Save time and money.
Pros:
- Quick setup. With ready certificates, profiles and a link to the repository, it will take only 2 minutes .
- The ability to “free” collect under Android and iOS, their licenses do not require, and even mac will not be required.
- For those who do not care about assembly time, this is a great opportunity for automatic assembly and storage of all application assemblies.
- Additional features to customize the assembly.
- The number of projects and assemblies is unlimited.
Minuses:
- Relatively long build time on the free plan. With the most expensive plan they promise a quick build, but I have not tried it myself, I can not guarantee it.
- There is no support for Hg, TFS, Asset Server (although I would not recommend using the last two).
- There is no built-in support for automatic tests.
Waiting for questions, suggestions, clarifications in the comments!
Perhaps someone will be interested to read my previous articles:
Good luck in your development!