Q: Can a developer use Git without an AccuRev workspace?

A: Absolutely. With Kando, the developer does not require an AccuRev workspace. Kando uses a native git repository, so developers can use Git with no modifications – it works seamlessly with AccuRev on the backend. It’s all native Git-to-Git.

Q: Is the Git repository limited to a single AccuRev stream, or can it follow most or all of the AccuRev depot?

A: The Git repository is not limited to a single AccuRev stream, it is completely configurable. When you create a repository, by default, it’s going to ask you to map the master branch in that Git repository to a stream in AccuRev, but you can set up multiple mappings. You could map 100s of branches to streams if you wanted to.

Q: Let’s say I’m an integration manager for a project. Can I create a Git repo using Kando, Git clone it on my system, and let other users clone from me?

A: You can certainly use that model if that’s how you’re most comfortable, where you clone from the bare Git repository associated with AccuRev, and then other people can clone from you. There’s nothing to preclude that from happening because it’s normal Git-to-Git. Another possible solution would be to have all of your developers push and pull from the Kando repository, then you could merge those changes up to the QA or Master branch using AccuRev or Git if you prefer. Kando supports both models.

Q: What about integration with code review tools (like Gerrit).  We actually use Gerrit as the centralized control for our Git repositories

A: If you are connecting Git to anything, whether it be Gerrit, GitHub, an open source library, etc., everything will work. Because Kando is reliant on Git working natively, you can connect to Gerrit or any other tool that integrates with Git. You can push and pull from Gerrit and GitHub as normal. When you push to the remote that is associated with Kando, which is connected with AccuRev, those changes end up in AccuRev in the stream that you’ve mapped to the Git repository’s branches.

Q: How do you handle bugs in Kando itself? Is there support?

A: Kando is an officially supported AccuRev product. If there are defects in Kando, they’ll be handled through our support and services organization the same as they would with AccuRev. Kando is developed using an Agile development methodology, so as we get feedback on defects and enhancement requests, we will turn around fixes and enhancements as quickly as possible.

Still have questions? Ask below, visit www.accurev.com/kando for more information, or check out the Kando video.

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!

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.

SCM software is not a luxury, nor just another layer of technology to be added to an already complex process. SCM software is a necessity for development teams working concurrently and in parallel on development projects, especially those employing agile processes to deliver higher quality software more rapidly.

Two of the biggest benefits of using SCM software are the ability to coordinate distributed teams and parallel development more effectively, no matter where your team members are located or even the language of the replicas being used – they can be in the next cubicle, the next state, or the next country.

We, of course, recommend AccuRev SCM

No surprise there. After all, we designed it to be fast, flexible, scalable, and effective. After all, we’ve taken process management and version control and made the ideal mash-up that provides the most comprehensive set of SCM tools available, including these best practices:

• Change management
• Visualized SCM patterns
• Automated workflows
• Private developer history
• Multi-stage continuous integration
• Issue-based development

With a single set of comprehensive, best-practices SCM tools to work with, life becomes much easier for your development teams – they can focus on software development instead of management and administration tasks. SCM software made nice and simple.

What makes it even easier is how AccuRev SCM easily handles virtually any combination of development processes, including Agile, XP, and waterfall – you name it. You’re free to mix-and-match because AccuRev SCM’s flexible model enables your teams to rip through development with continuous integration, code refactoring, and automated code sharing, to name a few.

Even parallel development is a cinch with fully-transparent code base relationship management that enables teams to store work safely and test it before sharing it with others. A stream-based architecture makes code branching and merging easier, too – it even allows changes to be automatically inherited from other teams.

If for some reason you’re not already using SCM software or if you’re unhappy with whatever software configuration management tool you’re using now and you want to know more about SCM software and AccuRev SCM in particular, check out our SCM Software Resource Center and AccuRev SCM 5.3.

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.

It’s all about the developers. They need to be free to innovate and get changes out the door quickly. But they can’t if they are stifled by tools that get in the way. Tools need to be able to ENHANCE the software development process. Many people think that source control is just a place to checkin / checkout code. But it’s more than that, it’s where the software development process comes to life. If the SCM system isn’t up to the task of a complex development process, developers can’t innovate.

Sometimes it’s hard to understand that you have a tooling problem, even if it’s staring you in the face. Think of an old pair of trusty sneakers that you have at your house. We all have a pair, they are many years old, beat-up, dirty, torn… but we still wear them. Our feet hurt when we wear them, but for some reason we refuse to get rid of these old sneakers. Until one day (usually after a sprained toe) we decide to buy a brand new pair and after a little breaking in… WOW our feet feel great! Why did I keep the other pair so long?

