Application Lifecycle Management (ALM) with Unity Apps


This article applies to Visual Studio 2015. If you're looking for the latest Visual Studio documentation, use the version selector at the top left. We recommend upgrading to Visual Studio 2019. 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


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


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:

  1. 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).

  2. 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.

  3. 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).


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.


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.