I thought for this week’s blog I would do a development update and some insight on how software updates get deployed to our customers.

A few weeks ago we announced that a new build is going to be released during the 13^th week of the current season.  We do our best to try and pick the best windows of opportunity to roll out major updates to the software so we don’t disturb the racing and points battles going on.  There are certainly going to be times that we do a software update during the season when we have found an issue that needs to be corrected immediately but for the most part we will be shooting for the break between seasons.

Creating and timing these software updates is not an easy task.  We have two major engineering teams here at iRacing, the Website and Infrastructure team and the Software Development team, who for the most part work independently from each other.  For instance, the recently released iRacingWorld was developed and implemented entirely by the Web team with no involvement from the Software team.  Where this changes is when we get closer to rolling out a software update.  A number of our software systems require significant use of an Oracle database which in essence is a “middle man” for how the Web team feeds you information about things like sessions you are signing up for or just completed and many other mostly invisible functions our website serves.  Any time we make database changes for the software we will more than likely need to roll out significant changes to the website.  This is one of the reasons why we have lengthy maintenance mode periods when we are rolling out new builds.

Being able to roll out software updates whenever we choose is a nice luxury we have here at iRacing which we did not have at Papyrus.  We used to have a date in January that whatever we wanted to have in our product for that year had to be completed and tested or it was not going out.  With four planned software updates scheduled here at iRacing we have essentially four three month windows to try and make as many improvement or additions we can.  In reality these quarterly development windows are really only about two months each because we try and do about a month of testing on each major build.

For the most part each software engineer works independently from each other on given tasks for their two months of development time.  In this development window we have been working on sound and UI improvements, Yellow flags and race control, improvements to tires and aero, incorporating the first stage of pitting, open practice servers, backend stuff nobody but Randy understands, the Silverado and Daytona Prototype along with many other projects.  Once we get towards the end of that two month development period we assess the open projects and make an evaluation on if they will make the next build. (Just to stop the speculation, this next build will not have the Daytona Prototype in it because it is pretty far from complete and open practice servers are a much longer term project.  There will also be tasks like tire and aero that will never be complete.)  The Web team has the ability to roll out updates much more often which is why you see us put the service in maintenance mode for five minutes to a few hours every few weeks.  I will tell you that one of the big projects the Web team is working on and hope to roll out before the end of the year is incorporating Paypal into our service.

Once we have reached the end of our two month development period we start the process of making a build.  Creating a build and all the associated packages and uploading them to our servers and distribution partner takes us an entire day to complete.  We have an entirely separate testing environment that we roll out any changes we want to make to the service before they make it to the environment you use.  We do extensive testing on these updates and find many, many problems that we take the entire month to try and correct.  We generally end up doing three to four builds and updates over the last month to try and correct issues we find during testing with the goal for each one to not break anything else. If an engineer has fixed all the open issues on their plate they may try and sneak a last minute addition into the build but only if it is deemed to be at low risk to break the build.

Testing is actually going pretty well at the moment and I feel pretty confident about the build we are targeting for the next release.  I know that it is difficult to be on the outside trying to figure out what is going on in the inside, but nothing is as easy as it appears even for guys that have been doing this for two decades now.  We all do our very best to try and make improvements as quickly as possibly but we absolutely do not want to roll out something or promise you something until we know it will work the way we want it to.

One major piece of the build puzzle that I did not really touch on is how content is created and this is worthy of a blog post all its own.  I will likely tackle this topic next week.

Steve