Q&A unanswered questions
During the webinar, we couldn’t get to all of the awesome questions in the Q&A session. For both those that were and were not able to attend, here is a wrap up of the unanswered questions. If you have any more questions, throw them in the comments section.
Q1: How will pricing for Stash Data Center compare to the cost for ‘normal’ Stash?
A1: Stash Data Center is based on 1,000 user tiers, not per node pricing. It is subscription based pricing that costs $24,000 per 1,000 user tiers. Stash pricing is an upfront cost based on user tiers. To learn more, check out the Stash Pricing Page.
Q2: Does every developer need to create a separate branch, or can all developers work in the same branch? Also, will there be a single repository for single applications, or different repositories for all developers?
A2 part 1: Multiple developers can work on the same branch if they are concurrently working on the same feature. This makes it a lot easier for developers to share and update their current snapshots of the branch.
A2 part 2: There should always be a single source-of-truth repository. If you’re using a Forking workflow, there will also be a repository for each developer. Otherwise, there will only be the origin repo and its clones.
Q3: Do you have plans to support migration tools? I’m interested in Perforce-to-Git migration tools other than git-p4.
A3: We don’t have any short term plans to build out additional SCM migration tools. We recommend posting your question to our forums at Atlassian Answers to see if any other Stash users have some advice on a Perforce to Git migration. We can also recommend one of our Atlassian Experts with Perforce==>Git experience for hands-on assistance.
Q4: I’m interested in hearing how you would handle multiple releases in terms of a workflow.
A4: We would create a release branch for each product involved. It would be best, however, to use a different repo for each product.
Q5: How is Git branching better than SVN using feature-branches?
A5: In Git, there’s an actual notion of a branch that is orthogonal to the object tree, and is treated as a first-class citizen in the interface (command line, Sourcetree, Bitbucket, Stash). This also means that they are easy to find and analyze in the DAG. In SVN, you’re hacking a few folders and pretending like it’s a branch, but both coexist in your local file tree. This is unnecessarily confusing.
Q6: What are the recommended approaches to backing up Stash repositories?
A6: Stash offers two different types of backup mechanisms, the Stash backup client and DIY backup. To get an understanding of which one would best fit your environment, see Data recovery and backups.
Q7: Currently, we’re using TFS and are planning to migrate to Git but would like documentation on how to get started. If any documentation exists on Git migration from TFS that would be helpful.
A7: At the moment, we don’t have any white papers or best practice guides regarding a TFS-to-Git migration. We recommend posting your question to our forums at Atlassian Answers to see if any other Stash users have some advice. We can also recommend one of our Atlassian Experts with TFS==>Git experience for hands-on assistance.
Q8: Do you suggest file system replication at the bottom of Stash Data Center?
A8: Absolutely. When possible, we recommend implementing a highly-available model for all systems in contact with Stash Data Center, i.e. database, file system, and load balancer. Most of these systems offer their own HA functionality, which can be used alongside Stash Data Center.
Q9: What are the recommendations for sizing out Stash/Git repos as they grow in size?
A9: This can be impacted by a number of different variables, which is why it is tough to make suggestions that will fit every team’s needs. We have done our best to gather baseline recommendations in our Scaling Stash guide. You might also consider posting this to our Atlassian Answers forum to see if any other Stash users have any advice.
Try Stash