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.

Did you know that CM systems back in the day were basically people? This is where the term “check-in” & “check-out” comes from- it refers to the days when there where actual software librarians would record peoples changes and check them in and out like books on disk or punch cards. It’s mind boggling to think of software this way.

If I was to ask software developers today what “software configuration management” was, they would probably say “SCM? Like Subversion?” Incorrect! You need to trust me on this one, SCM is not the same as a version control system. Yes, your version control system is an SCM tool (confusing?) but SCM is a broader discipline and technique that encompasses the management of change in software.

The introduction to the IEEE “Standard for Software Configuration begins with:

SCM constitutes good engineering practice for all software projects, whether phased development, rapid prototyping, or ongoing maintenance. It enhances the reliability and quality of software by:

• Providing a structure for identifying and controlling documentation, code, interfaces, and databases to support all life cycle phases
• Supporting a chosen development/maintenance methodology that fits the requirements, standards, policies, organization, and management philosophy
• Producing management and product information concerning the status of baselines, change control, tests, releases, audits, etc.

Let’s be clear- all of the things on this list do not fit under the heading of your version control system. Many of them will require practices and policies to maximize your development efforts and methodologies. With version control, release engineers will still have to perform some of these SCM related functions:

• Merge early and often
• Enforce a workflow for development teams to follow
• Record and have full visibility into all of the changes that were made
• Write build and compiler scripts
• Automate builds, deploys and tests
• Understand the dependencies between projects and code
• Maintain the development environment for a team
• Be responsible for the final product going out the door

That’s just the tip of the iceberg. A talented release engineer or SCM expert can do all of those things independently, but his or her job would be a lot easier with SCM tools that can automate and facilitate the necessary practices and processes. (This includes version control, compilers, debuggers, editors, continuous integration machines, automated deploy, and the ITS system.)

At it’s core, SCM answers the question “Somebody did something, how can one reproduce it?” In addition it’s about understanding and establishing relationships among items that are likely to change. It’s a tricky job, not one that’s easily understood. We have to understand the relationships between versioned artifacts, like code, hardware, documents, design models and even directory structures. In addition we have to do all of the necessary things to make those versions valuable to our organization. We have to design process, workflow, automation, build automation, reports and security.

With all of this, don’t tell me that SCM is the same as version control. Trust me on this one!

As the software development process has evolved over the past couple of years – particularly enterprise software development – one aspect  of software configuration management has drawn increasing attention as a means for controlling risk and maximizing success rates. Of course, I’m talking about software release management.

What is software release management?

It’s the practice of doing all the builds for the various aspects of a project and then moving all those builds to its particular process – development to QA to user acceptance to production to deployment.

What’s made software release management crucial to efficient and timely software development is the use of parallel and geographically dispersed development teams. What was once a pretty straightforward, linear process has now become a major, multi-tasking effort as engineering teams work concurrently on various aspects and features of a product that then need to be merged into a single main trunkline for QA, production, and eventual release to the marketplace.

Compounding this release management challenge are additional issues such as:

• error correction
• additional customer feature requests
• risk management
• product revisions
• manufacturing issues
• general software entropy over time

As a result, the release manager function was developed to deal with all these challenges – a sort of software release management superhero. Part overseer, architect, coordinator and support engineer, the release manager is expected to have a general, transparent view of the entire project development process along with a granular view of every aspect of it. Never mind real-time issue and code change tracking, along with  the ability to head off error propagation and broken builds. How can any one person manage to accomplish all this?

The best answer? With a software release management tool that provides a stream architecture, or something that can be described as “intelligent branching.” Streams are ideal configuration objects because they contain absolutely everything associated with any particular release, making it easy to track the history of the release and merge any changes with minimal (if any) errors. In fact, streams make it easy to dial back the clock and return to virtually any version of a release to quickly and effectively handle any errors that might pop up.

What makes this type of tool particularly useful is the way it helps release managers handle all the important aspects of software production, including build stabilization, QA testing hand-offs, product assessments, and archiving activities, to name a few. In short, software release management makes it really easy to move new builds to any one of the configurations needed in the software development and release process.

Some of the major features of our software release management tool include:

• Use of streams to store and make available complete code files for all release versions
• AccuRev TimeSafe architecture for atomic application of all code changes to minimize errors
• Integrated issue tracking
• Improved developer productivity

Me speaking at Agileee 2011!

