Plugin for Team City

Installation

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

To install the UVCS Team City plugin:

  1. Open "Plugins list" from TeamCity's Administration menu.

  2. Click the "Upload plugin zip" link. Changing the user identity

  3. Upload the UVCS plugin for TeamCity: <UVCS installation directory>/client/plugins/teamcity/com.codicesoftware.plugins.teamcity.PlasticSCM.zip

  4. Restart TeamCity Server. This way, the plugin will be automatically unpacked and loaded.

  5. (Windows systems only) The plug-in runs UVCS 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. Go to Control Panel > Administrative Tools > Services.

    2. Right-click TeamCity Build Agent Service and select Properties.

    3. Go to the "Log On" tab and select another user who already has a valid UVCS configuration.

      Changing the user identity

  6. 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 UVCS 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 UVCS.

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

The specific fields for UVCS plugin are the following:

  • Server: location of UVCS server (IP / name:port).
  • Repository: the UVCS 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.

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 UVCS 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 UVCS (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 UVCS 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 UVCS 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 UVCS repo and start building changes!

A basic build cycle tracking changes from UVCS 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 UVCS server.

First of all, a developer submits (checks-in in UVCS 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 UVCS (/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 UVCS. 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