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.

To deploy versus to release

Monday, April 10, 2017 Pablo Santos 1 Comments

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.

To deploy versus to release

This is something interesting and worth considering, especially for non-native English speakers like me.

You can deploy a new feature without releasing it.

Yes, you can put your new version in production, but it can be disabled, waiting to be released.

The DevOps "handbook" explains it better, but you get the point.

And the important thing is: yes, deploy as much as you can, but you control releases. Usually, release will happen at deploy time, but in very "trunk-based development fashion", sometimes you will hold the release to start unveiling it only to certain users. Very web-like, but also doable for on premise servers and even desktop apps.

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.

Pablo Santos

1 comment:

  1. UnknownMay 1, 2017 at 1:10 AM

    That's very true, and most teams handle release dates and use a code to cypher major, minor, build number and so forth but the final customer only perceives the changes when they are actually released, and that's kind of a management (or sales) decision.

    IMHO, the important thing for us, technicians is: deploy, more than release. When it's about a product and not a custom-made software we could distinguish between public and private releases to see the difference between deploy and release. D'you agree?

    ReplyDelete

Subscribe to: Post Comments (Atom)