As you know, we're extremely happy to announce that the Plastic SCM Server is now a DevOps orchestrator!

It can now coordinate information flows from/to your issue trackers, continuous integration systems, notification services and much more!

You can configure mergebots using our webadmin interface.

But today I'm going to explain how to configure the entire system using config files.

Recently I described how mergebots help implement DevOps from a conceptual point of view. Today, I'm going to explain what mergebots actually look like.

A mergebot automatically merges branches once they are correctly reviewed, validated and all tests pass. You can think of it as robotic automation for the integration process. It saves on costly context switches for developers (who no longer have to go and merge your branch, the bot does this with you) and automates most of the repetitive work of integrators and build-masters.

Activity last 7 days

Not sure if you noticed, but it's already been a few weeks since we released the new WebUI. We didn't make much noise about it so it has been almost in stealth mode all this time :-)

WebUI stands for "web user interface" (yep, not very original) and it is a web-based way to browse repositories, diff code and even perform code reviews.

We already had a WebUI before. The big difference is that this one comes embedded with the server, so you don't need to do a separate setup. You don't have to configure anything on IIS or Apache like you had to before. It was a real pain to properly configure it, and that's why we decided to get rid of it. The new one is started with the server, runs on the same process, so there's nothing to configure. You start your Plastic Server and the WebUI is there.

But, it is not jus the same old thing packaged differently. It is an entire rewrite that will serve as the basis for future development. And, it already includes a great new feature that you've never seen before on a web-based version control interface: semantic diff :-)

Semantic diff in WebUI

DevOps is now a pervasive concept in the software development arena. And, beyond the hype, we really believe in the idea of having a continuous flow of tasks (bugs, features, anything) correctly reviewed, tested, merged and deployed, is key for modern software creation (as of 2018).

But, while Plastic, as a version control system, plays a key role in the DevOps picture, we historically tended to remain "process agnostic". "Let teams find their path", we thought.

Now, we believe Plastic has to guide teams adopting best practices. We must make things easier and avoid leaving tough decisions as "exercise to the reader". (Which doesn't mean Plastic won't let you freely implement your own practices if you are an expert, but we'll provide guidance to newcomers).

This is the story of how we decided to automate the "integrator role" with mergebots, how we found a way to close the automation last mile, and how to make it way simpler for teams to integrate their Jenkins/Bamboos/TeamCities with Plastic, Slack, email and their favorite issue trackers.

This is about how Plastic will become proactive in terms of driving the workflow, pushing tasks forward and actively coordinating with CI instead of being just a source of information. Somehow, we decided to become accountable for it :-)

It is also about how we recommend our own formula of success for development: trunk-based development + short lived task branches + mergebots. And, how we coded it inside Plastic for teams to use it.

Sometimes users ask if it is possible to delete branches in Plastic. They want to get rid of them after the branch is merged because they are worried about polluting the repo with countless branches.

If you are a hard-core Plastic user you might think why someone would want to remove a branch with changesets on it. The reason is because these users have a very Git-centric view of version control.

So, if you are new to Plastic, and found this blogpost when trying to find how to "delete branches", I'm sorry to say the answer is NO, we don't delete… but for a reason :-)

We preserve history because it is great to do a diff, or a blame of a file, and find the branch where it was done, and the direct link to the associated task with all the extra info it contains.

We also preserve branches because… Plastic doesn't break with dozens of thousands of branches, not the core, nor the GUIs… unlike Git.

In the following topics, I'm going to explain the whys in detail.

I'm going to tell you the story behind Jet, our super-fast repo storage. Many of you have asked me if it was a good replacement for the SQL-based storage that we support, (It is!), and how we came up with a custom format. Well, here is the full story

It was a Wednesday in late August and I was on vacation. I exchanged some Slacks with the team back at the office during the morning. But, things got worse after lunch, so we jumped onto a call.

"There is definitely something broken. It seems it only happens after a week of very intense work, but performance in the database data layer definitely degrades at some point" – was part of the conversation on the phone.

"We are going to upgrade to the newest connector, because it seems like it is leaking something. We really need to move past this and have our own thing".

Having "our own thing" was something we talked about for years. And it was finally the time.

I love telling stories, so today besides making a few announcements, I'm going to share how we see version control working for games, and how our vision evolved by working side-by-side with studios.

Announcement first: Plastic Gluon, the UI and workflow designed for artists in game development, can now merge files.

We released it last week as part of and it is a major change in the Gluon feature set.

Like every story in software development, I'm going to share what we tried first, and how our vision and understanding was shaped by constant user interaction.

I will explain the why's of this decision and how it fits into our overall version control strategy for game development.