When I ask people what Continuous Integration (CI) is, I generally get a lot of different answers. Popular ones include:

“Running builds all the time!”

“Binaries on demand for QA.”

“The automation of the build so that developers don’t have to do it.”

And my favorite – “That server that sits in the corner that only the release engineer cares about.”

While all of these responses might be partially true, they don’t really cut to the core of what Continuous Integration is all about.

The true value that CI provides to your organization is QUALITY.

Let’s take a step back and talk about how quality happens. If we take a typical software development organization, feedback from the QA team is what drives product correctness. This feedback is used to help developers fix mistakes, and even change course in the way that something is designed for a specific release. One of the best ways to improve quality is to get that feedback to the developers faster, so developers don’t invest too much time, effort, and work into something that might actually be broken.

In Mary Poppendieck’s book “Lean Software Development: An Agile Toolkit” she often refers to feedback loops as being an important part of a development cycle – even going as far to point out that feedback loops help optimize certain common objects we use in everyday life, like a traffic light or in my opinion, a toaster oven. Feedback loops are all around us, it’s the difference between waiting at a traffic light that operates on a timer versus the ones that take feedback from the sensors in the road, sensing when vehicles are there. Which one do you think is more efficient?

This is what CI really is, it’s a basic feedback loop to tell your development organization that the code is either alive or dead. If dead, notify everyone and fix it. Without it, you might wait a week without fixing the problem, and will have coded yourself into a bad situation. It’s not about running builds all the time, it’s about knowing your code is still good.

What’s even more interesting about the current state of CI is that people are figuring out all kinds of ways to add new types of automation to it. For example, with Continuous Deployment, teams are measuring how the builds perform in a deployed state, even adding automated testing to it.

CI is turning into the ultimate feedback machine, going beyond regular builds and improving quality for development organizations.

As you start to scale a software development process it becomes apparent that code and user stories have to be merged more frequently. Sometimes changes may flow from one organization to another. This means that you will need to take code from one team, merge, integrate and test those changes with everyone. Each team needs to be able to work on its own schedule, this means that if multiple teams want to work on different sized iterations they can. It also means they can deliver changes as needed and on a regular basis, independent of other teams.

To do this in a traditional Software Configuration Management system, you’ll face two major problems.

1. You have to merge these code changes daily for them to be of any use.
2. You also still need to keep visibility into what stories are shared between teams, because delivering changes from user stories that are not completed in a sprint would be disastrous.

Typically, configuration teams use a single baseline or “trunk” methodology for situations like this, where all changes from each team are delivered to trunk and pulled from trunk as their iterations complete.

In terms of traditional Software Configuration Management, your teams will have to deal with these branching and merging issues. But there are STILL other problems that can happen when you use this trunk methodology:

1. Delivering 2 weeks worth of changes only causes isolation among teams, because teams are working in such a rapidly paced environment.
2. It’s too difficult to pick out each user story from the codebase as it is completed because no tracking is in place.
3. Figuring out the dependencies of those above mentioned user stories is complex.
4. Identifying what changes came from what branch is impossible.

This “baseline pollution” is not scale-able. There are a few ways to alleviate these issues that break the baseline mold. I recommend using a development hierarchy, and manage the relationship of dependencies between branches. This could also include process steps such as integration, quality assurance and code reviews.  A separate code configuration can be used for each step and user stories could simply be drag and dropped between each team, state or branch instead of a merge.

Doing this will increase code stability. As a completed user story is pushed from one stage to the next, the particular change as well as the system as a whole reaches a higher level of maturity. Many traditional SCM tools do not easily support or surface a development hierarchy. AccuRev supports the creation of a hierarchy, gives visibility into the changes at each stage, and enables straightforward merging between stages.

Branching and merging is one of the most critical things a development team must work on over the course of a software release cycle. But there’s a funny thing about branching and merging – it’s usually not thought of as part of the development process. How often do you see a user story called “as a developer I want to merge code to trunk”?

