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

So far, we shared how we do DevOps and Trunk Based Development using Plastic SCM and a set of tools around it. But I wanted to make the blogposts short, so I left lots of notes and explanation intentionally out for the sake of brevity.

In this 5th blogpost in the series, I will cover why automated testing is so important for us, but also 2 other practices we adopted long ago: code review and explore test each task.

In this blog post we will explain how you can easily analyze your Plastic SCM Server logs to get very useful information of our server behavior and identify potential issues.

The Plastic SCM installation provides a tool (plasticlogstats.exe) that is able to parse your server logs and generate detailed reports.

We have reached the 4th installment of the series telling how we implement trunk-based development at Codice today. Previously, we covered:

Today, we will answer some common questions that were not covered before. So far, we just described the ideal cycle, but never told you what happens if tests fail, the various reasons why a task/branch can be rejected, what to do when a branch can’t be merged or how to handle broken builds. These are the topics we cover today.

This is the third installment in the series of blogposts telling how we develop Plastic SCM. In the first two posts, we covered what our new working cycle looks like once we moved to trunk based development and then we gave a brief overview of the meaning of release versus deploy.

In this third blog post, we will be looking back and filling in some gaps. What exactly is trunk-based development and how does it blend with task branches?

If you read our previous blogpost about how we do trunk based development with Plastic SCM, you probably have a few unanswered questions.

This blogpost is the second in the series and covers something we find interesting: the difference between deploying and releasing.

For years, we praised the benefits of branch per task: a new branch for each task in your issue tracker, lasting only a maximum of 2 days (and better just a few hours), and one single developer per branch. This is how we used it and we really preferred this to mainline, even despite of Continuous Integration (CI).

But we started singing that song more than 10 years ago, and many things have changed since. What's new today? Does branch per task still work? Does it blend at all with new practices such as DevOps and Trunk Based Development?

These are the questions we are going to answer in a series of blogposts, during which we explain how we use Plastic ourselves in "eat your own dog food" fashion.