I wanted to take a minute to thank Agileee for having me this year. It really was a great conference- great speakers, great crowd, great city. I learned a lot and met some interesting folks, and must say that Kiev, you changed my opinion of vodka .

For any of you who missed it or would like a reminder, the video of my presentation, “Scrum and Kanban, Like Chocolate and Peanut Butter” is available here, as are the slides.

If you get the opportunity to attend the next Agileee, I highly recommend it! Thanks again for having me, Agileee.

The holidays are still several months away, but for software development teams in the travel industry, the “hustle and bustle” of the season is already here.

If you think about the ways you make your business or personal travel plans today, you’ll begin to appreciate the increasingly complex software development challenges travel websites present – and the importance of advanced SCM tools.

Just 10 or 15 years ago, many of us were still making travel arrangements through an agent – on the phone or in-person.  We may have gone online to check out a hotel and moved to another site to check on flights – and yet another to rent a car.

Today, travel websites like Kayak and Orbitz bring together all these consumer options and more – and others include frequent flyer miles, preferred guest points and other information related to our travel plans, often involving outside partners.  All of these variables are changing rapidly and are updated dynamically and in real time on travel websites.  This places greater demands on software development teams – teams that are increasingly distributed across multiple time zones and locations.

Also important to note is that the changes and updates these teams are called on to make are increasingly “business-critical.” A software glitch or a site crash can result in major revenue losses, not to mention the residual consumer frustration and damage to the brand.

More variables, more frequent updates and a more business-critical focus — now magnify all this during the many times of peak travel or weather-related interruptions and one begins to understand why more advanced SCM tools are required in the travel industry today.

Basic software development tools may have been fine for some organizations in travel — smaller airlines or hotels with more basic informational web sites that aren’t designed to process high volume reservations and transactions.  But such basic sites are becoming a rarity in the travel industry, leading more and more travel and hospitality businesses to turn to more advanced software development solutions.

AccuRev’s SCM solutions are designed to handle today’s most complex software development challenges, which explains the growth we’re seeing in travel and hospitality business customers.

So when the holidays draw near and you go online to book a hotel, schedule a flight or rent a car, you can thank all of those software developers that have been working hard behind the scenes to make sure the site is up and running 24/7.

Mammoth retailer Target must have had very high hopes for big sales when a new designer collection went on sale last week. Unfortunately it ended up being a bust. (The site quickly became overwhelmed and crashed several times throughout the day.) Online retail experts say losses for the retailer could run into the millions as a result.

Scenarios like this are not new, though with a large retailer like Target, it was somewhat surprising. The painful reality of eCommerce is when transactional websites experience dramatically increased traffic, there is always a chance that, without well maintained software development measures in place, crash scenarios like Target’s will occur.

When an eCommerce crisis like this occurs, developers go into fire drill mode to make rapid changes so the site is back up and running as quickly as possible. Software change and configuration management tools play a crucial role in both ongoing updates and crisis management updates, like the Target example.

It’s also important to note that traditional SCM tools won’t cut it when it comes to high volume transaction web sites like Target, Amazon or any major retailer. Most retail and eCommerce sites need enterprise SCM tools that can scale to accommodate large, geographically distributed teams of developers working in parallel. More advanced SCM tools are integral to the success of transactional web sites, both from a day-to-day aspect, and when there are spikes in traffic and transactions for special sales events, promotions, and holiday shopping.

While last week’s incident demonstrated what can go wrong when an eCommerce site experiences significant problems, there are some great stories out there as well.

One such example is that of a very large and well known travel eCommerce site that receives an average of ten million visitors a month.

As with most of the top of travel eCommerce sites, this one is very dynamic. Users can make reservations for airlines, car rental, hotels, sign up for text message alerts about delayed flights, rate their own experiences and much more.

While these features are popular with consumers, these transactional environments are highly complex to manage. At this particular website, there are as many as 40 different development teams working on 40 different projects. One “project” might be car rentals, another hotel reservations, etc.

When development environments have this much complexity, when teams are working in parallel on a wide variety of projects, only the most powerful SCM tools can help minimize version control problems that lead to bugs slipping through. What may appear at first to be a minor issue can, in the worst case scenario, cause an array of site problems and crashes that have a direct impact on the consumer and revenue. This travel site, which uses AccuRev’s SCM solution, is able to do everything possible to ensure the site and the software behind it stay up and running smoothly, 24/7.

The web storefront is a business critical tool for any type of eCommerce business.  For these reasons, enterprise level SCM tools under the hood are essential to success.

