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 life cycle 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 Azure DevOps Services and Team Foundation Server, provides a variety of DevOps capabilities. 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 DevOps features don't apply as they would to other kinds of projects built in Visual Studio.
The following tables identify how DevOps features in Visual Studio apply or don't apply when working with Unity. Refer to the linked documentation for details on the features themselves.
Reference link: About Agile tools and Agile project management (using Azure Boards 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 |
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 (TFVC) or Azure Repos | 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 Azure Repos | Yes | See notes after the table. |
Improve Code Quality | Yes | |
Find code changes and other history | Yes | |
Use code maps to debug your applications | Yes |
Special considerations for version control with Unity:
Reference link: Azure Pipelines
Feature | Supported with Unity | Additional Comments |
---|---|---|
On-premises Team Foundation Server (TFS) | 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. |
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. |
Reference link: Improve code quality
Feature | Supported with Unity | Additional Comments |
---|---|---|
Analyze managed code quality | Yes | Can analyze the C# script code within Visual Studio. |
Find duplicate code by using code clone detection | Yes | Can analyze the C# script code within Visual Studio. |
Measure complexity and maintainability of managed code | Yes | Can analyze the C# script code within Visual Studio. |
Performance tools | 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). |
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 Azure DevOps Services; for example, the extension for Google Play. |
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. |