Quan Mai
Oct 4, 2014
(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


Please login to comment.
Latest blogs
Optimizely community meetup - Sept 29 (virtual + Melbourne)

Super excited to be presenting this Thursday the 29th of September at the Optimizely community meetup. For the full details and RSVP's see the...

Ynze | Sep 27, 2022 | Syndicated blog

Preview multiple Visitor Groups directly while browsing your Optimizely site

Visitor groups are great - it's an easy way to add personalization towards market segments to your site. But it does come with it's own set of...

Allan Thraen | Sep 26, 2022 | Syndicated blog

The Report Center is finally back in Optimizely CMS 12

With Episerver.CMS.UI 12.12.0 the Report Center is finally re-introduced in the core product.

Tomas Hensrud Gulla | Sep 26, 2022 | Syndicated blog

Dynamic Route in ASP.NET Core When MapDynamicControllerRoute Does Not Work

Background Creating one of the add-on for Optimizely I had to deal with challenge to register dynamically route for the API controller. Dynamic rou...

valdis | Sep 25, 2022 | Syndicated blog

404 Error on Static Assets Within an Optimizely plugin

Background With the move to CMS 12 and .NET 5/6, developers are now able to build Plugins and Extensions using Razor Class Libraries (RCL).  These...

Mark Stott | Sep 23, 2022

How to bypass the content creation view in Optimizely

Something that has come up a couple of times in the last few year is feedback from content editors about the editing view that comes up when creati...

Ynze | Sep 23, 2022 | Syndicated blog