Quan Mai
Oct 4, 2014
  2245
(0 votes)

Stash–9 months later

As you all know, from the end of 2013, we switched to nuget packages approach, which allow us to roll updates more often than the old msi installation before. The source version control system we had been using for years – TFS – had trouble supporting that, especially for branching – the most important part of continuous releases. We decided to switch to Git, which Stash as the central management service. I want to share my personal experience with Stash, nine months later, which the hope it will help you to evaluate if you have plan to use it.

Disclaimer: I’m no Stash expert, so my view might be limited, or I don’t know a better solution. If you see a mistake in this post, please point out.

The good parts

The most known feature of Stash, might be that it support cross team collaboration greatly. In EPiServer, we have multiple development teams across the world, then Stash solves a problem TFS failed to do: remote collaboration. For some tasks (either bug or feature) which are complicated enough for us to involve people from teams, TFS failed hard because it provide no way to easily see the changes, to add comments or to update to reflect comments. Stash, in other hand, solves this easily. By creating a pull request and tag a teammate who we think should be involved, the review step is smooth as silk! We can comment to point out a code we think has “problem”, or asking a question we are not so sure. Then we can reply, answer, clarify … It works so well that something I don’t feel like we’re remote teams anymore. For collaboration, Stash is that good.

But the best thing with Stash is that someone which has not been involving in the coding, can join the discussion. I like this part the most. When you’re pair programming, or you review other code by adding comments, suggestions, by some mean, their code become your code. In most case, it works, but it has a potential dangerous that you forget the big picture when you’re too focusing to the details. When another one with fresh eyes join in, they might not think as you think. Their ideas might be more creative and not be constrained by given perception. Yes. The creativity we’ve dreamed about is here. Or even if they don’t have new ideas, it’s good piece of knowledge sharing. There’s no individual code, but team’s code!

Another good part of Stash is it’s really easy to see the changes for given task. In TFS, we need to go through files, and for each file, right click, and then choose “Compare to previous version”. So boring! By using Stash, it’s only click and click. And we recently updated to Stash 3.3, which allows us to choose between diff and side-by-side compare. Awesome!

The bad parts

Stash is great. But it’s not perfect. I would like to name this section as “The not-so-good parts” instead, but let’s keep it for fun.

We still keep TFS as the work items system. All of our bugs, test cases, user stories belong there. And we yet to get Stash work nicely with TFS. Yes, we get them to work together, by some hacks. Every commit need to tag with the ID of work item, in the commit message, for example #123456. And with certain build, we will link the commit with the work item tagged in comment. Although it’s not as good as TFS integration, but it works at some level. The bad thing is it’s easy to forget the id tag, or worse, tag the wrong one. If this is spotted early, it can be easily fixed by a amend commit. But if it got through the review and appear in mainstream – we usual have to add/remove links to commits manually. Rewriting history in public branches is just too dangerous. For its natural, TFS is still better in this field.

The second not so good part is the build gate. When we were using TFS, we set up gates on project, to make sure we (almost) always get the green build before anything being checked in. There’s no option like that in Stash. We configure Stash to only allow merging if the branch has at least one green build, but it’s far from gating builds we had with TFS – even with the great help from TeamCity.

Overall, I like Stash. It have some killing features which we love to use it every day. It might not be perfect, but it seems to be the best version control system out there. It’s fast, it can be branched in no time (thanks to Git), and it embraces the remote collaboration which is invaluable to us. It has some drawbacks compared to one “Complete TFS solution”, but can be somehow, resolved.

If you have teams across locations, it might be a great idea to switch to Stash, if you haven’t already done!

Oct 04, 2014

Comments

Please login to comment.
Latest blogs
Optimizely SaaS CMS Content Types

In Optimizely CMS, there are many base content types you can define through code, such as component, image, video, folder, and sections. But today,...

Patrick Lam | Jul 29, 2024

Opti ID overview

Opti ID allows you to log in once and switch between Optimizely products using Okta, Entra ID, or a local account. You can also manage all your use...

K Khan | Jul 26, 2024

Getting Started with Optimizely SaaS using Next.js Starter App - Extend a component - Part 3

This is the final part of our Optimizely SaaS CMS proof-of-concept (POC) blog series. In this post, we'll dive into extending a component within th...

Raghavendra Murthy | Jul 23, 2024 | Syndicated blog

Optimizely Graph – Faceting with Geta Categories

Overview As Optimizely Graph (and Content Cloud SaaS) makes its global debut, it is known that there are going to be some bugs and quirks. One of t...

Eric Markson | Jul 22, 2024 | Syndicated blog