TeamCity Cloud Getting Started: Create Your First CI/CD Pipeline
In a Nutshell
TeamCity Cloud lets you create a complete CI/CD pipeline in minutes by connecting to a GitHub repo and defining build, test, and packaging steps in a visual or YAML editor. The pipeline runs automatically on code changes, supports parallel execution and artifact publishing, and integrates with CLI, IDEs, and AI agents for monitoring and control.
These notes were generated by AI and may contain inaccuracies.
TeamCity Cloud is a CI/CD service from JetBrains that automates code building, testing, and deployment processes. TeamCity is also available as a local version for self-hosting, but this demonstration uses the cloud version. The demonstration shows creating and running a first build pipeline using a free trial version, connecting to a GitHub repository, and setting up tasks to build and test code. The completed workflow will be ready for checking the results of the first construction process.
To begin, go to teamcity.com, click "Try free", and choose the 14-day free trial period. Registration can be done using an email address or supported service providers. This demonstration uses GitHub. Next, choose a domain name for the instance, such as myteam.teamcity.com. TeamCity will set up the instance in a minute or two.
The demonstration uses Spring PetClinic, a Java Spring experimental application for managing a veterinary clinic. The application already includes an automated build and testing process, allowing focus on running it within TeamCity. Create a project called PetClinic and add a pipeline linked to a fork of the Spring PetClinic repository.
The workflow describes the tasks TeamCity should perform. The path contains jobs, and each job includes one or more building steps. The demonstration creates the workflow using the visual editor, though the entire path can also be defined and modified using YAML files. The process starts with a function called "run tests".
Add a Gradle step using the project's Gradle wrapper so the build uses the version specified in the repository. For the tasks, write "clean test" to compile the application and run its tests. A build agent is required, which is the device or operator that performs the function. This demonstration uses a build agent from the TeamCity cloud with the Java version required by the project. Self-hosted build agents can also be set up in TeamCity.
Save and play the configuration. TeamCity automatically fetches the code and runs the Gradle step. The construction log shows what happens during job execution. The Performance Monitor displays CPU, disk I/O, and memory usage of the build agent during the build process, helping choose the right size construction agent based on actual resource needs.
TeamCity reports test results as soon as they are available, allowing visibility of successful or failed tests while the task is still running without waiting for completion. Individual test results can be examined directly within the Tests tab without searching through the entire build log.
Expand the pipeline to include a three-task configuration. Add a code inspection task to run the tests made up in the project. This task does not need to wait for the tests, so both can run in parallel. For the Gradle step, run the clean, check style main, and check style test tasks.
Add the application package task to create the bootable application. Make this task dependent on both checks so the packaging process begins only after both are successful. Dependencies can be added by dragging and dropping or by selecting a task and choosing its dependencies. For the application package task, add a Gradle step to run the clean and boot jar tasks. The tests have their own purpose, so they don't need to run again here. A single task can contain several building steps.
After the application is packaged, add a script step to create a checksum for the JAR file. This allows anyone downloading the tool to verify its safety. TeamCity detects the CD command in the script and displays the use of this path as a working guide for the script. Accepting this proposal simplifies the script by removing the CD command and moving the path to the working directory field. The steps run in order on the same build agent, so this step can access the file created by the previous step.
Publish the generated JAR file and checksum file as build tools by defining new tools within the output files. This provides downloadable results from the pipeline.
Fully operate the pipeline. TeamCity reuses the test results because both the configuration and the code in the repository had not changed since the previous run. TeamCity Cloud can run multiple build agents as needed, so tests and code checks can run on separate build agents simultaneously. The task of securing both packages is pending their successful completion.
The pipeline completes successfully with test results, construction records, and a packaged application. The jar file and checksum files can be downloaded from the Tools tab.
Up until this point, construction operations were started manually. Automated construction processes are enabled for the main branch. A small change in GitHub triggers a new execution process. Once TeamCity detects a commit process, a new execution process begins. The process can be opened to see what change is being examined, track its progress, and check the results.
After a few route executions, individual test logs can be explored to see if tests succeeded or failed in each operation. The test profile tracks how execution time has changed over time.
Within the route settings, parameters can be specified for reusing values across tasks and storing sensitive values such as passwords and access codes as secrets. Integrations with external services can be added, such as a private NPM log for packages or a Docker log for container images.
Within each task, options help reduce construction times. Parallel testing allows TeamCity to split Gradle, Maven, or .NET test suites into batches and run them across multiple available build agents. This is useful when the test portfolio grows and takes longer to complete. Caching dependencies speeds up subsequent operations by reusing downloaded dependencies such as those used by Gradle and Maven, avoiding downloading the same files from remote repositories in every build process.
Build steps can run inside a Docker container. Specify the image name and tag, or provide a Dockerfile to build a custom image. Although TeamCity cloud proxies come with a wide range of commonly used tools, this allows specifying the tools and versions needed for the step, helping maintain consistency across the environment.
The path was created using the visual editor, but it can also be switched to a YAML editor to view and edit its definition as code. This code can be stored and synchronized with the GitHub repository, allowing the path to be modified from the development environment (IDE). The path now involves code inspection, running automated tests, and application packaging after both tasks are successfully completed. It also works automatically when a change is uploaded.
Once the workflow is up and running, TeamCity can be worked with from the terminal, IDE, or AI programming agent. Start by using the TeamCity command-line interface. Install it, then log in to the TeamCity Cloud instance. Upon logging in, accept the default permissions. A browser window opens asking to authorize the TeamCity command-line interface to access the instance.
Run the TeamCity command to see available options. To get a complete list of commands, run TeamCity-h. Once connected, bring up the results of the pipeline operation. Examine test results and view building records without opening a browser.
AI-based programming agents can also use the command-line interface. Agent skills provide guidance for working with TeamCity, including assistance with workflow migration from other CI/CD tools. GitHub Actions and Bamboo are currently supported, with more options to be added later. Links to the TeamCity command-line interface and setup instructions are available in the description.
TeamCity includes an integrated MCP server, giving compatible AI tools another way to connect, inspect constructions, and help investigate failures. Create a read-only access token in TeamCity, then use it to connect the AI assistant in the development environment to TeamCity's MCP server. Questions about construction processes can be asked directly in the AI chat.
With the TeamCity command-line interface installed and authenticated, a compatible AI programming agent can use it to interact with TeamCity. The accompanying agent skill provides instructions for using the command-line interface. If using a JetBrains IDE, the TeamCity IDE plugin allows checking the pipeline status and viewing test results directly in the development environment, enabling tracking of build processes while working on code.
The same approach is ready to be tried with any project.
Keep JetBrains in your library
Save the videos and channels worth coming back to, and find them again in one place.
