Posts Tagged ‘integration’

Why Would Anyone use Git in their Enterprise?

January 26th, 2012 by thinds

The secret’s out – AccuRev is releasing a seamless security and compliance related solution for the Git community called Kando on January 31st. To get a first look at Kando, register here for the webinar on 1/31/2012, at 1:00 PM EST.

You might be asking yourself, “Why in the world would a company focused on providing software development tools to enterprise organizations with mission-critical software development environments produce a solution for an open source version control tool?” I’ll tell you!

Git is increasing in popularity among developers working in small groups or collaborating on open source projects. It’s fast, flexible, and full of developer-friendly features. Git is a great tool for these smaller and more social types of development projects, and based on discussions about Git with customers, prospects, and analysts, it’s clear that there are more cases of enterprise organizations trying to use Git.

But poke around a few blogs, or read a few articles that discuss the use of Git in an enterprise environment, and I’m sorry, but you will uncover a few issues. As one article in BCW discussed, “Git is a version control system with an attitude of collaboration and sharing. There is practically no way you can enforce a specific pattern of access and sharing. If the people who’re using Git don’t want to follow your rules, the tool is not going to help you much.” Let’s be realistic – Linus didn’t originally design Git for use in an enterprise environment!

So, in which cases do enterprise organizations actually use Git?

1. Android Development

If you want to make changes to Android, you’re going to need Git. It’s unavoidable. This means any company creating mobile devices running on Android and working with Android source files has a real business need to use Git.

2. Linux Development

Same as with Android, if your company has a need to make changes to the the Linux kernel, you are going to need Git. Even if you don’t use Git when making those changes, you’ll eventually have to get them into Git.

3. Working with 3rd Party Vendors or Outsourced Teams Using Git

Similar to the Android and Linux situation, if you’re working with 3rd party vendors or outsourced teams who require that you merge your changes into their Git repository, you may be forced to use scripts or bridges to get your changes from your SCM into Git or vice versa, and that’s not a small task.

4. All of Your Developers Love Git

Let’s face it – Git has a cult-like following in the development community. Developers love Git because it’s fast, distributed, flexible, fairly easy to learn, and has a ton of developer-friendly features. It’s developed by developers for developers. Even if you understand the issues Git has with scaling in enterprise environments, it’s difficult to avoid Git when lots of your developers are pushing you to switch.

 

Don’t Tell Anyone I Switched to a Mac for my Agile Planning

May 28th, 2010 by brad hart

How did it come to this?  I still can’t believe it myself.  I started as an Intel + MS-DOS guy (was I the only one that was thrilled when DOS 6.22 was released??).  My first deviation from the Intel / Microsoft platform was Solaris, strictly via the shell.  I refused to deal with the Solaris windowing environment.  No fancy frills for me, just give me the CLI and leave me alone. Windows came along and it opened a whole new way of working with computers for me.  Then came Cyrix & AMD and I haven’t owned in Intel processor since.  Finally, Linux hit the world by storm, and I found my new favorite platform (Linux on a PC).

The one constant in all of this change? No Mac…never, ever, ever. I refused. I didn’t like their products, didn’t like their messaging, and couldn’t stand their image. I always said: “Macs are for art students and kindergarteners, PCs are for doing real work”.  Yet despite all the goodness I heard regarding OS/X, I refused to believe Macs were finally running a real OS. Plus, every time I walk by an Apple store and see the “genius bar,” I can’t stop laughing.

As the Product Owner at AccuRev, the problem I began hearing more and more from customers I really respect was they love developing software on their Macs, but their AccuRev/Mac experience could use some improvement.  Given that AccuRev is a leading provider and integrator of Agile Software Development Tools, I put my Agile Product Owner hat on and visited some of our Mac users to see if we needed to do some agile planning and shape up the backlog a bit to support the Mac better.

All I can say is I was definitely blown away watching the Mac experience in action. These brilliant engineers were showing me areas where both the AccuRev GUI and our AccuBridge for Eclipse and IntelliJ integrations can be improved upon as part of the natural Mac UI.   In my next agile planning session, I prioritized Snow Leopard support right to the top of the backlog. (Which by the way is so great about agile; being able to adjust or course correct your plans after each sprint is powerful, thus allowing you to react to your customers so much better.)

I had to make a tough decision: either take our customers’ word for it, or experience it myself. I figured what better way to see what needed fixing than to have a Mac affect my daily use. So I took the plunge and bought a MacBook.

Testing Agile Planning on the Mac

So I am sitting here as I type this with 2 Chrome windows open (23 tabs total), Firefox open (11 tabs), Safari open (5 tabs), Eclipse, AccuRev, 5 bash terminals running, simultaneously running Windows 7 and Ubuntu VMs (via VirtualBox), 3 Word docs and 4 Excel spreadsheets open, and 6 Finder windows. The MacBook is basically laughing at me as if to say “keep it coming”…  I am still in disbelief.

New Picture Dont Tell Anyone I Switched to a Mac for my Agile Planning Here is AccuRev’s WebUI running inside of Eclipse on Mac with AccuRev’s Eclipse integration enabled. I can do all my agile planning, process management and development right from within Eclipse!

So that’s it…I’m a Mac fan now. Don’t expect me to be growing a ponytail anytime soon though.

Continuous Integration vs. Continuous Perfection (part 2)

April 6th, 2010 by clucca

Integrate early and often, it’s a software configuration management mantra that we’ve been repeating for years. Integrate early and often is continuous integration. Every source control tool promotes this concept; you can read about it in the SVN book to the ClearCase manual. It’s been preached as a SCM standard for almost as long as we can remember.  In the case of Continuous Perfection we gave up our “integrate early and often” principles, so how can we solve this problem?

Flexible Agile Tools to the Rescue

We can preach “integrate early and often” all we want. But if our tools don’t help us achieve that goal, it can be an exercise in futility. The problem with traditional SCM systems is even though they tell us to “integrate” the only thing they seem to do well is “isolate.”  Think about the branches in your environment; they are static representations of a point in time in your development cycle.  How do you know when it’s time to merge changes from the other branches? How do your developers know when it’s time to pull in changes to their local workspaces?

Automatic inheritance is a way to keep your developers connected with the rest of the organization. It gives them the ability to automatically pull in changes as needed.  It also connects entire development teams. (See “Understanding Stream Inheritance”)

The second problem is that when the build is broken, there is no easy way to recover. Asking an entire development organization to roll back the codebase to an older version could take a day. Having an SCM tool that allows you to move the milestone in which your branch is based off of is a powerful way to get around this.

Tying into this is your build management solution. Free continuous integration servers are great at building and spitting out the results. But with every build that’s produced, there are a set of actions that need to take place. Being able to dynamically roll out code based on test and build results allows your QA teams to keep working even when code has been integrated poorly.

Create a Culture of Integration

This is the most important aspect, creating an “integration” culture in your development team. Often merging code is an overlooked and under rewarded task. Developers must deal with the merges, but often don’t get credit for doing so. Sometimes a difficult code integration takes a few hours, and developers may feel that this is eating into their valuable time.

Incorporating continuous code integration into your daily lives can help this. This might mean that you have Tasks that are assigned to your User Stories that deal with code integration. Or this might mean doing a code / review / integration session with your team. Engaging our team mates and making sure that the work that’s being done for these code integrations is rewarded and recognized goes a long way in relieving the frustration of a bad code merge and ultimately saving you from Continuous Perfection.