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.
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.
After creating the Project, TeamCity wizard asks for a Build Configuration. Again, enter a valid name, ID and description and click “Create” button.
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:
(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.
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.
This configuration depends on each specific project in order to trigger a build once the source code at a required version is downloaded.
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!
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).