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.

Encouraged by your feedback in UserVoice asking to add previews to dll files we would like to show you how to support the scenario by creating your own preview tool.

Add previews to dll files

Everything was green and working automatically while merging a feature branch to our latest release branch. In fact, I was about to meet my colleagues in the coffee room for a break, but... Ouch! A big red conflict involving a lot of lines appeared. At first glance, I have no idea what happened to the conflicting file. Cancel the coffee break? Hold on, not yet, not today!

Let me show you the steps I followed to solve a non-trivial merge conflict with Plastic SCM and have the feature branch integrate and checked-in into the release branch. For this purpose, I used some 2nd-class-citizen features in Plastic that definitively I have to promote to 1st class after this experience.

BL793 comes with another great feature for OS X users: now you can filter branches in the Branch Explorer! It is an added capability on top of the “inclusion/exclusion rules”. It works as follows: