It’s 1998. I’m just starting my job at Rational Software, supporting ClearCase. During my training and through my first few months handling customer issues, I developed a deep understanding of the complexities of SCM and the heavy-handed centralized control that ClearCase provided its customer base. Wrappers, triggers and script automation were the key to a tightly controlled, centralized development environment.  In the developers’ eyes, dealing with the version control tool was just a part of doing their job.

Developers like to code, not “waste time” with tools or infrastructure. They are creators and want to create their masterpiece. Check-in, Check-out, Merge, etc. are not ways developers want to spend their time, especially if they are forced to deal with poor performance from an SCM tool, whether it’s by the tool itself, or the myriad of wrappers that were forced on top of the SCM tool their company chose. In a developers eyes, any time spent NOT writing code is wasted time.

However, despite the negative ramifications of SCM centralization and control to the developer’s productivity, there are absolute benefits to the enterprise that cannot be lost. Security, traceability, visibility and control are paramount to running a development organization.

My decision to come work at AccuRev in 2001 was based on the software’s unique ability to provide all the features the enterprise needs, while minimizing the negative impact SCM has on developer productivity. The ease at which AccuRev provides visualization and control over the entire development process was truly a game changer.  And while still a centralized SCM tool, AccuRev was designed to minimize the pain developers felt during their day to day operations.

It’s now 2012 and the SCM landscape has changed dramatically for developers. De-centralized / Distributed development is all the rage now. Version control tools such as Git and Mercurial are providing developers with the experience they demand. Local copies of repositories give unparalleled performance. Strong branching models provide near painless branching and merging. Tools like Git are designed with the developer in mind. Performance, merging strength and extremely in-depth control of all operations are the focus of product features.

All that said, while distributed SCM tools are great for developers and fine for open source development, Enterprises are experiencing chaotic development and losing control in their engineering organizations. So which way do you go? Centralized appeases the Enterprise, De-Centralized appeases the developers.

The answer is both. Now that AccuRev has introduced Kando, Enterprises can maintain all the security, traceability, audit-ability, visibility and process control their business depends on, while giving their developers exactly what they want – to use Git for their day to day development.

AccuRev released for general availability today the first Git integration that seamlessly bridges the world of commercial tools and open source software configuration management.

AccuRev’s Kando, an enterprise security and compliance platform for Git, which was released in beta in January, complements the open source SCM tool with additional functionality, allowing organizations using Git to simultaneously leverage enterprise-level security and requirements traceability.

Kando is the first software development solution that enables Git development shops to add workflow, issue tracking, security, change requirements and other capabilities to the software development process, all while maintaining the flexibility and familiarity of Git environments.

Kando’s ground-breaking enterprise-level security and compliance capabilities allow its users to:

• Comply with enterprise-level regulations, by providing full audit and traceability
• Secure Git with access control capabilities, and support for enterprise authentication via LDAP and Microsoft Active Directory
• Visualize and manage development processes that use Git in AccuRev’s StreamBrowser™ environment
• Support Software Change and Configuration Management (SCCM) through change-based development with AccuRev Change Packages

“Our Kando Beta announcement in January had an overwhelmingly positive response, and it is clear that Git adoption has expanded well beyond the Linux community, into product development and IT,” said Lorne Cooper, AccuRev’s CEO. “Kando can solve many security and requirements traceability problems that enterprise organizations face when adopting Git, and really allows Git an opportunity to scale the development process across enterprise software development teams.”

During the development of Kando, AccuRev established the Kando Technical Advisory Board, comprised of representatives from several enterprise organizations with Git environments. To hear what they are saying, or to learn more about Kando, visit http://www.accurev.com/kando.

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.

 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!

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.

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.

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.

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.

I recently read a story that the World Health Organization (W.H.O.) issued a new safety checklist for surgical teams. Checklists sound great and frankly it was kind of surprising they weren’t already in practice. Here at our company we go through a number of checklists, and I can only assume you do as well. There are testing checklists to determine what test coverage exists, process checklists when products are about to ship, and integration points themselves could be considered a checklist of activities that need to occur for success.

What I found particularly interesting were the topics covered in the checklist. There are fundamental items like marking the location of the surgery, but I found the following to be the most topical:

*    Confirm that all team members have introduced themselves both by name and by their role on the surgical team.

