What is your Continuous Integration (CI) strategy? If you don’t have one, you should!

May 30th, 2013 by AccuRev No comments »

Your development teams are busy building your next product releases. You follow an “Agile” methodology for your software development process, and have feedback loops throughout your processes to increase visibility, quality, and speed. You have a well defined build and release process and you think you have it all figured out. But do you?

What happens when 2 of your 3 development teams checks-in good code and the 3rd team checks-in bad code? If you are merging the code from these 3 development teams into a main integration trunk, chances are the entire build process is going to break. This situation causes a ripple effect whereby QA is stuck with a build they cannot test. When QA is stalled, your build and release process is stalled.  The development teams have to fix their issues, re-test the individual check-ins and re-merge the changes into the main trunk again. If you are lucky, the build will be successful this second time around. This is adding time and cost to your development process and your release cycle. Oh, and by the way, during this time frame, your customers are stuck waiting for software that is just not getting out the door!

exploding branch What is your Continuous Integration (CI) strategy? If you don’t have one, you should!

So how does CI help fix this situation? By integrating early and often, the development process becomes more efficient, eliminating the potential bottle necks and stop gaps that you are dealing with today.

The CI process allows development organizations to be faster, more flexible, adaptable, and quality centric. CI build streams throughout the development process provide additional feedback loops, whereby developers and engineers get feedback on their code faster and earlier in the development process, which allows them to react faster. The practice of CI Build and test provides much greater visibility into what specifically broke a build and helps to find problems before the nightly top down build and test processes.

Pure and simple, Continuous Integration finds issues where they much less expensive and much cheaper to fix, resulting in higher quality and less risk in the end product.

Integrating early and often creates a predictable and repeatable environment. This environment can continue to interface with existing build/ test or code review processes; OR, because of the nature of CI, some of these build/ test and code review processes can now be automated, saving even more time during the development and testing processes.

The ideal Continuous Integration situation to address the issues experienced above may look something like this:

1) Each developer/team works on and completes issues that get submitted to a CI Build/Test stream

2) When those issues pass automated testing or code review, they get promoted up to the Nightly Build stream

3) Issues passing build and testing on the Nightly Build stream get promoted to the Feature stream; and from there to the Team, Final Integration, and QA streams.

 stream and CI What is your Continuous Integration (CI) strategy? If you don’t have one, you should!

Continuous integration ensures only those issues which pass the build/ test or code review criteria get promoted up to higher level streams. This process allows for “cherry picking” those specific issues which pass testing while segmenting and not promoting those issues which are broken or need more work. You no longer have an all or nothing build process.  QA is always working on a stable build for testing and integration purposes. All bugs, issues and defects are identified and addressed early in the development process.

CI is a key strategy for helping companies evolve their software development process.  If your organization has not adopted a CI strategy, you are putting your company’s longevity in danger!

Distributed Collocation.. an Oxymoron?

July 12th, 2012 by clucca No comments »

In preparation for Agile 2012 in a few weeks, I’ve decided to talk about collocation. If you watch as many webinars as I do, you’ll notice that many Agilists encourage teams to become collocated – a concept that encourages scrum teams to work together in the same location – because of the many benefits to this concept. Distributed Development 300x233 Distributed Collocation.. an Oxymoron?

Agile teams require high bandwidth communication so they can receive rapid feedback. In addition teams should be cross-functional and self managing. This means that each team should be staffed with developers, testers, doc writers, etc. This enables them to complete a user story without having to go outside the team. The idea is to avoid silos and delays.

But my problem with collocation is not about the benefits, but with this idea that we have to all work in the same location to get the benefits. Think of how many companies work in a distributed nature – lots of startups now work distributed. How are these teams able to deliver software so rapidly? Is it realistic to think that while organizations have been moving to a distributed model for the last 15 years, they would suddenly move back to gain benefits of collocation?

I believe you can have your cake and eat it too. Collocation can be more of a mindset as opposed to physical location. Is it beneficial to have everyone in the same office? Yes, of course. Do we have all of the tools we need to pull this off without actually being the same location? Absolutely.

One method is to apply the concept of virtual co-location. This involves staffing the team with every member they need in a cross functional way, but without being in the same location. This avoids the problem of silo-ing functions to whole teams, and encourages distributed members of the organization to communicate more often. There is no reason not to do this – think of all of the communication channels we have now a-days. From FaceTime, to Skype, development teams can stay in communication with each other in real time. Here at AccuRev, we do virtual scrums via video chat, enabling our teams to be crossfunctional and virtually co-located.

You can still break down the virtual cube walls, without having to bring those teams together. Yes, I believe virtual co-location is possible.

AccuRev Announces New President and CEO Peter Shields

July 10th, 2012 by AccuRev No comments »

AccuRev, Inc. today announced the appointment of Peter Shields as AccuRev’s President and Chief Executive Officer. Mr. Shields, whose position is effective immediately, has spent over 30 years in the software development industry. He replaces Lorne Cooper, who served as AccuRev’s President and CEO for the past seven years.

“AccuRev is a leader in advancing software development, with a strong customer base that spans the globe,” said Mr. Shields. “I am excited to be a part of AccuRev and look forward to building on the success the company has had to date.  The need for process-centric software development tools in the enterprise continues to grow, and AccuRev is well-positioned to benefit from this growth.”

Peter Headshot1 AccuRev Announces New President and CEO Peter Shields

Peter Shields, AccuRev President & CEO

Mr. Shields has an excellent record and extensive experience leading software companies similar to AccuRev. Prior to joining AccuRev, as President and CEO he led SoundBite Communications (SBDT) to an IPO.  Additional assignments included CEO Formation Systems (acquired by Infor), and Vice President of Worldwide Sales at Aspen Technology.

Mr. Shields earned a bachelor’s degree in Engineering from The University of Pennsylvania, and a master’s degree in business administration from The Wharton School of the University of Pennsylvania.