* A-A-P is portable over many systems. At least most Unix variants, MS-Windows and possibly the Macintosh. * A-A-P is open source, free software. Most of it is under the GNU GPL. Interfaces and libraries are more free. * A-A-P is not a monolitic program. It is made out of separate modules with clear interfaces. Most of the work is done by existing tools. * Since network connections are slow and unreliable - and when using a laptop - a local copy of a file is often required. A-A-P caches files, obtains a new version when available and cleans up files that have not been used recently. * The more alternatives there are, the more choices a developer has to make. Making all these choices slows down development. Therefore A-A-P provides a preferred set of modules. Many people will be satisfied with most of these modules, but will still be able to use a different module where they have a preference. * A-A-P is available in a command-line version and in a GUI version. The command-line version works on a console and over a telnet connection. The GUI version is easier to use, but requires a windowing system. * A-A-P maintains a set of preferences. These are global to all projects but local to the user or system. This specifies where specific tools, libraries, documentation files, etc. can be found. This greatly reduces the need to configure a package when building or installing it. * English is used in the original code. Provisions are made to add translations through the use of message files. * Reliability is considered more important than fancy features. A-A-P is a tool you can rely on.

* Technology Awareness - One reason TeamCity is dubbed an "Intelligent CI server" is its approach to integration. When we say we support a tool, we mean it in every way possible. For example, support for Visual Studio projects provides automatic detection of tool versions, testing frameworks support, code coverage, static code analysis, and more. And the best thing is, you get all this support without installing any plugins and with no modifications to build scripts! * Configuration - Skillful software developers try to avoid code duplication; similarly, build engineers avoid duplication of settings. TeamCity understands this and provides several ways to reuse settings. * VCS Interoperability - TeamCity version controls systems integration is comprehensive. It’s hard to imagine a project whose source code couldn’t be retrieved by TeamCity. * Key Integrations - It’s impossible to imagine a great CI and CD server without an integration with some key tools like your version control, you issue tracker, your build tool, and your package repository. TeamCity takes it very seriously to provide full support for these key integrations. * Build History - We believe that keeping a history of builds, changes and failures is crucial to the success of any software development process. TeamCity enables you to run history builds, see statistics and test history reports, as well as pin, tag, and add builds to favorites. All of the changes are accumulated in the change log. * Extensibility and Customization - TeamCity provides you with multiple ways of interaction, customization, and extending your server. Use service messages in your build scripts, interact via REST API, or create plugins for TeamCity using Open API. * Cloud Integrations - TeamCity takes advantage of cloud computing by dynamically scaling out its build agents farm on Amazon EC2, Microsoft Azure, and VMware vSphere. * Build Infrastructure - Imagine a conveyor belt of changes from developers and a bunch of testers taking the changes, verifying them and complementing these changes with verification results. TeamCity is such a conveyor, except that testers are replaced with Build Agents. * System Maintenance - TeamCity helps you maintain your CI server healthy and stable even when no builds are running so that you don’t waste your time when it’s needed the most. It provides you with useful reports like Disk Usage, Build Time, and Server Health reports