Application Lifecycle Management (ALM) with Unity Apps
Note
This article applies to Visual Studio 2015. If you're looking for the latest Visual Studio documentation, see Visual Studio documentation. We recommend upgrading to the latest version of Visual Studio. Download it here
Developing apps for modern platforms involves many more activities than just writing code. These activities, referred to as DevOps (development + operations) span the app's complete lifecycle and include planning and tracking work, designing and implementing code, managing a source code repository, running builds, managing continuous integrations and deployments, testing (including unit tests and UI tests), running various forms of diagnostics in both development and production environments, and monitoring app performance and user behaviors in real time through telemetry and analytics.
Visual Studio together with Visual Studio Team Services and Team Foundation Server provide a variety of DevOps capabilities, also referred to as Application Lifecycle Management or ALM. Many of these are applicable to cross-platform projects, including games and immersive graphical apps created with Unity—especially when using C# as a scripting language. However, because Unity has its own development environment and runtime engine, a number of ALM features don't apply as they would to other kinds of projects built in Visual Studio.
The tables below identifies how Visual Studio ALM features apply or don't apply when working with Unity. Refer to the linked documentation for details on the features themselves.
Agile tools
Reference link: Work (using Visual Studio Team Services or TFS, including Team Explorer Everywhere)
General Comment: all planning and tracking features are independent of project type and coding languages.
| Feature | Supported with Unity | Additional Comments |
|---|---|---|
| Manage backlogs and sprints | Yes | |
| Work tracking | Yes | |
| Team room collaboration | Yes | |
| Kanban boards | Yes | |
| Report and visualize progress | Yes |
Modeling
Reference link: Analyzing and Modeling Architecture
General Comment: Although these design features are either independent of coding language, or work with .NET languages like C#, they operate on a traditional application paradigm with object hierarchies and class relationships. Designing a game within Unity involves a different paradigm altogether, namely the relationships of graphical objects, sounds, shaders, scripts, and so forth. For this reason, the Visual Studio modeling diagram tools are not particularly relevant to the whole of a Unity project. They could possibly be used to manage relationships within C# scripts, but that is only one part of the whole.
| Feature | Supported with Unity | Additional Comments |
|---|---|---|
| Sequence diagrams | No | |
| Dependency graphs | No | |
| Call hierarchy | No | |
| Class designer | No | |
| Architecture explorer | No | |
| UML diagrams (use case, activity, class, component, sequence, and DSL) | No | |
| Layer diagrams | No | |
| Layer validation | No |
Code
| Feature | Supported with Unity | Additional Comments |
|---|---|---|
| Use Team Foundation Version Control or Visual Studio Team Services | Yes | Unity projects are simply a collection of files that can be placed into version control systems like any other project, but there are a few special considerations described after this table. |
| Getting started with Git in Team Services | Yes | See notes after the table. |
| Code analysis/Improve code quality (references, suggested changes, etc.) | Yes | |
| Find code changes and other history | Yes | |
| Use code maps to debug your applications | Yes |
Special considerations for version control with Unity:
Unity tracks metadata about game assets in a single, opaque library that is hidden by default. To keep files and metadata in sync, it is necessary to make the metadata visible and to store it in more-manageable chunks. For details, refer to Using External Version Control Systems with Unity (Unity documentation).
Not all files and folders in a Unity project are appropriate for source control, as is also described in the link above. The Assets and ProjectSettings folders should be added, but the Library and Temp folders should not. For an additional list of generated files that would not go into source control, see the discussion How to use Git for Unity3D source control? on StackOverflow. Many developers have also blogged on this subject independently.
Binary assets in a Unity project—such as textures or audio files—can take up a large amount of storage. Various source control systems like Git store a unique copy of a file for every change that is made, even if the change affects only a small portion of the file. This can cause the Git repository to become bloated. To address this, Unity developers often elect to add only final assets to their repository, and use a different means of keeping a working history of their assets, such as OneDrive, DropBox, or git-annex. This approach works because such assets typically don't need to be versioned along with source code changes. Developers also typically set the project editor's Asset Serialization Mode to Force Text to store scene files in text rather than binary format, which allows for merges in source control. For details, see Editor Settings (Unity documentation).
Build
Reference link: Build
| Feature | Supported with Unity | Additional Comments |
|---|---|---|
| On-premises TFS server | Possible | Unity projects are built through the Unity environment and not through the Visual Studio build system (building within the Visual Studio Tools for Unity will compile the scripts but not produce an executable). It is possible to build Unity projects from the command line (Unity documentation), so it possible to configure an MSBuild process on a TFS server to execute the appropriate Unity commands, provided that Unity itself is installed on that computer. Unity also offers Unity Cloud Build, which monitors a Git or SVN repository and runs periodic builds. At present it does not work with Team Foundation Version Control or Visual Studio Team Services. |
| On-premises build server linked to Visual Studio Team Services | Possible | Given the same conditions as above, it is further possible to direct builds triggered through Visual Studio Team Services to use an on-premises TFS computer. See Build server for instructions. |
| Hosted controller service of Visual Studio Team Services | No | Unity builds are not presently supported. |
| Build definitions with pre- and post-scripts | Yes | A custom build definition that uses the Unity command line to run a build can also be configured for pre- and post-build scripts. |
| Continuous integration including gated check-ins | Yes | Gated check-ins for TFVC only as Git works on a pull-request model rather than check-ins. |
Testing
Reference link: Testing the application
| Feature | Supported with Unity | Additional Comments |
|---|---|---|
| Planning tests, creating test cases and organizing test suites | Yes | |
| Manual testing | Yes | |
| Test Manager (record and playback tests) | Windows devices and Android emulators only | |
| Code coverage | n/a | Not applicable as unit testing happens within Unity and not Visual Studio, see below. |
| Unit Test Your Code | Within Unity, but not Visual Studio | Unity provides its own unit test framework as part of Unity Test Tools (Unity Asset Store). Unit test results are reported within Unity and will not be surfaced within Visual Studio. |
| Use UI Automation To Test Your Code | No | Coded UI tests rely on readable controls in the app's UI; Unity apps are graphical in nature and so content isn't readable by the Coded UI test tools. |
Improve code quality
Reference link: Improve Code Quality
| Feature | Supported with Unity | Additional Comments |
|---|---|---|
| Analyzing Managed Code Quality | Yes | Can analyze the C# script code within Visual Studio. |
| Finding Duplicate Code by using Code Clone Detection | Yes | Can analyze the C# script code within Visual Studio. |
| Measuring Complexity and Maintainability of Managed Code | Yes | Can analyze the C# script code within Visual Studio. |
| Performance Explorer | No | Use the Unity Profiler (Unity website). |
| Analyze .NET Framework memory issues | No | Visual Studio tools do not have hooks into the Mono framework (as used by Unity) for profiling. Use the Unity Profiler (Unity documentation). |
Release management
Reference link: Automate deployments with Release Management
| Feature | Supported with Unity | Additional Comments |
|---|---|---|
| Manage release processes | Yes | |
| Deployment to servers for side-loading via scripts | Yes | |
| Upload to app store | Partial | Extensions are available that can automate this process for some app stores. See Extensions for Visual Studio Team Services; for example, the extension for Google Play. |
Monitor with HockeyApp
Reference link: Monitor with HockeyApp
| Feature | Supported with Unity | Additional Comments |
|---|---|---|
| Crash analytics, telemetry, and beta distribution | Yes | HockeyApp is primarily useful for handling beta distribution and obtaining crash reports. For telemetry from C# scripts, it is possible to use any analytics framework provided that it runs on the version of .NET that is used by Unity. However, this allows for analytics only within game scripts and not more deeply inside the Unity engine. At present there is no plugin for Application Insights, but plugins are available for other analytics solutions such as Unity Analytics and Google Analytics. Services like Unity Analytics that understand the nature of a Unity project will, of course, provide much more meaningful analysis than generic frameworks. |