On April 4th, I presented the webinar, “Git for the Enterprise – Promises and Pitfalls.” In the session, I talked about how CollabNet TeamForge remedies concerns for enterprises looking to adopt Git, the leading distributed version control system.
Specifically, I covered:
- Why Git is vital for Enterprise Cloud Development strategies
- What the top Git adoption challenges are for enterprises
- How CollabNet TeamForge enterprise-readies Git
During the webinar, we encouraged our attendees to interact with us by participating in polls and by entering questions for the live Q&A session that we had at the end of the presentation. As a result, we received many great questions that we just couldn’t get to during the live event so we have provided answers to the audience’s questions below.
Don’t forget to register for our upcoming webinars. CollabNet offers multiple webinars a month that cover a variety of topics related to software development.
As promised, here’s the follow up to the live audience questions.
Q: How to approach the situation when you have all developers and testers barely trained into subversion and working with branches? How to pitch the DVCS principle to a development org that does not know it needs it?
A: I’d start by making sure I identified the business problem that DVCS is going to solve. It may be that there is no compelling reason for an organization to change. I’d really want to understand the current problems in the environment. If folks are struggling with branching and merging on SVN, then Git *may* be good answer. However if the root problem is a fundamentally flawed workflow, or lack of understanding around the “hows and whys” of branching strategy, then Git may just make things worse. It might be that training is your foundational issue; if it is, then changing tools may not be the right move. I’m painfully aware that this is a short answer to a complex question. Feel free to get in touch, and we can discuss in more detail: www.collab.net/gotgit
Q: Any thoughts / comparisons between CollabNet and Cloudbees?
A: They are actually a partner of ours (through CollabNet Cloud Services, Codesion) Here is some info about our partnership.
Q: How will you help us to migrate from Subversion on CollabNet?
A: CollabNet will be happy to help with a full range of migration services and training as needed. Take a look at www.collab.net/gotgit
Q: When Git will be available to use in CollabNet?
A: Available now! www.collab.net/gotgit
Q: Will it be possible to have custom server hooks?
A: Yes. As always, make sure that your hooks scale with your activity. I’ve been involved in more than one SCM performance issue on a variety of different platforms – where the problem tracked back to hook scripts. If you’re using a hosted service then the ops team who guarantees your SLA will definitely have an opinion on server hook.
Q: Git challenge: Lack of UI front-end for merge operations. Thoughts?
A: Git ships with Git gui. See, http://linux.die.net/man/1/git-gui. It’s basic, but does a good enough job of visualizing branches and runs across all platforms. Based on the number of projects you can find when you search for “Git UI,” I think it’s fair to say there is no clear winner yet in this space.
Q: I realized we already use TeamForge for arbitrary projects, but the product I’m on is still using clearcase. We want to migrate to Git, could TeamForge help with that?
A: Absolutely. Git has rich support for branching and merging and it’s fairly straight forward to map ClearCase branching strategies to Git. The migration is probably a good time to take a look at how you’ve been managing your branches and replication strategies. Some of the concepts such as Branch Mastership, no longer apply. The initial thought is often to move all history and I’d think long and hard before doing that. As a rough rule of thumb, I would move history of code that you have worked on in the last 6-12 months at most. CollabNet Teamforge is the right place to host your Master (or integration) servers and can really simplify setting up your security and code review processes (just two simple examples).
Q: I’m interested in how to migrate subversion based continuous integration workflow to a Git based one. Do you have any further information about this?
A: In theory, it should be pretty straight forward. The Git SVN clone command will import a full SVN repo into a Git repo. From there, you need to modify your build scripts to pull from the new repo. If you’re using Hudson/Jenkins, install and configure the Git plugin, and away you go. The bigger challenge may be associated with ensuring that the Git repo you are pulling from is the true “master”. Git workflows can get very complicated and ad hoc if not carefully tended.
Q: Does git alter the price of TeamForge? That is, is it an add-on?
A: There is a license option for the Git adapter, and related support. Please discuss with your CollabNet account manager, or contact us at firstname.lastname@example.org.
Q: Does TeamForge work well on Linux (both for server and for workstations)?
A: Yes. As always, make sure you scale up your resources, CPU, disc, memory, bandwidth etc. as you grow. Alternatively, let us worry about resource scaling for you, and consider a CollabNet hosted solution.
Q: What about other DVCS like bazaar, mercurial, AccuRev? Is integration with them considered in TeamForge?
A: We’re concentrating on Git at the moment as that’s where we see the most interest from our customers. If you have specific interest in other integrations I’d be very happy to learn more about your needs. www.collab.net/gotgit
Q: How to use Git with tools designed for code review?
A: The CollabNet TeamForge Git solution includes the Gerrit code review tool.
Q: How to use Git on continuous build server?
A: You can use Git in just the same way as any other SCM. The challenge is making sure you’re building the right code. If you’re coming from a single stable trunk workflow this might be a surprise. If you’re coming from an integration/promotion-workflow then it shouldn’t be that foreign.
Q: Do you recommend hybrid Git DVCS with central version management system (e.g. Perforce) serving as central repository?
A: Interesting question. I have been recommending the opposite approach. Have Git as your master Software Configuration Management tool and allow local teams to continue to use Perforce as needed. In general, I’m not a big fan of hybrids for long term production needs. They are great as transition plays, but in long term production they tend to be brittle with associated flame wars and finger pointing.
Q: Are many high-end customers actually using Git?
A: I meet a lot of Enterprise businesses as part of my role here at CollabNet. I have yet to meet a single Enterprise customer who isn’t either officially supporting Git – or worrying about how to manage the shadow Git environment being built by the developers.
Q: How do you manage windows support/differences comp with Linux and mac with respect to line endings, tools terminal functionality etc.
A: http://progit.org/book/ch7-1.html has a good discussion of the Git config options. You’re looking for core.autocrlf. It’s worth running a few tests to make sure that you’re getting the workflow that you’re expecting. Managing cross-platform CRLF issues can be a painful experience.
Q: Any concerns about Security and IP theft with the ability to have local repos?
A: There are some additional concerns to consider – I’m not sure they are an order of magnitude worse than the security concerns we should already have. I’ve seen a lot of workflows with a lot of version control systems. The default workflow a lot of folks adopt is, to check it all out to the workspace on the desktop. Even when you have the ability to do sparse checkouts of just a few files, it’s often not used.
I always assume the worst case, which is not a bad position to start from with security concerns. At a minimum, I worry about attached storage – flash drives, iPods etc. and theft/loss of mobile devices. A lot of us code on laptops these days. At a minimum, we should encrypt the hard drive. As for flash storage, that is a tricky one. Most companies are loath to impose a ban on our favorite music players, smart phones etc.
Git can make it harder to figure out where all your code is. It’s very, very easy to clone a repo and without good workflow you can end up with your code in some unexpected places. On the positive side, Git can make it much easier to segment your code base into “need to know” branches.
Q: Do you integrate with VersionOne?
A: Our Codesion Cloud Services has integrations into VersionOne: http://codesion.com/
Q: What is ALM
A: ALM: Application Lifecycle Management http://www.collab.net/products/ctf/
Q: How is TeamForge a better option over GitHub?
A: TeamForge has been built with the enterprise in mind, versus just individual workgroups. As such, TeamForge does provide cross-workgroup transparency and manageability, natively full application lifecycle management functionality, deep integration with 3rd party tools, and (last but not least) enterprise-grade 24/7 support. All this is provided at cost-effective price points for the enterprise, hosted or on-premises.
Q: Do you actually mean that in a distributed version control system there are no standard ways to impose who can change which parts of the source tree?
A: DVCS has security just like any other Version Control System. Properly implemented, this prevents people from making unwanted changes. The big difference with DVCS is the clone command. If you permit me to clone your Repo, then at that point in time, I now have a complete copy of the repo. I can make whatever changes I want. If you then permit, I can push changes back up to your repo. The worrying scenario is the so-called “hostile fork”. I get a copy of your repo; I then make whatever changes I want in my repo, and then advertise my repo as the new master.