What other similar success and web crisis/failure stories have you experienced directly or heard about?

AccuRev’s security has advanced to the next level with the release of version 5.2. One of the great new features that I’m happy to introduce is Access Control Lists, or ACLs.

AccuRev’s ACLs

Have you ever wanted to fine tune your security for files or streams based on role, group or user? Now you can using our new built in security commands. Here’s how it works:

In addition to locks, each stream can have one or more permissions. This also applies to files and directories. This means that you can control who can modify/see certain streams, and who can modify/see specific elements.

Setting ACLs are easy, this can be done via the CLI:

C:\Users\clucca>accurev setacl stream phoenix_Client chris all

The ACL has been set successfully.

This will now lock me out of all the files under the phoenix_Client stream…

If I try to access that stream in the GUI, I will receive this message:
This also works for files and directories, which is great for teams that want to have secure outsourcing and security conscious development initiatives.

In addition you can use the lsacl command to list permissions. You can see that for the stream phoenix_Client chris has no rights to access it, but the permission doesn’t inherit to the rest of the streams, so I can access everything underneath it.

At AccuRev, we’ve noticed a new practice emerging that we call “Issue Based Development.” You may have heard of this term or something like it such as Work Item Based Development or even “requirements traceability.” Whatever you call it, more and more teams are gravitating towards it, perhaps as a result of adopting some of the Agile practices. In this post I will give an overview of Issue Based Development as well as talk about how to maximize your success with the practice.

Issue Based Development is the practice of breaking all work down into individual issues; associating all work products such as code, tests, and documentation with those issues; and managing the progression of work through the various stages of your software lifecycle via those issues.

The benefits of Issue Based Development include requirements traceability, better progress and status tracking, and simpler application of patches from one stream of development to another. These benefits and more will be covered as we cover the individual practices that make Issue Based Development possible.

Track All Work by Issues

Whether you have requirements, enhancement requests, escalations, defects, bugs, tasks, user stories, RFE’s or some other way to describe work, it all goes into issues. You may use a different term to generically describe tracked work, such as work items, but in this post I will use the term issues.

Today, many companies use some combination of Excel, Word, a Requirements Management system, a bug tracking system, MS Project, and an Agile Project Management tool to track “different” kinds of work. In the end though, somebody has to be assigned the work and that work needs to be explained to them in a way that makes sense to them. Why not use issues as the final unit of describing work, whether you continue to use the other systems or not?

Make All Issues Available in a Single Place

Using issues to describe and track all work implies that all issues for a particular project eventually end up in a single Issue Tracking System (ITS). The obvious way to achieve this is to simply move everybody to use the same ITS and to use it for all work-related artifacts, from defects to requirements to whatever else it is that you use. In reality this is difficult to achieve, but is the right goal to strive for, to the extent that you can.

Synchronize Multiple Work Tracking Systems

A good complement to moving as much work tracking to a single ITS system as possible is to synchronize issues from other work tracking systems to a single ITS system. For instance, AccuRev provides AccuBridge and AccuSync to enable you to have all of your work in a single system.

Link Issues to the Work Performed

Once you have all of your work tracked via issues in a single ITS, you are now ready to take the next step, linking all of your issues to the work performed to implement those issues. I’m assuming that you are keeping all of your work artifacts such as code, test, and documentation in your Software Configuration Management (SCM) system. The best way to link your issues to the work performed is to use an SCM object called a Change Package. Some systems may have a similar object called a change list or change set. AccuRev uses change packages.

By linking issues to work artifacts, you can now manage by issues instead of by files. For instance, instead of trying to figure out which files correspond to a set of hotfixes that you want to apply to new development, you can instead refer to the issues that represent those hotfixes and have the SCM system do all the hard work of determining the exact set of changes and promoting those changes from one environment to another.

Use a Stream Per Stage

Having a set of promotion stages is a great complement to Issue Based Development. By having a set of stages corresponding to your development workflow, you can easily see what stage of development various issues are really in simply by querying your SCM system. Doing reports against your ITS are good, but those are generally hand updated. Your SCM system reflects the real state of your code.

A typical set of stages might be “Todo,” “WIP,” “Coded,” “Tested,” and “Done.” You can represent each of these promotion stages with Streams in your SCM system. This allows you to associate Continuous Integration servers which each stage and build versions of your product corresponding to those stages. Imagine for instance being able to build a version of your product that has only tested stories in it.