Software tools are often like this, there is an “if it ain’t broke (too much), don’t fix it” attitude. We often keep tools too long after their expiration date. You’ll hear it from your development team, moaning about the pains of merging code, switching workspaces, checking out … it’s enough to make you cringe. But still we don’t change. Your old SCM is the sneaker, and collectively as a group you and your team have a hard time recognizing when your feet hurt.

You’ve been warned.  From here on, you’re on your own.

Prediction 1: Everyone Will Claim They Are Agile

And 50% of them will be wrong, just based on the Nokia test.  And of the rest, half won’t get any value from it.

There are a lot, and here I really need to underline a lot, of bad development practices out there.  For every organization that is killing it with Agile, there are five (my agilesta friends say ten) organizations that are limping along, delivering buggy code to their customers, late, and missing committed functionality.  And often all three.

This “Going Agile Without Knowing How” problem is probably an inevitable result of the success the early-adopter teams had with Agile methods.  For instance, when I watch The Olympics, figure skaters make skating look effortless.  When I do it, I look like a drunken hippo and hurt my butt.  It’s hard to stop and remember that these athletes, in addition to good genetics, spent years at the rink with their coaches learning, trying, failing, and improving, before they got in front of the TV cameras.

Agile has crossed the chasm, and the great majority of organizations have too few people, with too little coaching, and hardly any tooling.  Sure, your boss doesn’t realize how useless your stand-up meetings are, or that your code isn’t fully tested at the end of a sprint, but she’ll eventually see that your customers are not happy.

Prediction 2: Development for Mobile Devices Will Still be Small

Yes, Mobile is really big, and moving fast.  It’s just that the great majority of the work to support useful mobile apps remains in the back office.  When we’re finished inventing new ways to swipe our coffee-stained fingers across our screens, the value of the great majority of our apps is back in the glass house, running Java and C++ on big ‘ole honking (virtualized) servers.

The development problem in the era of proliferating small platforms, remains the problem of dealing with large, complex, data and it’s interactions.

Sleep well, Larry Ellison.

Prediction 3: The Gap Between Pros And Amateurs Will Grow

Every new software technology “spike” rewards the early adopters with higher productivity, which can level the playing field for the “newbie” or occasional software developer.  But as application complexity grows, as the platforms become more complex and development environments become richer, the professional advantage becomes more significant.

There isn’t much of a disadvantage in time-to-market for the young developer, maybe working on his laptop with open source tools and no identifiable process. The difference between them and a team of experienced professionals, working with industrial strength tools and procedures, and building apps that run businesses on virtualized hardware in a web connected world, is in “value created.”

Created Value is a concept that we’ve all been learning during the past ten years of Agile evangelism.  Created Value is measured at the customer side, and primarily by the classic metrics of software: how does the software help me get my job done better and faster?

There was a time when the lowest cost labour source for a software project was the key criteria.  Over the past two years, software projects have been revisiting their decisions as they’ve seen the crippling effects of buggy, unmaintainable, badly architected products.  We’ve seen the evidence with a hiring boom in the US for developers and QA alike.

In short, in 2012, we’ll see a renewed focus on quality of development, over quantity.  And a better appreciation for the talent, tools, and techniques, that create it.

In the past few months I’ve had the privilege of talking to approximately fifty organizations about their Agile implementation.  Most of them are doing well, and many of them have great insights about how they customized Agile to fit their process requirements.  But some of them really Say the Darndest Things.

“We do Scrum, it’s just the rest of the company doesn’t.”

“So first we break the requirements specification into pieces and call each of the pieces a story.  Then we do our iterations and pass them off to the release team.  We’d sure like to get Product Management, QA, and the customer involved, but they don’t want to.”

There are a lot of places an Agile approach can add value, and I’d hate to adopt a “waterfall approach to going Agile”, but you’re really not doing Scrum.  The biggest chunks of value, the incremental use of customer feedback, and going from “completed state” to “completed state” in each iteration are lost if you can’t get more support.

“We’re Agile until the development is done.”

More than once I’ve been speaking with an earnest development leader who’s describing the Scrum process.  They’ll launch in, with obvious pride, and tell me how they’ve gone to two week iterations, do standup meetings, and work from a backlog.  “Terrific!  And how do you do QA?”

Oh, yes, of course they do QA, silly!  In fact, they demo the completed development to the QA team every sprint review and send it off to get tested.  Sometimes, unfortunately, QA actually finds some bugs that need fixing.  So that’s why they put the sprint on hold for a while to fix the bugs and loop them back into QA “’cause we don’t want to wait an entire sprint before they can restart the testing.”