*   The surgeon, anesthesia professional, and nurse should verbally confirm the patient’s identity, surgical site, and procedure to be performed.

*    Anticipated critical events to be reviewed by the surgeon are any critical or unexpected steps, estimated operative duration, and anticipated blood loss.

Keep it High-Level

Blood loss aside, what I find interesting about these items is how high level they are. You have team members participating as a team, identifying the areas of focus and activities. Staff executing risk analysis. Providing estimates. This is great.

SCRUM

We’ve been using Scrum. This means we have a 15 minute meeting once a day to go over our activities. We talk about what we did yesterday, what we are doing now, how long it should take and any risks to success. Sound familiar?

SCRUM HURDLES to HURDLE

Although Agile has been going well here for a while, there may be a number of initial hurdles to watch out for if you make this kind of change. Having to coordinate a day and time for all team members, then trying to keep the meeting to 15 minutes can be a challenge. It’s far too easy for development staff to lapse into traditional practices. When we first went to Scrum some of us would begin to discuss specific issues during the meeting (a Scrum no-no), and people would obviously start tuning out. This then translates into not knowing the more high-level team goals and activities.

Our first attempt to fix this, having everyone send a daily status email, at first just went to the team lead. The team lead knew what was going on, but it still didn’t solve the larger goal of having people be aware of their role and its impact on the team. We then tried to fix this, by group consensus, by everyone emailing the group with their daily status. This had the advantage of getting the format of the data consistent amongst the team, and getting information to everybody in the team. But it doesn’t get people to read the email. I now have a filter that automatically drops these into a directory that makes them easier to find, open, and read, or scan depending on my level of caffeine.

NOT LOSING SIGHT OF THE GOAL

So what I see as part of the goal, as well as what the W.H.O. was trying to achieve could be lost. Without the physical meeting everyone remains caught up in their own particular goals.

These personal goals are necessary, but they are not always conducive to team productivity.

Here we use Continuous Integration. We’ve been progressively converting more of our attended tests to unattended, increasing our product coverage and productivity. At the same time, staff members have been changing the test infrastructure to allow us to test varying configurations. Both are great goals, but in the beginning they ended up in conflict. One engineer was making more configuration settings required while another staffer was trying to make more of the configuration settings dynamic for portablity. The newly unattended tests were hanging or exiting early because configuration items unexpectedly became required.

Without a common goal, or at the least an understanding of everyones goals we run into conflict.

What else can be done?

When developers are used to being siloed, and their work feels isolated, they are more likely to tune out as to what is being done around them. But integration has to happen. And it has to work. Integration should no longer be thought of as somebody else’s problem, or as something that happens after the fact. Yes I was one of the people who didn’t like yet another meeting. I was one of the people who sometimes drifted into the mundane details of my work that I thought others would want to know, eating up meeting time. Now I champion the 15 minute meeting and keep people quick and to the point. And if everyone can start feeling like integration is the goal, then people will start thinking about how their work impacts others. Sharing that information in a timely manner will smooth out the bumps, and ultimately get us more focused on the larger goals. This isn’t “brain surgery”…or is it??

I’m happy to announce the first gold release of the AccuRev SCM integration for Vim!

For those AccuRev users out there that know the true power of the vim editor, life just got even better. Now you can perform over 30 commands directly within vim including keep [\k], promote [\p], update [\u], merge [\m], revert [\rb], diff [\db], status search [\s], and more! The plugin is per-buffer so you can work on multiple files concurrently and perform AccuRev actions on each file independently. In addition, you can work in either console or GUI (gvim) mode! Here are some additional screenshots of the plugin in action.

This vim plugin has its own site at vim.tools4accurev.com for downloads, announcements, documentation and user feedback (ala blog style). You can download the plugin from the download page.

The plugin currently requires Vim 7.x and supports AccuRev 4.5.x and the latest 4.6.x. I developed and tested the plugin on both linux (Ubuntu 7.10) and Windows (XP) platforms.

Important note: While the plugin was developed by an AccuRev employee (me) and vim-user for 10+ years, it is considered a third-party open-source plugin and is not officially supported by the folks @ AccuRev support. That being said, I’m proud of the plugin and welcome feedback and enhancement requests for the next release. You’ll find my contact information on the plugin website.

/happy vimming/ – dave