Last summer, we celebrated an exciting milestone: eXtyles Build 4000!

But what exactly does that mean? Well, since you asked …

How Inera “makes” eXtyles

Inera has used an Agile development methodology since we started developing eXtyles in 1999. This means we’re constantly evolving requirements and solutions during development, based on real-time feedback, and continuously improving our software. We make those improvements available to our customers on a rolling annual release cycle, so that whenever you receive an update of eXtyles, you’re getting the very latest and greatest version.

A key part of our Agile development is the nightly “build” process. Every night at 5 pm Eastern time, an automated process running on Inera’s servers takes all the latest code and data from our Source Control System (essentially a content management system for computer code)—including any changes made that day—and puts it all together into a new release of eXtyles. We call this “building” eXtyles because the process involves pulling and compiling thousands of files each night.

So what do my build numbers mean?

Each time the eXtyles build process runs, we apply a new, incrementally assigned number to the resulting release of eXtyles. This “build number” allows us to uniquely identify every release of eXtyles and describe the exact new features (or bug fixes) that were added to it. Build numbers are more precise and more informative than traditional software version numbers, because they reflect the reality of daily software releases rather than the less frequent releases of past software distribution.

You can always find your current eXtyles build number (via eXtyles>About in Word). It’s likely a number between 3800 and 4200, depending on when you received your last eXtyles update. If it’s lower than 3800, please contact our Support team, because that may mean the latest update hasn’t reached you!

Usually there will be a gap of about 300 builds between your current release and your previous release. That’s because we try to provide all customers a new build of eXtyles once a year, and we make about 300 builds per year. Sometimes that gap will be smaller or larger if we’ve been doing a special customization project for you that has affected your annual release schedule.

And what does it mean that we recently reached Build 4000? It means that our automated process has put together a full release of eXtyles more than 4000 times. That’s an average of one build per night, 6 nights a week, for almost 19 years.

Whew!

(Why 6 nights a week? Because we often do a special weekend test run to investigate specific processes, improvements, or concerns.)

First we build—then test, test, test

Making a new build of eXtyles every night is just one part of our Agile development process. We want every customer’s eXtyles installation to work exactly as expected with each update, so you’ll only get a new build when we’re satisfied that it’s performing as it should!

And how do we ensure that? We do lots of testing. And we’re able test virtually everything, every night, because the vast majority of testing at Inera is automated. Sure, we do a lot of manual testing when we first build a new feature, improve an existing feature, or configure eXtyles for a new customer. But once that feature is ready, or the customer’s configuration is complete, our Development, Configuration, QA, and Support teams work together to “lock” that behavior into our automated “test suite” by setting up test documents and regression-testing (i.e., re-running) them every night to ensure that the feature or configuration stays stable with every new build.

Every night, as soon as the “build” is ready—it takes about 45 minutes for the build process to run—the new release of eXtyles is automatically distributed to eight servers, which run a combined 80 machine-hours of automated testing overnight, using eXtyles SI. (Talk about eating our own cooking—we get to use our own product to automate our own testing!)

Thousands and thousands of tests

Every morning, our QA team reviews the results of the overnight testing. If anything has changed—even something as small as a single period or space—it’s carefully reviewed and a decision is made. If the change is an improvement, it’s approved by QA, and the result becomes the new standard for that file. But if the change is not correct, QA sends the update back to Development for further work until later test suite runs show no incorrect changes. Thanks to this process, if an “improvement” to eXtyles has unexpected side effects, we’ll find out right away, and our Development and Configuration teams can resolve the issue before the next night’s test run—and, of course, long before it can creep into an eXtyles release.

These automated tests cover just about every feature of eXtyles. They also cover customer-specific configurations, so that we can ensure your specific eXtyles setup is not adversely affected by a development change to eXtyles.

How do we get such broad coverage? Our test suite has been created and continuously expanded over twenty years of eXtyles development. It currently includes thousands of unique documents and test cases, and we add new test documents with each new eXtyles customer, so that we’re always testing out our software in relevant real-world conditions. We also add a test case any time we fix a bug (alas, all software has bugs), so that we can be sure never to “un-fix” a fix.

Finally, the test suite gives us a unique testing ground for new ideas. If the Development team wants to try out a new approach to parsing references, for example, they can develop the idea and then get overnight feedback on tens of thousands of references to see if the approach works, needs further refinement, or should be set aside. This test- and data-driven approach to software development allows far faster and more accurate updating of eXtyles features.

The test suite covers such a wide range of our software that it would be tempting to rely completely on automated testing and dispense with manual testing. But, as valuable as our nightly automated testing and extensive data set are, no build, patch, or feature is ever released to a customer without also undergoing manual testing. There’s no substitute for having multiple levels of quality control, both automated and manual.

The bottom line: Quality!

Our Agile development process, combined with extensive automated and manual testing, means that customers should only ever see improvements when updating their eXtyles installation. This is Inera’s quality commitment to our customers.

We’re excited to have reached the Build 4000 milestone, and we look forward to the next 4000!