The other side of this one is the guys that take the old “Release Tail” loophole for all it’s worth.  “Yes, Lorne, we’ve been agile for three years now.  We do Scrum, unit testing, standups, and play in the World Series of ‘Planning Poker’.  We do that for about six weeks, or until the release.  Then we have a three month release testing tail, which follows a ‘modified Scrum process’ … the project leader estimates the amount of work on each bug QA finds, and assigns it to a developer.  Sure, sometimes we have to work on new functionality during the “release testing tail” … you can’t expect the customer to stop needing improvements for three months!”

Folks, I don’t think I’m sharing any great trade secret when I tell you the QA process needs to be completed before the story is considered “done.”  I don’t want to be Klaus Fuchs of Scrum, but here’s the secret: you’re going to have to invest more in testing up front.

“We do continuous integration every night.”

I blame the education system: how’s an engineer supposed to know what “Continuous” means when we have “social promotion!”  Now some people understand the idea of continuous integration, and made a conscious effort to make it more “Discrete”.  Some companies I talked to had broken builds that lasted for a week.  You’d rather have a child repeating “Mummy” every 30^th of a second before you’d like to get an email every five minutes saying the “Build Failed.”  I get it.  And if the email was going to your boss too, well, you don’t have to be Dogbert to know that’s a bad idea.

Builds are going to fail.  Get used to it.  The problem is not that the build failed, but that you couldn’t fix it.  Good practices are to have the team drop what they’re doing when the build fails and hop on fixing it.  If they can’t fix it, it needs to get escalated *pronto*.  Better is to have the team do local builds and unit testing before they check in.  Best Practices are to divide up the build process by team and stage of development, so your team only pollutes itself, not the rest of the development org.

“We don’t need training since we can use the internet.”

Uh huh. So I guess the schools will be shutting down any day now.  Not that the Internet might not turn out to be a useful aid someday, but the software development process is a hands-on activity.  And similar to other hands on activities, like dancing or carpentry, you can’t learn to do it by reading a book.  You’re going to need to get some experience with the process before you understand how to run a sprint review or a stand up, how to estimate stories, and how to work with your QA partner.

Now if you’re a hobbyist and working for free, your time is cheap, and there’s no reason not to use trial and error as a learning method.  But if you’re getting paid, and your work is important, you really don’t want to waste four sprints figuring out what someone can help you get right in sprint two.

I’m hoping my surgeon, pilot, and barber got a few lessons before it was my turn.

Finally…

No one has to pass a test to call themselves “Agile,” nor should they. Agilistas don’t have a monopoly on the right way to develop software.  But when people believe they’ve made it to Agile without using critical Agile concepts like time boxing development or getting to “done”, they’re missing the real value.

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!

So, what’s the deal?

#1) Agile is an umbrella term for several methodologies.
Agile encompasses a lot of different things; it can mean different things to different people. This might be why people have such a hard time understanding it. So comparing “waterfall” to Agile isn’t entirely accurate, or possible, since it’s like comparing one NBA team to all of MLB. Agile encompasses several methodologies (such as XP, Scrum, Kanban), which are all iterative in nature… that brings us to…

#2) Agile is iterative.
Yes, agile is an umbrella term, but all of the methods in agile share common core values: The fundamentals are to incorporate iterative development and to have continuous feedback so that you can always improve. This means you continuously plan, continuously test, and continuously integrate so you can adapt when needed.

#3) Agile is adaptive, not predictive.
Do you remember what “waterfall” was like back in the day? We spent months gathering business requirements, writing specs, and designing, and then spent the next 10 months coding. Since we spent the first few months trying to predict what the next 10 months would entail, we could never accurately estimate how much work a task was supposed to be, and heaven forbid the requirement changed half way through! Agile is an attempt to shorten that cycle so we don’t have to waste 10 months before find out something was wrong.

#4) You can pick and choose what methods you want to implement.
It’s funny. I ask people all the time, “How agile are you?” They typically say “Well, we’re somewhat agile, but not fully agile.” People tend to measure some sort of agile “zen” in their head, and that doesn’t exist! If you’re practicing some agile methodologies, you’ve won half the battle.
You’ve won half the battle if you are practicing:
·         Continuous Integration
·         Agile Workflows
·         Test Driven Development
·         Short Iterations
·         User Stories
There’s no out of the box way to do this, but if these methods work for you… then you’re there.

#5) The genius Of Agile is in the name.
Since the word “Agile” can’t be traced back to a specific methodology like “waterfall” we probably won’t ever think of it as “development”. In addition since it’s not a prescribed method of doing things (ex: Watefall.. requirements->design->implementation->verification->maintenance) it just can’t fail… whatever methods we use can always be improved and adapted to best suit our needs.