Game developers are close to 25% of Plastic SCM users today. That's why we went again to the Game Developers Conference in San Francisco, March 21st-23rd, to meet many customers, and of course many new interested ones.
Plastic SCM at GDC

If you have been using Plastic for a while, you probably know what "merge-to" is and when it is useful. Well, we just made it better; it now supports full conflict resolution! With GUI support for Linux, OS X and Windows available.

Merge-to feature

Super quick intro to merge-to

Regular merges happen like this: you switch your workspace to the destination (where you want the merge to go) and then you merge from source (what you want to merge from).

Internally we tend to call it "merge-from".

Merge contributors

Well then, what is merge-to?

UPDATE 2018/04/04: We included a link to a webinar about DevOps with Atlassian Bamboo, Plastic SCM and Jira

To implement a full DevOps strategy, it is crucial to fully automate the testing and merging of each task branch. Automation is the way to achieve faster delivery of tasks required to fully implement DevOps.

I explained a recommended DevOps cycle and how to implement it with Atlassian Bamboo and Plastic in two previous blogposts.

Now, I'm going to cover how to fine tune the process by introducing Jira into the equation. What if Bamboo requires a given Jira task status to test and merge the associated task? What if the testing and merging process is reflected back onto the Jira task status? This is exactly what we released in 7.0.16.2063 and what I'm going to explain in detail in this post.

How pieces fit

UPDATE 2018/03/22: Added section "Update branch attributes".

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.

Cycle

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 systems 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).