TeamCity lets you automate CI/CD for projects of any size and complexity while using Docker for every step of your pipeline.
Have you ever been frustrated to find that code you debugged on your own machine didn't work in other environments? TeamCity lets you run builds and tests in Docker, ensuring that your application is not tied to your specific system and will work correctly elsewhere, from a QA’s machine to a production instance in the cloud.
Looking for a way to build a scalable and maintainable CI/CD infrastructure? With TeamCity, you can customize Docker commands with build parameters, use templates to set up centralized pipelines, and automate the cleanup of build agents and Docker registries from obsolete Docker images.
Do you need to test how different app components work together, or test your app in a specific environment? TeamCity will start Docker containers, run integration tests, and safely shut them down at the end of the process in a highly reliable and reproducible manner.
TeamCity supports and can speed up all software development workflows that use Docker. While other CI/CD tools provide only binary information about build results (that is, whether they succeeded or failed), TeamCity deeply integrates with Docker, giving you comprehensive information about your pipelines, including:
As a result, you can quickly find problems with your builds, understand what needs to be fixed, and deliver new features faster and with better quality.
Choose between the cloud and on-premises versions of TeamCity:
Hosted by JetBrains
Are you looking for a CI/CD solution with Docker support but don’t want to run it on your local machine? Check out TeamCity Cloud, our managed service.
Hosted by you
Do you have local builds that you want to decouple from your machine and move to a Docker container? Start with TeamCity Professional. It's free for small projects!
The Docker build runner allows you to add build steps that execute Docker commands. It is particularly useful if you need to dynamically customize Docker arguments. For example, you can run builds under a specific version of an operating system that was defined earlier in the pipeline. It also allows TeamCity to automatically clean up the local cache of Docker images on build agents, making sure they are ready for subsequent builds.
For more details, see the Docker Runner section of our documentation.
Docker Wrapper allows you to run a TeamCity build step in a Docker container independently of the host operating system, providing consistent and reproducible results. TeamCity tracks all events that happen during the build and provides you with real-time reports, test analysis, and other smart features, like stack traces from within the Docker container.
For more details, see the Docker Wrapper section of our documentation.
The Docker Compose build runner is used to start Docker containers at the beginning of a build and make sure TeamCity shuts them down after the build is completed or stopped. Its primary use case is running integration tests in which components are containerized and their execution can be described using Docker Compose files. For example, TeamCity itself is tested against multiple versions of different databases that can work as its backend, and the respective integration tests are run with the use of the Docker Compose build runner.
For more details, see the Docker Compose Runner section of our documentation.
The Docker Support build feature is used to manage access to Docker registries. Configured at the project level, it supports all popular services, including Docker Hub, Amazon ECR, JFrog Container Registry, and others, allowing different TeamCity features to work with them. For example, when server cleanup deletes data associated with an outdated build, it can be configured to remove Docker images published as part of that build.
For more details, see the Docker Support section of our documentation.
Let’s say that you’ve implemented a backend service that builds and runs on your own computer. Even if you are not planning to use it outside your local environment, there still are many things that can change over time: the operating system, build tools, third-party libraries, and others. Maintaining a fully static environment on a local machine is unachievable in practice; sooner or later something will break.
With Docker and TeamCity, you can make your builds fully reproducible and avoid the hassle of managing dependencies and fixing compatibility errors. A CI/CD pipeline for a Java project with Maven could look like this:
TeamCity gives you real-time reports about your builds and tests, from the moment you commit to VCS until you get the results, allowing for the fastest feedback loop possible. It supports projects of any complexity and scale, and it helps your team minimize bugs, ship features faster, and establish a more transparent development process.
You can set up CI/CD pipelines without writing any code by using a simple web UI. You can also configure them programmatically using Kotlin and implement a maintainable, reproducible continuous integration setup that can combine multiple programming languages, operating systems, and cloud platforms.
TeamCity can work with Docker on any platform that supports a Docker runtime, including Linux, Windows, and macOS.
Yes, in addition to running builds in Docker containers, TeamCity can create Docker images, push them to Docker registries, and delete them based on various criteria.
Yes, TeamCity On-Premises is free for small projects, and has no limitations on the number of users or build time. TeamCity Cloud offers a free 14-day trial period. Both versions have full-featured support for Docker.
With TeamCity, you can choose between running builds directly on your machine or running them using Docker containers.