Another benefit of this arrangement is that it enables “One Piece Flow.” For more on this topic, see my related (http://damonpoole.blogspot.com/2009/09/one-piece-flow-transitioning-from-scrum.html) DIY Agile blog post.

Keep Issues as Small as Possible

Most organizations are good at tracking all bugs in a bug-tracking system, but usually track new work via Word documents which describe very large chunks of work. When moving to Issue Based Development it is important to break these large chunks down into as many and as small issues as you possibly can. This is important for two reasons.

First, it is next to impossible to measure real progress against very large chunks of work. By breaking work down into small issues, it is easier to measure progress by seeing how many issues are fully coded, tested, documented, and ready to ship and measuring the amount of effort associated with those issues.

Second, working on small issues reduces the chances of “issue entanglement.” Entanglement occurs when two issues have changes that are dependent on each other in such a way that they become impossible to promote independently. The ideal is to have one person (or programming pair) work on a single issue at a time and for that issue to be finished in days rather than weeks. The more people working on an issue an the longer they are working on that issue, the more likely it is that the issue will become entangled with multiple other issues.

I’ve often heard people wonder why the SCM system can’t make this simpler. At AccuRev, we are always striving to make Change Packages simpler to use, but the simple fact is that there are limits to how much can be done to simplify entanglement issues. It is generally much more productive to apply the practices in this post which have benefits in and of themselves as described throughout.

Apply the Open/Closed Principle

Large files are another factor that contributes to issue entanglement. Often, frequently used and/or complex classes create large source files. This is similar to the problem of large issues. The larger a file is, the more likely it is that multiple people will be working on it within the same timeframe and thus the more likely it is to lead to issue entanglement.

There is a very useful principle that comes from Objected Oriented programming called the “Open/Closed” principle. This is the idea that software should be open to addition, but closed to change. In its pure form this means that you only add and extend classes and change them as a matter of last resort. A slightly modified version of this would be to only add new methods and to avoid changing them. Also, changing methods should be restricted to rewriting the code such that it adheres better to the principle by being easier to add new methods to and requiring less change to existing methods. This is a very common refactoring pattern.

The side-effect of the Open/Closed principle is that you end up with smaller source code files. The smaller your files are, the less likely you are to run into entanglement and merge issues.

Start Towards Issue Based Development Today

Whether you follow these principles and practices to the letter or not, the more you follow them, the easier it will be to practice Issue Based Development. The better you are at Issue Based Development, the more success you will have with requirements traceability, progress and status tracking, and the application of patches from one stream of development to another.

Source code control is one of those topics that can cause some software developers to sweat profusely and make the veins to pop out of their necks, especially if the project includes working with third-party or vendor code – and these days, what project doesn’t include vendor code?

I should probably start by defining source code control as that mechanism for checking source code in and out of a central repository, enabling several developers to work on the same project simultaneously without the risk (hopefully) of mucking up the source code in the process.

If that isn’t difficult enough already, add vendor code customization to the mix and even the sanest developer becomes a serious candidate for expensive therapy. After all, isn’t traditional branch-and-merge challenging enough without adding a entirely new layer of software configuration management for the vendor code and its corresponding upgrades?

Most of the headaches associated with source code control and management can be attributed to traditional, file-based branch and label source code control tools. The problem stems from traditional branch-based SCM models that require numerous branches to track both vendor source code and custom modifications to that code. Individual branches are needed to track just the vendor code, making merging really unwieldy, especially if you want to do a branch-to-branch merge. Throw in a vendor upgrade and then try to merge a subset of existing custom features and you can see how this can rapidly get ugly.

What’s the answer? Real simple: streaming.

Think of streaming as “intelligent” branching. What makes streaming so great for source code control is that each stream contains every single file needed for that specific source code configuration. They are complete entities unto themselves. Streams can be arranged in a simple “parent-child” hierarchy with a built-in feature that causes configurations to be automatically inherited by every new stream from the parent stream. Even better, the inheritance can also apply to any previous, older streams!

In fact, stream-based architecture provides a host of developer-friendly source code control benefits, including:

• a flexible release process that includes integrated source code control and issue-tracking
• private developer workspaces that enable private versioning  with continual server-backup
• instant, authentic, single-step renaming of any object in the source code control system with full history preservation so no changes are lost

If you’d like to know more about stream-based source code control, especially when using third-party code, we’ve got a free white paper you can download: Managing Vendor Code Customizations with AccuRev’s Stream-Based SCM.