Internally at FIE LLC I created a build system, to keep my shared assets under control. I’ve been using it for about a year.
Once I encountered the need to publish open source unity packages, I decided to open source the build system, simply to keep my development clean.
You can find it on GitHub, here.
Currently, my build system is based on uTomate, which can be found for purchase in the Unity Asset Store. In the future, I may remove that dependency. We’ll see.
The idea is rather simple.
You run the configure script, and the build system will reach out and configure itself for the current operating system and environment. If you move to a different computer, or check it out to a new system, re-run the configuration before using the build system.
Once your build system is configured, you can then expect everything else to work.
An artifact is a thing you are making and building. It has a name, a type, and a version. The name is up to you. For now, I only support unitypackages as artifacts. But there is an option for building a player. Versions should be in dot format. major.minor.build. e.g. 1.0.1
Ideally, once you do a proper release, you would increment the build to indicate what version you are now working on.
Individual artifacts within the project typically provide a make script and an export script.
The make step, is reserved for doing processing and making things inside the editor. A make script might include baking lighting. You might create a complex make script that takes parameters. Or, you might create multiple make scripts. For example: make_fast_game and make_release_game. By default, the make script is usually empty. But you can put whatever uTomate supports in there.
The export script will export the artifact from unity. In the case of a unitypackage artifact, you can expect it to be put in your user’s unity_packages directory to be used by you on other projects. It keeps a simple naming and organization standard and keeps versions straight.
I actually mirror my unity_packages directory between my workstations with SyncThing. That allows me to keep a library of my own published packages for myself, in the (peer to peer) cloud. In your shared environment, you might make that a network share. Or a subversion repository. Or whatever you want to do, to distribute versioned packages to your teams.
The build system is currently incomplete. It provides commands and data to manage unitypackage dependencies and automatic updating of those dependencies. However, most of this is not implemented.
The easiest way to create a new unitypackage to be managed by the system is to first import uTomate and the build_system. Then, copy the “build” directory from the build_system into your own package directory.
Then, go through it and customize each item.
Start with the artifact. Set your name and first version. Such as 0.0.1.
Then, rename the export_build_system plan to export_[yourpackage].
Then, rename the make_build_system plan to make_[yourpackage].
In the actions directory, rename the export_build_system_package action to export_[yourpackage]_package, and edit the function in the Output File Name to use the name of your artifact rather than “build_system”. The system uses this to look up the right artifact. So make sure it matches the name in your artifact. Also, change the includes to point to your own asset package directory(s) rather than the build_system.
Last, test it out. If you got it right, then running the make_[yourpackage] plan, followed by the export_[yourpackage] plan should result in a nicely named package in your user directory. If you import it into a new Unity project, it should all be there.
If you like, you can exclude the build directory to make sure your exported packages don’t depend on the build_system or uTomate. Or, if you plan to use the build_system everywhere, you can leave the build directories in.
Contributions to this open source project are welcome. But if you’re going to do something big, you should probably contact me about it.