Who we are
We are the developers of
Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can
find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.
If you want to give it a try, download it from
here.
We also code
SemanticMerge, and the
gmaster Git client.
All the software we write
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.
Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code.
You can reach me at
@psluaces.
Who we are
We are the developers of
Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can
find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.
If you want to give it a try, download it from
here.
We also code
SemanticMerge, and the
gmaster Git client.
Checkin with reviewers in mind: how to speed up code reviews
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.
Pablo Santos
I'm the CTO and Founder at Códice.
I've been leading Plastic SCM since 2005. My passion is helping teams work better through version control.
I had the opportunity to see teams from many different industries at work while I helped them improving their version control practices.
I really enjoy teaching (I've been a University professor for 6+ years) and sharing my experience in talks and articles.
And I love simple code.
You can reach me at
@psluaces.
Who we are
We are the developers of
Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can
find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.
If you want to give it a try, download it from
here.
We also code
SemanticMerge, and the
gmaster Git client.
Plastic SCM DevOps: Custom mergebots
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
Miguel González
Prior to become a Plastic hard-core developer, I worked in a consulting firm in France where I also finished his Computing Engineering master's degree.
I'm a Linux enthusiast (I was the one developing the Plastic SCM linux packages), heavy-metal guitar player on a band, LP collector, youtube expert and talented Plastic hacker.
You can find me at
@TheRealMig_El.
Who we are
We are the developers of
Plastic SCM, a full version control stack (not a Git variant). We work on the strongest branching and merging you can
find, and a core that doesn't cringe with huge binaries and repos. We also develop the GUIs, mergetools and everything needed to give you the full version control stack.
If you want to give it a try, download it from
here.
We also code
SemanticMerge, and the
gmaster Git client.
Plastic SCM DevOps: Custom plugs
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.
Miguel González
Prior to become a Plastic hard-core developer, I worked in a consulting firm in France where I also finished his Computing Engineering master's degree.
I'm a Linux enthusiast (I was the one developing the Plastic SCM linux packages), heavy-metal guitar player on a band, LP collector, youtube expert and talented Plastic hacker.
You can find me at
@TheRealMig_El.
0 comentarios: