TeamCity

TeamCity is used across all the development, test and DevOps departments across the company. It's integrated with every GitLab project to provide efficient continuous deployment respecting the priorities of the different projects' builds and the availability of the nodes which are multiple racks. It has been an excellent decision to purchase such a tool.

We make use of TeamCity to build and deploy our code from our git repositories to our various environments - development, test, staging, and production. We have incorporated comprehensive tests into the process as well, making TeamCity the backbone of our CI/CD pipeline that has strengthened our ability to deliver features.

The organization is rather small, so it is used by the whole organization, for all the projects we are working on. We are using it to perform tasks of continuous integration and continuous deployment to several environments including test, acceptance and production.
We are also running all our automated unit tests using TeamCity.

TeamCity is being used across my company. We have integrated TeamCity with the CI/CD pipeline. This is solving number of problems which occur if we do not have CI/CD in place. Configuring node servers to build the projects is easy. We can easily configure the properties while building the specific branch. Can easily build multiple feature/develop/release branches at once. It gives all build related information at one place, so can troubleshoot problem in build easily. Basic implementation of application is easy.

We use TeamCity on a self-hosted instance to build our ASP.NET projects, .NET desktop projects, and Angular projects. We use it to automatically build these various projects from our git repos and then execute deployment scripts via Octopus Deploy. We also run unit tests on each build and tie in build and test status to our code review tool, Upsource. TeamCity is part of our end-to-end pipeline that allows us to get quality changes out the door quickly and react to production issues quickly.

We use TeamCity as a CI/CD tool for our pre-production and production builds. We've set it up for near full automation use and have set it up with multiple steps for each build. TeamCity is used on a team-by-team basis here at my work. Several surrounding teams in many different departments use it with much success. TeamCity solves the problem of integrating other tools in the CI/CD build process without being too complicated or without too much overhead. Given a corporate firewall can cause great limitations, it's nice to have a tool that's simple to integrate with other tools.

TeamCity was used by the technology department of the organization, especially by the web development team.

We used TeamCity to test and release code from our development environment to our production environment. Our web developers worked under an agile project management system and used continuous integration. In this system, TeamCity allowed us to integrate our git repository with our ticketing system, as well as help us quality assure and properly release clean code to production.

TeamCity is the go-to tool to getting the Builds and Deployments packages for a variety of platforms like .NET, Java and JS etc. It is being used by the whole organization. It unifies the build and deployments needs of all the diverse projects to a single platform and solves the build and release issues previously we faced and reduces the time to go to Prod.

Our company has two products. 1 of which, TeamCity is the critical tool for development and for both products, it's the critical tool for automation testing. In all cases, both development and product support use it. It's the tool which pulls together the 300+ components that make up our current SaaS-based product and the tool which schedules, executes and produces reports for all our type of automation testing (behavioral, backward compatibility, performance, security, and load).

We used TeamCity as our Core Continuous Integration solution for four years. I love TeamCity's easy to use interface, and the way builds and releases are linked together in dependency Chains. I found it particularly helpful that Builds can be run separately, or in advance of Releases - and then when Releases are run the Builds only run again if the code has changed. TeamCity's Templates, Variables, and Parameterization capabilities also made it very easy to establish a flexible template for common solutions such as deploying MVC applications to IIS. Once templates were configured I could create a "build and release" for a new project in less than 10 minutes.

While TeamCity has a simple to use and understand chaining mechanism, allowing builds to call "builds and releases" to rely on multiple dependency chains - TeamCity's PipeLine visualization capabilities are one of its weakest points. I had a complex build across five different environments consisting of eight different solutions and over 20 deployment targets. During a major update, it would have been nice to visualize the deployment pipeline and "watch" the deployment process for issues - but that really isn't possible with TeamCity. Outside of that, TeamCity worked great, integrated well with all of our platforms: Git, Azure, AWS, Visual Studio Team Services.

Great Product.

TC is used across our organization to do builds for all our apps and services. We started using it to replace our custom build and deploy system because we needed something more flexible and customizable, and something that did not need a fully dedicated support team.

We use TeamCity for Continuous Integration & Delivery of our software products. We have many projects for various customers that are built and integrated continuously whenever we check code into our git repositories.

We use a mixture of Gradle & Maven builds and TeamCity handles both well.

We get immediate feedback from TeamCity if a code change has caused issues with other linked projects and, because we have confidence in our tests we also have confidence in a 'green' build prior to delivery to a customer.

TeamCity is used in every rollout of code to production in engineering. We heavily believe in test driven development, we probably have more tests than actual code for the product. Since we have nightly releases, TeamCity (CI) is great for getting all our builds tested and ready to go for release.

I set up TeamCity for our core product continuous integration. For both the main product and the core libraries it is used to compile on check in, build and deploy on pull requests, and to run the unit and functional tests. No code goes into the develop or main branches without passing through this process.

We use TeamCity at San Diego State Instructional Technology Services to support our CI (Continuous Integration) and CD (Continuous Deployment) needs to support our Agile DevOps practices we implement for our developers. TeamCity also allows us to integrate with our Issue Tracker (YouTrack) and GitHub to ensure we stay on top of issues, and make sure that all of our production deployments are stable and reliable (thanks to Unit Testing, which is handled automatically by TeamCity on artifact build and deploy).

Every single commit to our codebase results in an automatic full build and unit test run, then this code is automatically deployed to a bare-bones environment if it builds and the tests pass.

TeamCity was used by my team to do the continuous evaluation and integration of various projects under our team. It was used by our team only in our organisation. It was easy to spot wrong commits and build a failure before the product release. This was very easy with the help of a continuous integration tool like TeamCity that has a very versatile UI.