Archive for the ‘Best Practices’ category

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.

 

Agile vs. Waterfall: We’ve Been Doing it Wrong for How Long!?

January 16th, 2012 by clucca

I was browsing reddit.com the other day and ran into this post:

20120116 Lucca Reddit Agile vs. Waterfall: We’ve Been Doing it Wrong for How Long!?Yup. It’s true. The tried and true development approach of Waterfall that we’ve been using for years was an example of what NOT to do for software development.

From the Wikipedia article: The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,[3] though Royce did not use the term “waterfall” in this article. Royce presented this model as an example of a flawed, non-working model (Royce 1970). This, in fact, is how the term is generally used in writing about software development—to describe a critical view of a commonly used software practice.

That’s what’s amazing about waterfall, and the agile transformations that seem to be taking the industry by storm. Maybe we all know deep down there is a better way to develop software.

I hope someday we don’t look back on Agile the same way we look back on Waterfall. I don’t think it will happen for the simple reason that Agile doesn’t have one methodology tied to it. Agile can mean a simple set of practices to help with software development, but it’s more like a mission statement as opposed to a plan.