DevOps is all about breaking silos and making production and development cooperate to deploy a continuous flow of stable changes to production.

In the previous blogpost, DevOps Primer, I explained the basics of what DevOps is and our vision on how to implement it with Plastic SCM.

This blogpost will start where the last one ended and will cover how to implement a full DevOps cycle using both Atlassian's Bamboo and Plastic SCM.


I will delve into the details of how to handle task branches with Plastic and then run tests, merge and deploy using Bamboo with the Plastic Plugin. The entire cycle is based on the Bamboo Gatekeeper feature using Plastic attributes that are set to branches to decide when a branch is ready to be merged.

My goal is to start a series of blogposts explaining how to implement a true DevOps cycle with Plastic SCM and the main CI system we integrate with — Bamboo, Jenkins and TeamCity.

But, prior to jumping into the specifics of each tool, I'd like to describe better what DevOps is, and how we envision the actual cycle every task must go through.

DevOps is all about breaking the production and development silos by delivering a continuous flow of stable changes to production.

Achieving stability means every task must go through enough checks to ensure nothing is broken before entering the main branch. Thus, every change merged-to-main is a potential new release.

Task cycle

While we invest lots of efforts improving our built-in diff, semantic diff and the graphical merge tools, there are times where you really need to run a diff in a terminal.

How can you configure unix diff to be your diff tool?

Mike is working on the main branch and has some changed files that are ready to checkin. Bob and Joe are also working on main. When Mike is about to checkin, Plastic asks him to update his workspace first. Mike goes nuts. He didn't have to do this with Perforce. Why is Plastic forcing him to work this way?

Short answer: Mike, if you want to work this way (SVN/Perforce style), please use Plastic Gluon :-P. It comes with Plastic, has no extra cost, but supports a different workflow. It is perfect for working with non-mergeable files (art, docs, blogposts...).

Long answer: it is all about merge-tracking. If you want to look under the hood of version control then keep reading. I will explain why Git, Mercurial and Plastic SCM implement per-changeset merge tracking instead of per-file merge tracking like older systems used to do (P4, Clearcase, SVN).

External tool actions have been around since release, thanks to some of you asking for them.

You can create custom actions to run on selected objects such as labels, changesets, branches, and items, and invoke those custom actions directly from Plastic SCM.

External tool actions - Branches

Add custom actions to branches and files

Okay, this is a little bit difficult to understand without an example, so I'm going to teach you how to implement two different actions: one for branches, and one for items. I'll let you tinker around with action for labels and changesets on your own, but it is just as easy. Remember, this feature is available on Windows, macOS, and GNU/Linux, but only in the regular Plastic SCM client, and not in Gluon.

For the action to a branch, I'm going to add a custom action to directly apply an attribute to the branch. This is instead of the alternative of having to navigate to attributes, then selecting the attribute I want to apply, and then looking for the value, which is a real hassle if you do this a lot, like we do.

For the action to an item, I'm going to add a custom action to directly open that item in Visual Studio Code.

Ready? Ok, let's go.

Having local repos (working distributed) is great: super-fast checkins, speed-of-light branch creation... nothing breaks the flow. In contrast, slow checkins to a remote server simply get on my nerves and drive me directly to productivity-killing time filling like checking conversations and forums on Slack.

Super big local repos with tons of history I never actually use are not good, though. Yeah, disk is cheap and all that, but 20GB local repos drive me crazy.

And, I'm connected to the internet while I code 99.9% of the time. Cant I just have lighter clones and grab the data from the central server on demand?

We have just introduced nodata replication. You only get the metadata and data is downloaded on demand from the central server.


We have just released a new cross-platform (web-based) admin tool to configure and monitor the Plastic SCM server. We call it webadmin and it is included in release