How to integrate Plastic SCM with TeamCity CI server

Installation

The Plastic SCM Team City plugin extends the capabilities of the TeamCity server, enabling it to manage continuous integration operations using source data that is under Plastic SCM control.

To install the Plastic SCM Team City plugin:

  1. 01. Download the Plastic SCM plugin for TeamCity .zip file.
  2. 02. Open “Plugins list” from TeamCity’s Administration menu
  3. 03. Click on “Upload plugin zip” and select the recently downloaded .zip file in the dialog that pops up.
    Changing the user identity
  4. 04. Restart TeamCity Server. This way, the plugin will be automatically unpacked and loaded.
  5. 05. (Windows systems only) The plug-in runs Plastic SCM commands with the user identity of the TeamCity Build Agent Service (Agent-side checkout mode). By default, this identity is the SYSTEM user account. We recommend changing this service’s user account to a different one:
    1. 05.1. Go to Control Panel > Administrative Tools > Services.
    2. 05.2. Right-click TeamCity Build Agent Service and select Properties.
    3. 05.3. Go to the “Log On” tab and select another user who already has a valid Plastic SCM configuration.
      Changing the user identity
  6. 06. Start the TeamCity Server service.

Configuration

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.

Changing the user identity

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.

Changing the user identity

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.
Changing the user identity

(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.

Changing the user identity

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:

Changing the user identity

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.

Changing the user identity

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”.

Changing the user identity

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:

Changing the user identity

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:

Changing the user identity

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:

Changing the user identity

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:

Changing the user identity

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

Changing the user identity

Get the latest news