Overview. Hello!
I’m Na’Tosha and I’m the Build and Infrastructure Developer here at Unity Technologies. While speaking with users at the awesome Unite 2011, I had several people ask me to write a blog post about how Unity Technologies manages to develop, build, and test Unity. We do this with a combination of: Continuous IntegrationAutomated TestingCode HostingCode ReviewsManual Testing I’ll talk about how we do the first four of those things here. The Continuous Integration Server Our builds and automated tests are all run by TeamCity. We use TeamCity from JetBrains as our continuous integration solution. Our only real complaint now is regarding the web UI — it can still be slow to load at times (specifically, when loading a large project page that hasn’t been loaded for a while, or when opening the custom build run dialog when a lot of agents are attached).
The Build Farm TeamCity farms builds out to a distributed build farm of between 40 and 50 machines. Why Mercurial? A Code Review in Kiln. Regression Testing. One of the unwritten commitments we make to our customers is that our webplayer will play back their content identically in all versions we publish.
We constantly tweak and improve the webplayer. For example webplayer 2.6 added threaded background loading and improved animation culling. Each change that we make intending to improve the webplayer has the potential to break a customer game, and we don’t like that. Remember, webplayer 2.6.1 can play content authored with Unity 2.0, 2.1, 2.5 and so on. To make sure that we don’t break customer games with new webplayers we have to do a shed load of regression testing. Obviously, the games require inputs such as keyboard and mouse entry, random numbers, assets fetched from remote websites. The regression rig should help us find problems with the webplayer before you do, but as always, please let us know (by sending in a detailed bug report) if you have issues when you publish your game to the web.
Bug Tracking. SCM Solution. Team Up Don’t compromise on quality.
Kiln makes it easy to get feedback, mentor team members, and improve the quality of your software. Another set of eyes on your code now means fewer bugs later. Learn more… Keep Track Don’t compromise your project’s success. Kiln helps team leaders track the team's progress and reach their goals. Learn more… Get Organized Don’t compromise your productivity.
Kiln gives you tools to visualize, organize, and understand your code. Learn more… Mercurial/Kiln migration. At work we switched to Mercurial almost two months ago.
Like Richard says, it was time to stop using Subversion. Here are my impressions so far. Preemptive warning: I’ve only ever used CVS, SourceSafe, Subversion, git and Mercurial as source contro systems (never used Perforce). I never really used a code review tool before Kiln. Everything below might be non-issues in other tools/systems, or not suitable for different setups/workflows! The Story At Unity we used Subversion for source code versioning as long as I remember. svn revision 1 — an import from CVS — happened in 2005. Since merging branches in subversion does not really work well, everyone was mostly working on one trunk, carefully. So we looked at various options, like git, Mercurial, Perforce and so on. In hindsight, maybe switching three things at once wasn’t the brightest idea; there’s only so much change a person can absorb per unit of time.
Our Setup We use Fogcreek’s Kiln and host it on our own servers. Things like this: Packager.