November Happy Hour will be moved to Thursday December 5th.

Quan Mai
Oct 4, 2014
  2275
(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
Adding Geolocation Personalisation to Optimizely CMS with Cloudflare

Enhance your Optimizely CMS personalisation by integrating Cloudflare's geolocation headers. Learn how my Cloudflare Geo-location Criteria package...

Andy Blyth | Nov 26, 2024 | Syndicated blog

Optimizely SaaS CMS + Coveo Search Page

Short on time but need a listing feature with filters, pagination, and sorting? Create a fully functional Coveo-powered search page driven by data...

Damian Smutek | Nov 21, 2024 | Syndicated blog

Optimizely SaaS CMS DAM Picker (Interim)

Simplify your Optimizely SaaS CMS workflow with the Interim DAM Picker Chrome extension. Seamlessly integrate your DAM system, streamlining asset...

Andy Blyth | Nov 21, 2024 | Syndicated blog

Optimizely CMS Roadmap

Explore Optimizely CMS's latest roadmap, packed with developer-focused updates. From SaaS speed to Visual Builder enhancements, developer tooling...

Andy Blyth | Nov 21, 2024 | Syndicated blog

Set Default Culture in Optimizely CMS 12

Take control over culture-specific operations like date and time formatting.

Tomas Hensrud Gulla | Nov 15, 2024 | Syndicated blog

I'm running Optimizely CMS on .NET 9!

It works 🎉

Tomas Hensrud Gulla | Nov 12, 2024 | Syndicated blog