Where would we be in the world if we didn’t have feedback loops? Whether you know it or not, feedback loops are everywhere and you probably use them every day. Your toaster oven, your car, and the computer you’re using right now to read this blog post- feedback loops are everywhere.  Heck, even most biological organisms including humans and animals are constructed out of feedback loops. (Don’t believe me?) It’s the basis of all life!

A classic example of a feedback loop is the temperature control on your toaster oven.

Let’s imagine that we set the temperature to 300 degrees.

Here is the loop in which your toaster oven sets its temperature to 300 degrees:

1. Check thermostat for temperature

2. If greater than or equal to 300 degrees, stop heating coils

3. If less than 300 degrees, heat coils

4.  Goto step #1

“So what?” You’re probably saying to yourself, that’s easy.  Provide feedback to a device and it’s behavior will change. Why is this a big deal?

Continuous integration is the feedback loop for your development organization. It’s a feedback loop for people. It allows your developers to rapidly change course at a moment’s notice.

The Continuous Integration Feedback Loop

Let’s run through the continuous integration feedback loop, which is remarkably similar to the toaster oven.

Here is the feedback loop for a developer while using continuous integration:

1. Checkin code

2. Receive e-mail of build results

3. If build/test is success, enjoy the fruits of your labor

4.  If build/test is broken, fix and Goto step #1

If you don’t believe a feedback loop is necessary, if you’re thinking everything is working fine, you’re fooling yourself!  The reason? If there is a problem, you’re just not aware of it. In the same sense, would you just turn off the thermostat in your toaster?

Here’s how the toaster works without the feedback loop:

1. Heat coils

2.  Burn down house

And that’s what NOT doing continuous integration is like… playing with fire.

A lot of times I hear from customers who aren’t doing continuous integration that it’s just too hard to implement CI in their organization. The reasons vary, but usually come down to not being able to afford rewriting manual processes already in place in order to gain a rapid, consistent build running. To this I say, you are using the wrong tools, and bad practices to boot. The amount of rework and frustration you will save will be worth your effort. It’s a fools game not to expose your integration problems to the rest of the organization.

When I talk to customers who HAVE implemented a CI solution, I’m astonished at what I hear. They say “We never know we had so many issues until the QA cycle” or “We can’t’ believe we ever lived without this.”

Changing course is one of the key principles of Agile; inspecting and adapting is what allows your team to avoid disasters. It gives visibility into what’s happening with your current processes. Continuous integration is the tool that you need to allow your teams to function like a perfectly functioning toaster oven.

So what does a world look like without feedback? Houses on fire, cars crashing, development organizations failing and developers blindly making disastrous coding changes. Do yourself a favor, and think about feedback.

By Ryan LaNeve, AVI-SPL

Much has been written on this blog already regarding the ease with which AccuRev allows you to tailor your development process without having to fight with your SCM software. While I could offer yet another account of how simple and straightforward it is to manage our particular process using AccuRev, instead I thought I’d take a few minutes to point out some of the things we’ve done using the tool’s command-line interface and its ability to output results formatted as XML.

Of the various tools we have created over the years, the two we find most useful are what we call “AccuLoad” and “SQL Object Scripter”. The former pulls data out of AccuRev, while the latter puts data into AccuRev. Both were developed in a matter of hours thanks to the extremely intuitive command-line interface which AccuRev provides. Let’s take a closer look at each.

We’ll start with our “SQL Object Scripter”. Anyone whose development efforts involve a database server knows how difficult it is to maintain change logs for the “code” kept within the database. There are a number of “best practices” with regards to maintaining this information within an SCM, but in our experience they are all too time-consuming and involved, which leads to one or more members of the team either forgoing the process due to time constraints or just ignoring the process all together. Maybe we’ve just become spoiled by AccuRev allowing us to work exactly the way we want and otherwise staying out of our way, but we now have a hard time following any procedure which requires us to change the way we do things.

