Códice has been around since 2005, when we decided we wanted to create a better version control system. Since then, we have created Plastic SCM, a solid version control system that many teams of all sizes around the world pay to use. And it is important to note that they had many options to simply grab a version control system without having to pay a dime, but they opted to purchase our software, and keep us in business.

Well, today, I'm writing down the list of all the software components we develop, just to share with the team and users, the scope of the products we make here at Códice Software.

Pull requests are broken. Ever experienced that? Take a branch with only 3 small changes and it will get a whole lot of comments and suggestions. Take one with +100 changed files and it will get none.

Broken.

Is there a fix for this? We believe there is. What if every checkin was done with reviewers in mind? What if we take the approach that "checkins must be created for people to review, only incidentally for authors to deliver their work"?

A little bit of background

Yesterday, I was writing a short guide on how we work for a new developer joining the team. Some sort of "how to use Códice Software" inspired on readings like Basecamp's Handbook and the "how to work with me" guide described in High Growth Handbook.

Then, I was about to write down our oral tradition on how to "work on task branches". And I realized that... well, it would deserve a blogpost. So, here I am.

We treat checkins very carefully, and I'm going to explain the secret sauce we cooked up for really great checkins that lie at the heart of task branches.

We designed our DevOps ecosystem for Plastic SCM with versatility in mind. All functionality is provided by separate pieces of software, each one with a specific purpose: plugs to perform actions and mergebots to orchestrate the process. In this guide, we'll be looking at the mergebots and their general structure so you can implement your own!

What is a mergebot?

We define a mergebot as an independent program that connects to a Plastic SCM server through WebSockets, where it registers itself and stands by for the event notifications that Plastic SCM emits.

The main goal of a mergebot is to effectively lead the integration process in an event-driven way. It can (and should) make use of the available plugs to perform the necessary checks and actions to implement the integration that suits your teams development methodology.

A great example of a mergebot is our TrunkBot, a mergebot that enforces Trunk-Based Development in a Plastic SCM repository. You can take a look at its source code in our GitHub repository.

Mergebot types

Our DevOps ecosystem was designed with versatility in mind. All functionality is provided by separate pieces of software, each one with a specific purpose: plugs to perform actions, mergebots to orchestrate the process. In this guide we'll be looking at the plugs and their general structure so you can implement your own!

What is a plug?

We define a plug as an independent program that connects to a Plastic SCM Server through WebSockets, where it registers itself and provides a generic interface to perform actions in systems external to Plastic SCM. Those include Issue Tracking systems, Continuous Integration systems and Messaging systems.

Real life examples of plug actions range from setting an issue as Done in your issue tracker or triggering a build in a CI server to sending an email to the QA team when a task is ready to be tested.

Some time ago we introduced both the WebAdmin and the WebUI. The first one is the Plastic SCM's server administration and monitoring web panel, while the second is a nice web interface to browse repository content (including code reviews and even semantic diffing!) For now, both interfaces lack SSL.

By the end of the post, you should be able to browse the WebAdmin using HTTPS, as shown here

Our friend trx contributed in our forum with a quick guide on how to add SSL to the WebAdmin and WebUI using NGINX. In this blogpost, I'll walk you through an extended version of trx's guide, covering how to customize the WebAdmin's default port, install NGINX, generate a self-signed certificate (in case you don't want to invest in buying one from a trusted CA), and configuring NGINX to act as a reverse proxy for the Plastic SCM's WebAdmin and WebUI web interfaces, adding SSL support to them.

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