How to integrate Plastic SCM with TeamCity CI server

Create a new Project in TeamCity

First step is creating a new Project in TeamCity, which will be attached to Plastic SCM VCS later. To do that, Go to "Administration" > "Projects" and click on "Create new Project" button.

Type a valid Project name, ID and an optional description, and click on "Create" button.

Create a build Configuration

After creating the Project, TeamCity wizard asks for a Build Configuration. Again, enter a valid name, ID and description and click "Create" button.

Create VCS root for the Project

This is the wizard step where we attach our Project to Plastic SCM as VCS.

Select "Plastic SCM" as a type of VCS, enter a VCS root name and ID, required by TeamCity.

The specific fields for Plastic SCM plugin are the following:

• Server: location of Plastic SCM server (IP / name:port).
• Repository: the Plastic SCM repository to download contents for the build Project.
• Branch: the default branch on the specified repository to track changes and build them (/main branch by default).
• Branch specification (optional): TeamCity opens the possibility to track other branches' changes different than configured default branch, by entering inclusion / exclusion rules as described in TeamCity's "Working with feature branches" documentation page.

(In the example above, all child branches of /main branch will be tracked, excepting those child branches that start with Release string in their name).

Click on "Test connection" to check whether the plugin can connect to the configured Plastic SCM server, and if the test connection is successful, on "Create" button.

Configure checkout from VCS mode

TeamCity supports two different VCS checkout modes to download the contents to be built from Plastic SCM (plus the option to do not perform the VCS checkout automatically, and usually delegating this action to the project's "Build Steps" configuration phase by executing an user-defined script). We highly recommend the "Agent-Side checkout mode", already supported by Plastic SCM TeamCity plugin:

Customize your specific project settings (such as selecting an user-defined checkout directory or VCS labeling on successful build) and when done, click on "Save" button.

Configure build steps

This configuration depends on each specific project in order to trigger a build once the source code at a required version is downloaded.

Configure build trigger

This is the step that rules the way builds are triggered. In this example, we configure a VCS trigger so that builds are launched when TeamCity Server detects new changes in the tracked branches of the specified Plastic SCM repository configured in the previous step: "Configure VCS root for the Project".

Although feature branches are already tracked by TeamCity (as we did in "VCS root" configuration step), we can define which of them will cause TeamCity to trigger a build or not, by setting up a "Branch filter". With the configured branch filter in the example above, any tracked branch will trigger a build when a new change is detected.

And that's it, the TeamCity project is ready to watch changes in Plastic SCM repo and start building changes!

Continue below to see the plugin in action!

A basic build cycle tracking changes from Plastic SCM repo

TeamCity is now ready to track changes from the configured feature branches in a repository. Let's see how TeamCity starts triggering builds when VCS changes are detected through a basic development cycle as an example with an existing repo in a Plastic SCM server.

First of all, a developer submits (checks-in in Plastic jargon) new changes in the default tracked branch (in this case, /main branch). A couple of seconds later, TeamCity detects these new changes, checkouts source code from /main branch into the configured workspace folder (from "checkout options" step while configuring the VCS root of the TeamCity project), and starts executing the actions defined in "Build Steps" in order to perform a build:

Now, the same user (jesus in this example) creates a child branch in Plastic SCM (/main/scm78453) to perform a couple of changes in order to fix a bug in the code. As the new branch name matches with the "Branch specification" pattern for feature branches to be tracked, TeamCity will trigger a build when detects changes in this new branch:

As the build of the newly created child branch is successful, the integrator decides to merge back to the parent, default /main branch in Plastic SCM. When the merge in the /main branch is checked-in, TeamCity will trigger a build once it's detected. Let's see this new build ("#3") in the Change Log graph, along with the merge link:

The history in the VCS repository continues: a new branch (/main/scm81245) is created, some changes are submitted there, and then, this branch (along with the previous one) is merged into a release branch (/main/Release-792). After that, the release branch /main/Release-792 is also merged back to default /main branch. Let's see how TeamCity triggers new builds for changes in branch /main/scm81245 and /main, but not for the /main/Release-792 branch, as it matches with the configured exclusion pattern in the "Branch specification" defined when configuring the VCS root:

Let's see how the TeamCity's Change Log graph draws these new changes (blue dots) and corresponding builds (green dots).