So one day a couple of us sat down and decided to find a new solution. We felt that, at a minimum, what we really wanted was to be able to view changes over time for our database objects, such as tables, views and stored procedures. We knew that if we could just get each change into AccuRev some of our issues would immediately disappear, but we found it too difficult to require the entire team to manually create every script and then manually promote that script into our SCM. We decided that what we needed was a tool that could simply detect changes to our database objects and automatically store those changes within AccuRev. Again, thanks to the simplicity of AccuRev and its CLI, our “SQL Object Scripter” tool was born in a matter of hours. We now have a record in AccuRev of (almost) every change made to any database object we care about, which then allows to use the features of AccuRev to view the history of any object, the differences between any versions of any object and even an annotation of any object to see who is responsible for the make-up of the object. The solution consists of a few parts: a SQL Server table to store DDL change event details, with a DDL trigger on the various databases we care about. The trigger fires whenever a DDL event occurs, such as the creation or alteration of a table, view or stored procedure, and the details of the event get logged to a table. Our custom console app is then scheduled to run every few minutes and checks the table for any records. When a record is found, the console app scripts out the definition of the object to a file and then uses the AccuRev CLI to add/keep/promote the file to our “SQL Scripts” depot – whatever is appropriate depending on whether the object is brand new or pre-existing and has been changed. The AccuRev commands all run within the context of whichever user made the change in the database itself, so all of our AccuRev transactions are associated with the correct team member. While this solution is not optimal and does not provide as much traceability as having each developer maintain and promote database change scripts themselves, we have found it to be an excellent interim solution which was extremely easy to put together.

Another of our tools is the one we call “AccuLoad”. The purpose of this tool is to pull various bits of information out of AccuRev and load that information into a database. We then use the information in the database from several other applications. The tool is a console application which runs in a couple of different modes, but the primary mode is run via an AccuRev trigger. Whenever a promote happens in one of our depots, our custom trigger runs and fires up our console app, passing in a few details such as the name of the depot, the name of the stream and the transaction number of the promote. AccuLoad then takes this information and makes various calls to the AccuRev CLI to gather more details, such as which elements were included in the promote, the version numbers of each of those elements, the user who performed the promote, etc, etc… Additionally, a diff is run against any changed elements, and those details are stored in the database as well. Gathering all of this information from AccuRev was extremely simple thanks not only to the intuitive nature of the functionality exposed by the AccuRev CLI, but also thanks to the option of having the results returned as XML. While I’m sure it would have been possible to create such a tool using any SCM, I doubt we would have ever found the time to do so had we not been fortunate enough to have AccuRev as our SCM. It was, again, only a matter of hours from the time we came up with the idea for AccuLoad and the time our first promotions were being logged in our database.

Having this database detailing the activity in our SCM, we were then able to create several other tools to utilize the information, such as one we call “AccuBrowse”, seen below. This web-based application allows us to browse the database and view any transaction within any stream of any of our depots, and see who performed the promote, the comments supplied during the promote, the elements included in the promote and the differences for any changed element. I should mention that much of this functionality is probably available in the AccuRev Web Interface, though we have not actually used that tool provided by AccuRev. Ours was created a couple of years ago and suits our needs. Beyond just allowing us to browse our SCM history via a web-interface, our database also allows us to perform some analysis, such as frequency of change for elements within a specific depot or stream, which allows to keep tabs on classes within our systems which may have too much responsibility. We can even run queries against the data to find “problematic” code, such as those files most often included in promotions which cause a failed build (not that our builds ever fail, of course…).

In summary, there are a myriad of fantastic features and functionality within AccuRev which make it a great fit as an SCM for any development environment. Once you’ve got your core needs taken care of by the out-of-the-box functionality, I encourage you to explore what can be done with the provided CLI and its XML-formatted output. In our experience, if you can imagine it, you can build it with AccuRev in no time at all.

Our custom AccuBrowse application, viewing a transaction involving a SQL Server stored procedure: