Posts Tagged ‘integration’

AccuRev Announces Kando!

January 31st, 2012 by AccuRev

It’s here! AccuRev today announced Kando, the seamless integration of Git with the AccuRev server. Everyone at AccuRev is incredibly excited about it.

As many people know (and as we discussed here last week), Git is increasing in popularity among developers working in small groups or collaborating on open source projects. It’s also fast, flexible, and full of developer-friendly features. But when it comes to using Git in an enterprise, the size and complexity of these environments can make it difficult to secure and manage the software development process.

What makes Kando different from other Git integrations?

Take a look at the diagram below. With Kando, Git developers push and pull from real Git repositories. Kando takes all changes pushed to these repositories and replicates them on the AccuRev server. Furthermore, any changes made in AccuRev streams that are mapped to Git repositories are replicated in their respective repositories. This means Git users can just do a pull to get those changes, which allows Git users to continue using Git as usual without interacting with AccuRev, if they choose not to.

Functionality Diagram AccuRev Announces Kando! How does Kando benefit Git development environments? 

Kando enables the flexibility of Git and the security of AccuRev by providing:

  • Support for enterprise authentication via LDAP and Microsoft Active Directory
  • Fully integrated issue tracking system and Software Change and Configuration Management (SCCM) through change-based development with AccuRev Change Packages
  • User and group-based access control security measures
  • Visualization of development processes using Git through the AccuRev StreamBrowser
  • Seamless integration of Git into an AccuRev environment

Take a look at how it works:

To read more about Kando, watch the demo video, and learn about beta availability, check out the Kando page here!

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.