The fact that we often don’t follow a process for the branching and merging of code leads to disarray and pain.  It really shouldn’t be that hard! Teams end up in “merge hell” and deliver changes late to schedule. This problem stems from the way branches are created. They’re often not part of the process and are created from a specific business need, not a from a development practice.

When development teams do create a branching pattern, it’s usually drawn out on a white board or in a Visio document, and is used as a model for the overall development process. While the intention is good, many times these plans become quite complex for reasons that can’t be foreseen.

So, why even create branches, if they’re too complex, and unaccounted for?

Create branches the right way, and use them as:

• Development Branch – A branch created for a development code configurations and builds
• Integration Branch – A special branch for parallel teams to integrate code
• QA Branch – QA branches for QA teams to create builds and environments
• BETA – A preproduction branch for customer sign-off, etc…
• Production – All of the content that ends up in prod

If we take a more philosophical view of what branches represent, beyond business needs, they actually serve as workflows for different aspects of the software development process.

The goals of a branching pattern should always to be to manage a software team’s development process and to make this process as easy and straight-forward as possible. With this process, the team should be able to complete all of the things that need to happen in order to release a piece of software. So how you establish this pattern?

Make Merging Changes Easy and Straight-forward

The funny thing about branching patterns is that we often attempt to create a process, but have a hard time following it. Typically someone from the team will draw the branching pattern on the whiteboard, and even go as far to take a picture of it with a phone to send around to teams.

Unfortunately this process doesn’t scale well when development teams have more than a few people. Change management on the whiteboard isn’t an effective system for ensuring the success of a software release.

Branching patterns should be able to support the development process, and mirror the natural flow of the development team as they work towards a release.

To achieve this, we might want to think of branches as a process management tool, not just a place to put a specific release, patch or development build.  Promotional branching patterns allow for different “states” of code, which is hugely powerful when working through the development cycle. This is a huge topic that is part of larger conversation. To find out more about promotional branching and merging patterns check “A Guide to Branching and Merging Patterns.”

Provide Private Areas for Teams to Check-in and Integrate

Committing early and often is an SCM best practice. Over the years, developers have been told “If it’s not in source control, it never happened.” To avoid this philosophy, teams may require people to check code in everyday so work isn’t lost.

In a practical branching pattern, teams and developers create both private workspaces and branches, allowing them to create builds, releases, and tests of code before they push those changes to other team members. Avoid using mainline type branching patterns that don’t provide code stages; this leads to broken code and unfinished work making its way into a release.

Manage Distributed Teams

Collaborating and sharing code with distributed teams is more complex than ever – teams routinely develop in one location and test or perform other tasks in another location. This distribution of teams strains the development process, yielding security, auditing, and integration problems.

Development teams must appear to be co-located while utilizing the same process with lower complexity. This means code integrations with other projects should happen in real time, so teams can give each other feedback immediately. The branching pattern and process must be followed by everyone, to ensure they are all on the same page.

Understand What has been Delivered

User Stories, bugs, and requirements drive any process, but the ability to see what changes match such items and the location of those code changes are often overlooked in the branching structure.

There is a magical feature that many SCM tools have, called “change-sets” or “Change Packages” in AccuRev. Change Packages associate your changes in the branch with an issue, so you can stay organized and move issues from branch to branch, without having to remember what file went with what issues.

Take these pieces of advice, and they will help if you want to build a release with “finished” issues or if you want traceability into what people are currently working on for a specific release.

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

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.

I hope I don’t end up with a seized engine on the side of the road, but if I do, I’ll know I should have had that oil change. I hope I don’t end up on the Worst Dressed List, but if I do, at least I’ll know I should have given away those old shirts.  I feel sorry for those on the “Worst Agile Implementation” list who don’t even know they’re there.

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.

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!

A funny thing has happened over the last couple of years…. we started calling waterfall software development… er… “waterfall”. By this I mean, we never had a name for the process… waterfall was just called “software development”. There was no distinction or name for what we were doing- there was only one way. This is a draw of agile, it’s something different.. and it’s the only new development methodology to actually get attention in the last 10 years.

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.

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.